jsweet

Optimisation & stabilisation

See PR https://github.com/cincheo/jsweet/pull/604 for details.

• Minor bug fixes
• Some improvement in generated code lisibility
• New options to better tune code generation

• async / await support
• Faster TypeScript transpilation using tsserver
• A lot of enhancements & fixes

Bug fix version for v2.0.0.

Main new features (see the specifications for full details):

• Full support for external configuration file (jsweetconfig.json)
• Well-tested and documented extension API for tuning the TypeScript/JavaScript generation (JSweet is now a fully Open Transpiler, see the doc)
• More extensive Java API built-in support (without any runtime): collections, reflection, java.io, math, ...
• Many Java bug fixes: inner and anonymous classes, enums, logical and comparison operators, lambdas/classes mapping, method overloading, ...
• J4TS runtime is not used/required by default (unless you add it to the classpath)
• More support for JavaScript decorators
• Better source map support (including when using modules)
• Built-in watch mode to transpile your modifications on the fly regardless of what IDE/editor you are using
• Core API changes for consistency (jsweet.lang -> def.js, jsweet.dom -> def.dom, jsweet.util.Globals -> jsweet.util.Lang) - older API is deprecated but not removed for backward compatibility
• Core API improvements: better typing, lang macros (for instance $insert), flexible code replacement annotation (@Replace), ...

This this the second release candidate for JSweet version 2. Compared to rc1, this release contains the improvements below. Many thanks to all the contributors and issue reporters.

Fixes

• fix a runtime bug when overloading constructor in non-static inner classes
• various fixes and generated code improvements for module imports
• support the equals method on enums
• allow extending JavaScript's Error class
• various fixes on built-in JDK support
• $apply(..) fix
• more robust candy descriptor parsing
• various fixes to support full Angular2 compilation (including TypeScript phase)

Features

• add the extraSystemPath option to tune the transpiler path if necessary
• add the moduleResolution option to enable/disable node module support
• API improvement to add headers in generated files (see PrinterAdapter.addHeader(..))
• allow @Replace annotation on constructors (requires new core API)
• support for enums implementing interfaces

Main new features (see the specifications for full details):

• Full support for external configuration file (jsweetconfig.json)
• Well-tested and documented extension API for tuning the TypeScript/JavaScript generation (JSweet is now a fully Open Transpiler, see the doc)
• More extensive Java API built-in support (without any runtime): collections, reflection, java.io, math, ...
• Many Java bug fixes: inner and anonymous classes, enums, logical and comparison operators, lambdas/classes mapping, method overloading, ...
• J4TS runtime is not used/required by default (unless you add it to the classpath)
• More support for JavaScript decorators
• Better source map support (including when using modules)
• Built-in watch mode to transpile your modifications on the fly regardless of what IDE/editor you are using
• Core API changes for consistency (jsweet.lang -> def.js, jsweet.dom -> def.dom, jsweet.util.Globals -> jsweet.util.Lang) - older API is deprecated but not removed for backward compatibility
• Core API improvements: better typing, lang macros (for instance $insert), flexible code replacement annotation (@Replace), ...

JSweet v2 will bring many major improvements, including:

• support for Java APIs with or without J4TS (when J4TS is not in the classpath, JSweet generates JavaScript code)
• support for extensions (the code generation can be customized depending on your needs)
• full support for writing custom definitions in def.* packages

The goal of this intermediate release is to have a stable version for those who already want to use JSweet 2 latest capabilities.

This release contains many bug fixes and new features. It takes into account our last-months experience developing real IONIC/Cordova applications with JSweet, but also many excellent feedbacks from the community (many thanks to the reporters!).

Important new features and changes

• Full support for in-project definitions (bridges to JS lib can be defined on-the-fly within the def.* packages). Now, you can easily write bridges to JavaScript libs in your project if you don't find the corresponding candy. For your definitions to be taken into account, the definitions option of the compiler needs to be turned on.
• Better support for source maps (including when using the bundle mode). You can now debug your Java files from a JSweet-generated bundle. Also the debug mode does not break the generated code presentation anymore. The new source map support is implemented with Google's Closure source map API.
• Changed/improved module support to make it compatible with Angular 2 (see https://github.com/cincheo/jsweet-primeng-quickstart).
• Support for type decorators as Java annotations (required to use Angular 2)
• Full support for Java enums (including fields, constructors, and methods).
• Support for Object.getClass(). JSweet now supports expressions such as myObject.getClass() == x.y.z.MyClass.class.

Bug fixes

• Various bug fixes for method and constructor overloading, inner classes, default methods
• Various bug fixes when using the modules
• See the Github commits for a full list :)

Important note on Candies and the next version

Candies will not be released anymore under the current form. So you should continue using the 1.2 snapshots for this release. Candies will now be publically available for modifications in order to favorize a more collaborative and open approach. This new way of dealing with Candies should be available soon (for the next version).

Changes:

• Fix problems when using some functional interfaces defined in java.util.function.
• Allow the use of functional interfaces in overloaded method.
• Support instanceof with functional interfaces (for exemple: if(myFunction instanceof BinaryOperator) { ... }).
• Support passing varargs as arrays in constructors.
• Fix name clash when declaring a class called Function.

Note: varargs cannot be used in overloaded methods

Changes

More Java support

• Field are allowed to have the same name as a method name. For instance the following code is now valid in JSweet:

    public class C {
        private int size;
        public int size() {
            return size;
        }
    }

• More general support for complex overloading (methods and constructors). JSweet now emulates the Java behavior when overloads are detected. For example, the following code is now valid in JSweet (and behaves as expected by Java programmers):

    public class C {
        private int size;
        public int size() {
            return size;
        }
        public int size(int addTo) {
            return size + addTo;
        }
        public int size(String string) {
            return string.length;
        }
    }

• Support for inner classes (both static and non-static). In the non-static case, the enclosing instances fields can be accessed preserving the Java semantics.
• Support for default methods in interfaces
• Support for static methods in interfaces
• Support for JSNI (support to help forking GWT's JRE emulation...)

    public native void m() /*-{
       // JS code
    }-*/

• Preserve Java integer semantics (for example, a cast to an int will be rounded)
• Preserve Java array allocation semantics for any dimension

    String[][] array = new String[2][2];
    assert array.length == 2;
    assert array[0].length == 2;

• Add 'instanceof' support (valid for classes and interfaces)

    assert "abc" instanceof String;
    assert true instanceof Boolean;
    Object object = new MyInterface() { ... };
    assert object instanceof MyInterface;

• Add jsweet.util.Globals.typeof helper method to generate the typeof JavaScript operator:

    assert typeof("abc") === "string";

• Change the == operator semantics to be closer to Java

    o1 == o2; now generates: o1 === o2;
    o1 != o2; => o1 !== o2;
    Because of the null/undefined duality in JavaScript, there are exceptions when comparing to null literal:   
    o == null; => o == null;
    null == o; => null == o;
    o != null; => o != null;
    null != o; => null != o;

• Better mapping of some binary operators to TypeScript (for instance XOR and arithmetic operators on chars)
• To control the use of == and === operators, add some helper methods:

    jsweet.util.Globals.equalsStrict => ===
    jsweet.util.Globals.notEqualsStrict => ===
    jsweet.util.Globals.equalsLoose => ==
    jsweet.util.Globals.notEqualsLoose => ==

• Add jsweet.util.Globals.$map helper method for easy construction of untyped maps

    $map("a", 1, "b", true) transpiles to {"a": 1, "b": true}

• Add support for labels
• Add jsweet.util.Globals.any helper method, which completely erase typing (similar to a cast in TypeScript)
• Emulate Java behavior for static field initialization and static initializers so that there are no initialization ordering issues. Static field are lazily initialized.
• Support for anonymous classes (both static and non-static).

    int i = 2;
    void m() {
        return new Comparator<String> {
            @Override
            public int compareTo(String s1, String s2) {
                System.out.println("here I can access enclosing class fields: "+i);
                return ...;
            }
        };
    }

• Support for final variables accesses from anonymous classes.

    void m() {
        final int i = 3;
        return new Comparator<String> {
            @Override
            public int compareTo(String s1, String s2) {
                System.out.println("here I can access final variables: "+i);
                return ...;
            }
        };
    }

• Default initialization of fields as expected by Java programmers (numbers are initialized with 0, booleans with false).
• Add various built-in macros to support core Java APIs:

    XX.class.getName()
    XX.class.getSimpleName()
    java.lang.Math.*
    java.lang.String.*

New bundles

• Support for much more robust TypeScript/JavaScript bundles:
  • static-based and inheritance-based permutation to ensure correct ordering of classes
  • lazy initialization of static fields to avoid ordering issues
  • fix performance issue when calculating line numbers
  • use qualified names to avoid explicit imports (which may break the bundle)

Removed features

• Strict mode removed (having J4TS and various macros implemented are two different visions that are not compatible and we do not have time to maintain both)
• Removed former bundle support delegating to Browserify

This release contains all the important transpiler features, which have been tested as much as possible.

A stable release can be used with corresponding releases of the candies. By using released candies for a given transpiler stable version, you can rely on the fact that candies will not change. You can confidently use them in long term projects.

A candy (JS library) release for release 1.0.0 is called: libname-x.y.z-1.0.0-yyyyMMdd, where x.y.z is the version of the candy and yyyyMMdd is the date at which the candy was released. Candies for stable releases will be released when necessary, but far less often as SNAPSHOT versions.

To keep being updated every day for a given candy, you should use the SNAPSHOT version of the candy: libname-x.y.z-SNAPSHOT, which follows the TSD updates on a daily basis. There is no warranty that a snapshot version keeps being compatible with a transpiler stable release, so it is advised to update the transpiler on a regular basis (or to use the latest snapshot) when wanting to follow the TSD modifications on a daily basis.

NOTE on 0.0.0 candy versions: a lot of TSD libraries do not have any version number but instead have a version called latest. In that case, the JSweet candy version is 0.0.0, which means latest.

We decided to do a RC1 before the actual release. Please test that it works for your use cases and we will release the ultimate 1.0.0 ASAP :)

IMPORTANT NOTE: candy versions in snapshots will now correspond to the actual versions on TSD. It was not the case before for some obscure reasons. This means that the old candies will eventually be deleted from our repo and that you will need to redo your dependencies (note that this is exceptional and will now be stable). For the ones wanting to use stable versions of the transpiler and of the candies (instead of snapshots), the new release and candy updating process will be fully explained when releasing v1.0.0.

Also, we added some jar packaging features to this release because it appeared like a must for production environments (check the doc's last section on packaging).