Skip to content

Latest commit

 

History

History
42 lines (29 loc) · 1.73 KB

limitations.md

File metadata and controls

42 lines (29 loc) · 1.73 KB
Raw

Limitations of J2CL - Java compatibility

[comment]: # TOC

No Support for Java Reflection

J2CL does not support any of java.lang.reflect.* or any kind of runtime class, object introspection including all methods on java.lang.Class that return java.lang.reflect objects.

The main reason is that code that uses reflection hinders global dead code removal. On the other hand code generation could be a substitute for many tasks that would normally be accomplished by the use of reflection.

No Support for Enum Reflective APIs

J2CL doesn't support Class.getEnumConstants and Enum.valueOf APIs.

No Bound Checks on Array Access

J2CL doesn't perform bound check for array accesses. J2CL promises minimal to no overhead for using language primitives to discourage people from writing native code for simple stuff only for performance considerations. Having JavaScript-like array semantics help that story.

Limitations of JRE Emulation

J2CL emulates a substantial portion of the Java Standard Library (a.k.a JRE). However it's not feasible nor practical to support all of the APIs in the web platform; APIs like java.net.* are intentionally left out.

Shared code that uses these APIs can work around this limitation by super-sourcing the classes and providing an alternative implementation specific for J2CL.

Minor Semantic Differences

  • Switch on enum type does not trigger class initialization (clinit). Although JLS §12.4 does not explicitly require switch to trigger class initialization, both javac and ecj generate code that does, but J2CL generated code does not.