Use proper enums
Throughout the Echo server side library, int constants are used where enums are needed. This is a problem, since it makes it easier to make mistakes which could have been caught at compile time had enums been used. In some classes, constants with different purposes are declared which can be mixed up. Editors with code completion tools also cannot pick up the correct completions. Here are some examples of ints used as enums:
Extent ex = new Extent(Extent.PX, 100); // correct use is value,units but compiler can't pick this up. Border b = new Border(Border.STYLE_INSET , Color.BLUE, 1); // swapped style and size.
While these examples will seem contrived, it should be obvious that in a large application mistakes can occur, and may be hard to track down. Since 1.5, Java has had proper enum support, and in my opinion the Echo developers should at least consider changing the library to use enums rather than int constants. Since this will cause code breakage (which will be detectable on recompilation), it would be best to change this while Echo3 is still in beta.
Would the Echo3 developers consider changing this? Our development team would be prepared to do this and to submit a patch for this.
I'd love to move to Java
I'd love to move to Java 1.5, but our base requirement for (Echo3) is still 1.4.
Since Java 1.4 is EOL since
Since Java 1.4 is EOL since over a year now,
http://java.sun.com/j2se/1.4.2/
perhaps a poll to ask if Java 1.4 is still used.
Or are there other java 1.4 versions still supported by other vendors (IBM) ?
We ourself have all servers on at least Java 1.5 and are now rolling out 1.6 on the new systems.
J2SE 5.0 has also reached
J2SE 5.0 has also reached its End of Service Life already.
http://java.sun.com/javase/downloads/index_jdk5.jsp
Yes, but if you buy
Yes, but if you buy enterprise support then 1.4 support is extended up to 2018 (16 Years since launch) and to 2019 for 1.5
http://java.sun.com/products/archive/eol.policy.html
I think it is important to know what the installed base is using as JVM, then depending on that we could drop support of older JVM's IF we gain something by dropping the support.
What advantages would dropping java 1.4 give us today ?
André
Slight advantage
Access to features such as generics and enums which help us produce better code.
Echo3 is in beta and will, when launched, be a big upgrade on Echo2. The only reason to stick to Java 1.4 would be if there are a large number of installed Echo2 users on 1.4, who will migrate to Echo3 but can't migrate to Java 1.5.
Even 1.5 is vanishing quickly.
>> What advantages would dropping java 1.4 give us today ?
1. Generics + Enums + new for(TYPE var : sequence) syntax would be the biggest immediate benefits.
2. Using annotations for Component properties and more.
Generics + Enums will make the code cleaner, less prone to Runtime errors. ( ClassCastException anyone ??? )
annotations + a bit of reflection magic can also reduce code size without obfuscating things (to much), especially code that deals with properties , events , serializing to xml etc..
Most of the Enum changes can be done with little to no impact (other than a re-compile ).
for example the use of Extent ..
public class Extent {
public enum Unit {
PX , PC ...
};
// Also declare final instances of Enum constants.
public final Unit PC = Unit.PC;
...
}
This will keep most of your code compiling without any required changes , However I would personally suggest a sed script to change all references of
Extent.<WHAT EVER UNIT> to Extent.Unit.<WHAT EVER UNIT> and deprecating the the direct referencing of the enum instances if you feel the need to add them..
To convert the current Echo3.beta to use Enums won't take more than a few days ( I'll even volunteer to do it )..
Generics is a bit more work and probably won't make such a big impact since the current Component public 'interface' uses arrays and not collections.
Perhaps for Echo4 we can change that to use generic Collections and remove all references to the arrays ( this would mostly be for performance reasons more than anything else really).
As for the magic that can be done with the Annotation processors in java 1.6 , the sky is the limit.. ( Automatic generation of ComponentSynchronizePeers ? )
For those who haven't played with the java Enums , they are not as simple a C enums, you can specify contructor , methods and additional properties, making them quite powerful.
BTW.
The latest Mac OS/X updates dropped support for Java 1.5 . So our current toolset is two versions ahead of the code base..
My opinion is that very few people if any would be using Echo3 with java 1.4 ..
I'm just being curious, but
I'm just being curious, but why? Where is this requirement coming from?
Echo3 is already non-backwards compatible with echo2, why not switch now? What's the benefit?
Use Retroweaver
Hi Tod,
In a project of mine I use Retroweaver (http://retroweaver.sourceforge.net/) which allows me to use Java 1.5+ syntax, but produce a 1.4-compatible Jar for those still living in the dark ages.
Maybe it's worth checking out for Echo 3.1.
Tristan
Throwing in my 2 cents
Throwing in my 2 cents worth...
The existing codebase could be updated to make use of enums in java 1.4 - there are good patterns for doing this, and gives you compile-time checking. Maybe not as good as 1.5 enums, but it would also be a good opportunity to define these enums in a more centralised way which would make moving to 1.5 enums much easier in the future.
Biggest problem would be in breaking backward-compatibility with existing code... but speaking from experience, moving from echo2 to 3 is a much bigger issue. As our echo2 apps uses a lot of extras and epng, we have a big effort in front of us to move to echo3 and for us it just isn't possible at this time.