
| Key: |
MULE-947
|
| Type: |
Improvement
|
| Status: |
Closed
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Holger Hoffstaette
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Related
|
|
This issue relates to:
|
|
MULE-639
Investigate JDK 1.5 as base platform for upcoming Mule versions
|
|
|
|
|
|
This issue relates to:
|
|
MULE-891
Plan roadmap to 2.0 via 1.3.x, 1.4.x
|
|
|
|
|
|
|
|
One thing I just noticed again is the dangerous habit of having the same instance variable several times, e.g. AbstractReceiver and subclasses like Pop3MessageReceiver store individual references to the connector, most likely to avoid typecasting the connector in their individual "layer of visibility". Since the same object is stored in these references there's no problem calling methods through either, but problems can occur when one lower layer e.g. replaces the connector, sets it to null etc. and "forgets" to do so in the superclass. The problem cannot be easily solved by get/set methods since JDK 1.4 does not allow so-called covariant return types, i.e. having a subclass' method return a subtype of the overridden superclass' method return type. This would be one of the significant advantages of moving to source-level 1.5.
I consider covariant return types one of the most important features of JDK 1.5, especially in a system that uses inheritance as much as Mule does.
The other thing that could be gained is a much improved control flow and the ability to properly synchronize certain accesses by simply getting the appropriate method right.
|
|
Description
|
One thing I just noticed again is the dangerous habit of having the same instance variable several times, e.g. AbstractReceiver and subclasses like Pop3MessageReceiver store individual references to the connector, most likely to avoid typecasting the connector in their individual "layer of visibility". Since the same object is stored in these references there's no problem calling methods through either, but problems can occur when one lower layer e.g. replaces the connector, sets it to null etc. and "forgets" to do so in the superclass. The problem cannot be easily solved by get/set methods since JDK 1.4 does not allow so-called covariant return types, i.e. having a subclass' method return a subtype of the overridden superclass' method return type. This would be one of the significant advantages of moving to source-level 1.5.
I consider covariant return types one of the most important features of JDK 1.5, especially in a system that uses inheritance as much as Mule does.
The other thing that could be gained is a much improved control flow and the ability to properly synchronize certain accesses by simply getting the appropriate method right. |
Show » |
|