
                   NEW FEATURES in version 0.9.10.

This release is a major reshuffling and rewriting of the code with the
aim to enchance the performance and decrease the size of the
compiler. No interfaces were changed and the new version should be
backward compatible. But, about every part of the library was
touched. It passes all test from an old testsuite, but still, be
careful with this release. If something does not work (or works
strangely) -- tell me about it and try to use the 0.9.9 release (which
has the same functionality, but is better tested).

The changes were

*   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 JAR.
    BTW, about 10Kb less than the first 0.1 release of JEL (which did almost
    nothing compared to what JEL can do now).

*   Performance was also enchanced by new parser, which does
    significantly less heap allocations.

*   A short introduction to the internals of JEL (how to use it as a Java
    assembler) was added. It is in the file CODEGEN_HOW_TO in the distribution
    root.

*   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 constructor
    2) gnu.jel.DVResolver interface, please use DVMap instead.

    

                       PLANNED FEATURES

1. Implement the panned feature. ;) The new features weren't added to this
   release purposedly, to give chance for the new internal representation
   and parser to stabilize a little bit.

2. Identification of the return type of compiled expression at run-time but
   prior to evaluation. Currently, the type can either be fixed (which is
   convenient for numerical computations), or be free (in this case the
   precise type of the returned object can be determined using its "getClass"
   method. There is also possibility to determine the result type without
   expression evaluation by calling CompiledExpression.getType, but currently
   it only distinguishes between the primitive types and does not say the
   exact class if the result is an object. The additional type identification
   would enable to access what compiler knows about the result type of the
   expression returning an object without running the expression. This is less
   precise than querying returned object directly, but guarantees that the
   returned object belongs to a subclass of the class determined this way.

   Note that fixing the result type (an already implemented feature) of the
   expression to a class of non-primitive type guarantees that the returned
   object will be always of a subclass of that class.

   This feature was requested on help-jel mailing list.

   http://mail.gnu.org/mailman/listinfo/help-jel

3. Improve detalization of error messages. A few (2-3) error messages become
   unused with a new parser. Also, having a custom parser gives more control
   in adding more helpful and suggestive error messages. This is an important
   problem and I would like to consider it separately. It will be implemented
   in a next non-bugfix release. Anyway, the current error messages are not
   that bad, just they can be better.

Wed Feb 13 03:15:40 CET 2002 
           Konstantin Metlov.
