gvSIG bugs #2036
Bad implementation of FLyrDefault.cloneLayer()
Status: | Outdated | % Done: | 0% | |
---|---|---|---|---|
Priority: | Normal | Spent time: | - | |
Assignee: | - | |||
Category: | Application | |||
Target version: | - | |||
Severity: | Add-on version: | |||
gvSIG version: | 2.0.0 | Add-on build: | ||
gvSIG build: | 2066 | Add-on resolve version: | ||
Operative System: | Add-on resolve build: | |||
Keywords: | Layer FLayer clone | Proyecto: | ||
Has patch: | No | Hito: | ||
Add-on name: | Unknown |
Description
The FLayer.cloneLayer()
JavaDoc says it's a fast implementation of clone which return a new instance of the layer.
But, in fact, it's the fastest implementation because in the FLyrDefault
implementation of this method looks like that:
public FLayer cloneLayer() throws Exception { return this; }
While developer thinks that this generates a new instance, he gets the very same instance. So, it can produce a very strange behaviour in application (changes on one layer than affects to other in TOC, etc..).
I suggest to deprecate this method and make Flayer
implements the org.gvsig.tools.lang.Cloneable
inteface.
History
#1 Updated by Álvaro Anguix over 10 years ago
- Assignee set to Joaquín del Cerro Murciano
#2 Updated by Álvaro Anguix over 10 years ago
- Target version set to 2.1.0-2218-testing
#3 Updated by Joaquín del Cerro Murciano over 10 years ago
- Target version changed from 2.1.0-2218-testing to 2.2.0-2311-rc2
#4 Updated by Álvaro Anguix about 10 years ago
- Priority changed from High to Normal
#5 Updated by Álvaro Anguix about 10 years ago
- Assignee deleted (
Joaquín del Cerro Murciano)
#6 Updated by Álvaro Anguix over 9 years ago
- Target version deleted (
2.2.0-2311-rc2)
#7 Updated by Álvaro Anguix 9 months ago
- Status changed from New to Outdated