Thanx, I'll go to the latest 0.9 first and see if I have time to go to
2.0 . I know that the code uses DVResolver, but I'll have to prioritize
that change with all the rest of the refactoring.
From: Konstantin L. Metlov [mailto:metlov@kine...]
Sent: Wednesday, July 25, 2007 5:39 AM
To: Chappelear, Jack
Cc: help-jel@gnu.... Subject: RE: [Help-jel] Identifying version of jel
> The class files in the jar file were compiled on Feb 20, 2001
Then you have the version 0.9.7 exactly.
The "major" changelog is the following:
* Overridable String comparisons using the usual relational operators
">", ">=", "<", "<=", "==", "!=" and employing the current locale.
* User-definable explicit casts of non-primitive types.
* The library size is reduced by 11%
* The compiler performance is improved by 14% (running the 0.9.8
* New DVMap class, allowing optional compile-time translation of
dynamic variable names from Strings into other Java primitive types
for improved performance.
* Deprecated (scheduled for removal in JEL >1.0)
1) gnu.jel.Library constructors except the 5-argument full version,
please add null arguments to your calls to the Library
2) gnu.jel.DVResolver interface, please use DVMap instead.
* The code is now represented by tree internally.
* A new hand-written parser. JEL does not depend on JavaCC anymore.
* The compiler size is reduced by >30%, it is now <34Kb compressed
* Performance was also enchanced by new parser, which does
significantly less heap allocations.
* JDK 1.4 source compatibility.
* Detailed identification of the result type prior to expression
evaluation (see method getTypeC() in gnu.jel.CompiledExpression)
* JDK 5 source compatibility.
This release is built (and tested) under JDK 5 using all of the
new features (such as Generics). It will not work with older JDK
releases (because JDK 1.5 itself is not backwards compatible).
Please use older releases of JEL with old JDKs and JREs.
* JEL is now built with ant.
* Documentation is improved and is now in DocBook format.
* Numerous doc commentsfixes.
> The 'real' question is how painful and what benefits would I get by
> upgrading to the latest version as part of a migration to Java 5.
> The other option is to just go to 0.9.11 , which sound pretty stable (
> going on 3 1/2 years ...)
All these versions are stable with no critical bugs. The versions 0.9.*
are API-compatible, whereas the version 2.0 is "mostly" API-compatible
0.9.* (and even then the migration should be easy).
So, my suggestion would be to just try 2.0. There is a big chance it
will just work. You will also benefit from numerous and significant
performance enchancements since 0.9.7.