Issue Details (XML | Word | Printable)

Key: MULE-947
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Holger Hoffstaette
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Mule

Unify access to shared variables by using proper accessor methods

Created: 01/Aug/06 07:35 AM   Updated: 30/Nov/08 04:05 AM
Component/s: Core: (other)
Affects Version/s: 1.3-rc5
Fix Version/s: 2.0.0

Time Tracking:
Not Specified

Issue Links:
Related

Labels:


 Description  « Hide
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.

 All   Comments   Work Log   Change History   Transitions   FishEye      Sort Order: Ascending order - Click to sort in descending order
Andrew Perepelytsya added a comment - 01/Aug/06 01:22 PM
It looks like it fits nicely in the Mule 1.4 target scope. There's too much for 1.3 line with the m2 push coming. WDYT?

Holger Hoffstaette added a comment - 01/Aug/06 02:19 PM
Fully agree, that's why I didn't set any fix-version. Ironically enough, since I removed PXE and made sure gigaspaces was 1.4-only we now fully compile and run with JDK 1.4...
But as I said moving to 1.5 (hello MULE-639) might have other benefits. The invariant return types are a little known but extremely valuable feature e.g. for factories and the bizarre typecast workarounds with some "helper methods".
I also think generics might be able to help reduce a lot of typecasting and potential ClassCastExceptions by simply making everything more consistent. When I finished PXE's generification I found numerous extremely subtle bugs that were hard to find otherwise.

Holger Hoffstaette added a comment - 02/Sep/06 07:21 AM
The return types are of course _co_variant, not invariant..