Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
VJET/Java2Js Language Translation Reference
Contents
- 1 Introduction
- 2 Overview
- 3 Language Translation
- 3.1 Lexical Structure
- 3.2 Types, Values and Variables
- 3.3 Conversions and Promotions
- 3.4 Names
- 3.5 Packages
- 3.6 Classes
- 3.7 Interfaces
- 3.8 Arrays
- 3.9 Exceptions
- 3.10 Execution
- 3.11 Binary Compatibility
- 3.12 Blocks and Statements
- 3.13 Expressions
- 3.14 Definite Assignment
- 3.15 Threads and Locks (not supported)
Introduction
Purpose
This document captures language reference for Java to JavaScript translation.
Java to JavaScript project started with a mission to enable Java Active Programming that allows developer to implement, run and debug end-to-end web applications within server-side IDE, such as Eclipse. Developers can leverage the power of Java language, JDK and Java IDE to manage complex web applications with rich client-side behavior.
Java to JavaScript translation can also be leveraged when any server-side functionality need to be shared or moved to client-side.
Definitions/Terminology
Language Feature: In this document, anything that is intrinsic to language or its runtime is referred to as language feature.
VJO:
JST: A tree-structured, syntactical representation of VJO sources.
JSR: A Java proxy of VJO
VJET: An IDE plug-in for VJO authoring and debugging.
AST: A tree-structured, syntactical representation of Java sources.
Scope
The focus of this document is the language features relating to Java to JavaScript translation. The supported language versions are:
Source:
Java 1.5 (Ref [1])
Target:
JavaScript 1.5 (Ref [2])
VJO 1.3? (Ref [3])
Information about translation engine is provided in Ref [7].
References
- Java Language Reference 3rd Edition
- Java Script – The Definitive Guide
- VJO Language Reference
- JST Doc
- JSR Doc
- VJET User Guide
- Java to JavaScript Translation System Reference
- Java to JavaScript Language Translation References
Overview
Translation Objectives
- Maximize supported Java language features
- Maximize syntactical and structural resemblance
- Maximize semantic equivalence
Translation Target
JavaScript is an interpreted programming language with object-oriented capabilities. Syntactically, the core JavaScript language resembles C, C++ and Java, with programming constructs such as if statement, while loop, and && operator etc.
However the similarity ends with the syntactic resemblance in expressions and statements. JavaScript is a dynamic language with loose typing. Its inheritance is prototype-based, not class-based. To largely keep the Java language features when translating to JavaScript, some of the gaps need to be filled to bring JavaScript closer to Java, both structurally and semantically.
VJO is a JavaScript-based runtime that has been enriched with many language features that are equivalent to Java. It supports class, abstract class, interface, and enum types, with access control. It supports type-based inheritance, embedded types, local types as well as anonymous types. For details of VJO language features please refer to Ref [3].
VJO also comes with an authoring tool, a.k.a VJET, which is an Eclipse plug-in that provides code completion, syntax validation, hierarchy and reference searches, refactoring, as well as runtime debugging functionalities inside Eclipse. Please refer to Ref [6] for a complete feature set of VJET.
In summary, choosing VJO as Java to JavaScript translation target brings following benefits among others:
- It narrows the gap between Java and Java Script, enabling more Java language features to be supported, and translated with more structural resemblance and semantic equivalence.
- The translated code is developer-friendly, easy to read and debug, as well as directly code with.
- It makes translation easier.
Translation Process
During Java to Java Script translation, Java sources are first translated into JST, a tree-structured, syntactical representation of VJO, documented in Ref [4].
From JST, we can generate VJO as well as JSR. JSR represents server-side proxy of client-side Java Script, as documented in Ref [5].
JST is also used in VJET parser and type space, to facilitate parsing, code completion, searching and refactoring of VJO sources.
Following diagram shows supported translation and code generation paths:
The schematic view of Java to VJO translation process is shown below:
Controller is the entry point for translation. It’s also the integration point for build and IDE plug-in. The entire process involves mainly following steps:
- Parsing – Parse Java source into AST, an abstract syntax tree representation of Java
- Translation – Translate AST to JST
- Post translation processing – additional processing on JST
- Code generation – generate VJO and JSR from JST
- Validation – validate generated VJO and JSR
Error may happen in each step. The translation engine will try best to continue the translation. However, please be aware that translated result will be incomplete or incorrect due to those errors.
For more details, please refer to Ref [7], Java to JavaScript Translation System Reference.
Translation Prerequisites
Java to JavaScript translation is based on Java and Java language references (Ref[1], and Ref [2]), as well as VJO language reference (Ref [3]).
To ensure a valid translation, following are required:
- Java source code must not have any compile-time errors.
- Java to JavaScript translation relies on Java compiler to catch any Java syntax errors in Java source code. Java to JavaScript translation will not perform any Java syntax check.
- Build system should not start translation if Java compilation fails.
- Java source only uses supported Java language features as described in Chapter 3 and Ref [8]
- Error message will be produced if any non-supported Java language is encountered during translation. Translation errors are discussed in a later section.
Supported Java Language Features
Supported Java language features are translated in one of following ways:
- Directly mapped to JavaScript syntax that has same semantics as in Java.
- For example, while loop statement can be directly translated to JavaScript.
- Java: while (x > 0){……}
- JavaScript:while (x > 0){……}
- Directly mapped to VJO syntax that provides equivalent semantics as in Java.
- For example, JavaScript doesn’t support class and interface. Java classes and interfaces are mapped to VJO ctype and itype.
- Java: package x,y,x;
- public class A {……}
- JavaScript:vjo.ctype(x.y.x.A) {……}
- Direct translation doesn’t produce same behavior; however the behavior can be simulated in JavaScript.
- For example, in Java, integer literal 1 divided by integer literal 2 produces 0. In JavaScript, same division produces 0.5.
- To keep same semantic behavior, JavaScript parseInt function is included in the translated code to ensure equivalent behavior.
- Java: int x = 1/2;
- JavaScript:var x = parseInt(1/2);
- Direct translation doesn’t produce same behavior; however the behavior can be simulated in VJO.
- For example, Java runtime auto boxing and unboxing are simulated in VJO
- Java: Integer x = 10;
- JavaScript:var x = new vjo.java.lang.Integer(10);
Following are examples of supported Java language features:
- Class, interface, and enum types
- Class and interface inheritances
- Generic
- Embedded classes and interfaces, local classes and anonymous classes
- Static and instance initializers
- Method overloading (with exceptions)
- Majority of statements, expressions, and operators
Please note that some features are simulated in VJO comments, such as Generics, final modifier etc. VJO comments provide hints to VJET to enforce certain VJO syntax, as well as to JSR generator. VJO comments can be suppressed (via configuration, Ref [7]) when needed, for example, minimize page weight when deploying JavaScript to browser.
List of all supported Java language features can be found in Chapter 3 and more details are provided in Ref [8].
Non-supported Java Language Features
Non-supported Java language features fall into one of following categories:
- It’s not supported due to intrinsic JavaScript limitation.
- For example, multiple thread related features
- It’s not supported in AST Parser
- For example, comments are not kept in AST which is the input data of Java to JavaScript translation.
- It’s not supported today but could be supported in future releases
- For example, assert, annotation
An error should be generated, with line number and message, when any of non-supported features is encountered during translation.
Examples of Non-supported Java Language Features
Java Language Feature | |
| ||
|
|
| ||
Threads and Locks | |
|||
Object Finalization | |
|||
Strictfp | |
|||
Throws clause in method and constructor declarations | | |||
Checked exceptions | | |||
Runtime check of semantic violation and exception throwing | |
|||
Annotation types | | |||
Annotation | | |||
Assert | | |||
JDK | | |||
Comment | |
List of Features that are Supported with Constraints
- Identifies – avoid using JavaScript and VJO keywords and reserved words
- Array – avoid using any inherited Object features with array.
- Enum --
- Char
- Avoid using it as numeric type.
- Avoid using char arrays as mutable
- Inheritance – avoid declaring class or interface fields that hide inherited fields. Same apply to methods and embedded types.
- Constructors and methods:
- Avoid using same name across fields, methods and embedded types
- Avoid using overloading with signature only differ by primitive types or array element types
- Generics – avoid unchecked conversions with generic types
Open Issues
- Java Array is mapped to JavaScript array. Its behavior as an Object is lost
- toString may have different behavior
- Array of primitive types created with default value
- Array runtime check (Out of bound exception)
- Mutable char array
- Narrowing reference conversion simulation
- Implicit methods such as for enums and interfaces
public class Test { public int foo(IX x){ return x.hashCode(); } interface IX{ } }
- interface overriding/hiding with matching sub-signiture
- Statement abrupt completion behavior – need to verify
Translation Errors
Error Messages
Error Severity
Language Translation
This chapter provides high-level view of Java to JavaScript translation. The sections are corresponding to sections in Java Language Reference 3rd Edition (Ref [1]).
Within each section, there is a table showing whether the feature(s) are supported or not, and how if supported. Following the table is a list of notes to provide some highlights.
Complete coverage with detailed descriptions and samples can be found in Ref [8].
Detailed about VJO features and behaviors can be found in Ref [3].
Lexical Structure
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Comment | | ||||
Identifiers | |
| |||
Keywords | |
|
| ||
Literals | |
||||
Separators | |
||||
Operators | |
||||
Please note:
- As discussed in Translation Process section, Java to JavaScript translation starts from AST, therefore, features that relates to Java source parsing are not included in the table above. For example, Unicode, Unicode escape, line terminators, input elements and tokens, white spaces etc.
- Along the same line, as current version of AST Parser doesn’t support comments, Java comments are not translated to VJO.
- Java identifiers are mostly supported except the keywords reserved in JavaScript and VJO.
- Regarding Java keywords, some are mapped to JavaScript keywords, some are mapped to VJO, and rest is not supported. For example:
- To JavaScript: boolean, void, continue, break, if, else, while, switch etc.
- To VJO: import, class, interface, abstract, enum, extends, implements etc.
- Not supported: assert, synchronized, transient, volatile, native etc.
- Java literals are all supported and mapped to JavaScript literals.
- The operators listed in Section 3.12 of Java Language Reference 3rd Edition are all supported and mapped to JavaScript operators. However, there are other operators discussed in different sections, we’ll follow the same. Examples are cast and instanceof operators.
Types, Values and Variables
Data types in Java can be categorized into primitive types, JDK defined types, and user defined types.
All Java primitive types are supported and mapped to JavaScript native types, such as number, boolean and String. User defined types are supported as long as they only depend on supported Java language features.
JDK translation will be covered in a separate reference.
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Primitive Types & Values | |
||||
Reference Types & Values | |
|
|||
Type Variables | |
||||
Parameterized Types | |
||||
Sub-typing | |
| |||
Variables | |
|
|
||
Please note:
- Java primitive types are all mapped to JavaScript primitive types, with exception of char which is mapped to JavaScript String.
- Java Object is mapped to VJO Object. However, only a subset of methods is supported. For example, equals(), hashCode() and toString().
- Java String is mapped to JavaScript String. The Java String methods that are not supported in JavaScript String are simulated in VJO via VJO StringUtil.
- Java reference types, except Object, String and arrays, are mapped to VJO reference types, including JDK types which will not be in the first release though.
- Java generics are simulated in VJO comments. VJO comments can be suppressed for performance via configuration (Ref [7]).
- Sub-typing is supported in VJO. Just be aware that array related sub-type is not supported, as arrays are mapped to JavaScript Array.
- Local variables are mapped to JavaScript variables. Static and instance variables are mapped to VJO static and instance properties. Access control and final modifiers on variables are simulated in VJO comments.
- Type Erasure, Reifiable Types, Raw types and Intersection Types are not included in the above table.
Conversions and Promotions
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
| |||||
Identity Conversion | |
|
|||
Widening Primitive Conversion | |
||||
Narrowing Primitive Conversion | |
||||
Widening Reference Conversion | |
||||
Narrowing Reference Conversion | |
||||
Boxing Conversion | |
||||
Unboxing Conversion | |
||||
Unchecked Conversion | | ||||
Capture Conversion | | ||||
String Conversion | |
||||
Value Set Conversion | | ||||
| |||||
Assignment Conversion | |
|
|
||
Method Invocation Conversion | |
|
|
||
String Conversion | |
||||
Cast Conversion | |
|
|
||
Numerical Promotions | |
|
|||
Regarding conversion types:
- Widening primitive conversion is naturally supported in JavaScript. The only exception is char.
- Narrowing primitive conversion is simulated in JavaScript via native functions such as parseInt etc.
- Widening reference conversion is naturally supported in VJO.
- Narrowing reference conversion is simulated in VJO during translation via VJO cast utility, which should perform check during runtime whether the actual reference value is a legitimate value of the new type. If not, an exception equivalent to ClassCastException should be thrown.
- Boxing conversion is simulated in VJO during translation, by wrapping primitive expressions with corresponding wrapper type instance in VJO.
- Unboxing conversion is simulated in VJO during translation, via VJO unboxing utility which will return a primitive value from its wrapper type instance value. If the wrapper type instance is null, an exception equivalent to NullPointException should be thrown.
- Unchecked conversion is not supported, same for any other conversion that involves possible heap pollution, such as Capture conversion.
- String conversion is naturally supported in JavaScript for both translated primitive and VJO types.
- Value Set conversion is not supported.
Regarding conversion contexts:
- Assignment conversion are supported, depending on the type of conversion, it is either mapped directly to JavaScript, or simulated in JavaScript or VJO.
- Same applies to Method Invocation Conversion.
- In Java, there is only single special case of String conversion, which behaves same as in JavaScript. So it’s naturally supported.
- Casting conversion is simulated in JavaScript or VJO via JavaScript native functions or VJO utilities.
- Numerical promotion is supported, either naturally mapped to JavaScript, or simulated in VJO.
Names
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Declarations | |
|
|||
Names and Identifiers | |
|
|||
Scope of a Declaration | |
|
| ||
Members and Inheritance | |
|
| ||
Access Control | |
||||
Fully Qualified Names and Canonical Names | |
|
Please note:
- Scoping rules are quite different between Java and JavaScript, as well as between Java and VJO.
- Members of Java class or interface, declared or inherited, are all in scope, however:
- Instance members in JavaScript must be scoped with this inside instance member functions
- Inherited instance members in VJO must also be scoped with this or base.
- Static members in VJO can always be accessed via this.vjo scope, or just scoped with this when accessed from static member functions.
- Inherited static members in VJO must be accessed via either fully qualified name or VJO short-hand scope which is setup by VJO runtime.
- Embedded members in VJO are also scoped based on VJO rules. Please refer to VJO language Reference for more details.
- Shadowing and Obscured Declaration become specific after translation, benefiting from JavaScript and VJO scoping rules. However,
- Current VJO runtime doesn’t support field declaration with name conflict with inherited fields. Same apply to methods and embedded types.
- Members and Inheritance:
- Members of type parameters are fully mapped to VJO comments
- VJO package is mainly a name space, currently there is no semantic behavior associated with it. Not like in Java, types under same package need to be explicitly added to need list in VJO if the type is referenced directly.
- Class and interface members are fully mapped to VJO equivalents.
- Java arrays are mapped to JavaScript Array. Therefore, array members inherited from Object are not supported.
- Java member access control are simulated via VJO comments and enforced via VJET
- Fully qualified naming are directly translated to JavaScript or VJO
- Determine the Meaning of the Name is more related to Java source parsing, so it is not included in the above table.
- Same naming convention is recommended whenever it applies. However, it has no direct impact on translation result.
Packages
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Package Members | |
| |||
Compilation Units | |
|
|||
Package Declarations | | ||||
Import | |
|
|||
Top Level Type Declarations | |
||||
Please note:
- VJO package mainly provides qualifying name space for types. Some Java package related features are simulated in VJO during translation. For example:
- Include translated java.lang types in VJO need list if directly referenced within the type.
- Include types within same package into VJO need list, if directly referenced within the type.
- Compilation Unit doesn’t apply to JavaScript or VJO. Non-public types defined within same compilation unit are mapped to separate VJO file, with access control mapped to VJO comments and enforced via VJO.
- There is no explicit package declaration in VJO. Java package name are combined with simple name of the type and form a fully qualified type name.
- In Java, an import declaration makes types available by their simple names within the compilation unit that contains the import declaration. In VJO, the equivalent need declaration makes types available by their simple names prefixed with this.vjo within the type that contains the need declaration
- Static imports are supported. The references to statically imported fields and methods are translated to following normal VJO static field and method referencing rules.
- On demand imports with are also supported. The referenced types will be added to the need list of VJO type.
- Host Support for Packages has no direct impact on how Java languages are translated to JavaScript. So it’s not included in the above table.
- Same package naming convention is recommended whenever it applies. However, it has no direct impact on translation result as long as there is no naming conflict.
Classes
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Class Declaration | |
|
| ||
Class Members | |
||||
Field Declarations | |
|
|||
Method Declarations | |
|
| ||
Member Type Declarations | |
||||
Instance Initializers | |
||||
Static Initializers | |
||||
Constructor Declarations | |
|
| ||
Enums | |
|
Please note:
- Strictfp is not supported.
- Java class is mapped to ctype in VJO.
- Java class modifiers are mostly simulated in VJO comments. strictfp is not supported.
- Type parameters are simulated via VJO comment.
- Embedded types are mapped to VJO embedded types, accessed via VJO name space scheme. The syntax to instantiate inner types is also different.
- Super-class is mapped to VJO super class
- Super interfaces are mapped to VJO super interfaces
- Java class body is mapped to VJO props, protos and inits blocks respectively.
- Java class members can be completely mapped to VJO equivalents.
- The way to access inherited members in VJO is similar as in Java. The two major differences are:
- For inherited instance members, it can be accessed via simple name directly or via this.base.
- For inherited static members, it needs to be accessed always via declaring type in VJO.
- The way to access member types is different in VJO. Please refer to VJO language reference for more details.
- The way to access inherited members in VJO is similar as in Java. The two major differences are:
- Field declaration is translated to VJO properties.
- The modifiers and type of the fields are simulated in VJO comments
- Field initializer with constant value is mapped to property value.
- Static field initializer with an expression is simulated at the beginning of the inits block
- Instance field initializer with an expression is simulated at the beginning of the constructor
- Primitive field declaration without an initializer is mapped to property with default value as in Java
- Variable arguments in method and constructor declaration are simulated in JavaScript.
- Method and constructor overloading are simulated in VJO via dispatching based in parameter types, however
- It’s applied when and only only when there are more than one instance methods with same name, or more than one static method with same name. That means it’s valid to have one static method and one instance method share same name. Same rule applies to constructor
- It doesn’t work in cases when the parameter types only differ in primitive numerical types or differ only in array element types.
- In dispatching condition, any type parameter is mapped to VJO Object for instance type check
- If none of dispatching conditions is satisfied, the translated code will check base for any overloaded method
Question: how to handle runtime error
- Java constructor is mapped to single constructor in VJO. In case there are more then one Java constructor, same dispatching approach is used, with same limitations.
- throws clause in Java method and constructor declarations are not supported in VJO.
- Instance field initializer and instance initializers are translated and moved to the beginning of the constructor. If there is no constructor defined in Java, a VJO constructor will be created. And same execution order in Java is kept in translated VJO.
- Static field initializers and static initializers are translated and moved to inits block. Same execution order in Java is kept in translated VJO..
- Java enums are mapped to VJO enums
- Implicit static methods of Java enum (values() and valueOf(String)) are mapped to VJO equivalents.
- The optional class body of an enum constant which implicitly defines an anonymous is not supported in the first release
Interfaces
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Interface Declarations | |
|
| ||
Instance Members | |
||||
Field (Constant) Declarations | |
|
|||
Abstract Method Declarations | |
||||
Member Type Declarations | |
||||
Annotation Types | | ||||
Annotations | |
Please note:
- Strictfp is not supported
- Similar translation that applies to Java classes applies to Java interfaces, as long as the same feature is supported by both Java class and interface. For example,
- Type parameters are simulated in VJO comments
- Field initializer is mapped to inits block
- Java interface has implicit methods as defined in Object. Those implicit methods are not translated, but will be provided in VJET code completion.
- Annotations are used for custom translation. But it’s not mapped to VJO
Question Do VJO/VJET: support interface overriding/hiding with matching subsigniture?
Arrays
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Array Types | |
| |||
Array Variables | |
||||
Array Creation | |
| |||
Array Access | |
| |||
Array Initializers | |
||||
Array Members | |
| |||
Class Objects for Arrays | | ||||
Mutable char array |
Please note:
- Java arrays are mapped to JavaScript Array. That means any usage of Java arrays as Java Object is not supported, unless explicitly stated. For example:
- Object inheritance and clone are not supported
- toString() has different behavior
- Java arrays are created with elements initialized with type-specific default values. For example, int array will be filled with zeros. This behavior is simulated in VJO via array creation utility.
- What about OutOfBoundIndexException
- Java array initializers are directly mapped to JavaScript array initializer
Question: mutable char array
Exceptions
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
The Cause of Exceptions | |
|
| ||
Compile-time Checking of Exceptions | | ||||
Handling of an Exception | |
|
|||
The Exception Hierarchy | |
Please note:
- Java has many runtime check of semantic violation. Some of them can be simulated in JavaScript; some can be simulated but may not be efficient, the others just can’t. For example:
- 1/0: Java throws exception, which can be simulated in JavaScript by wrapping it inside a JavaScript utility function.
- Array index out of bound: Java throws exception, JavaScript returns undefined. It’s possible to warp each array element access into a JavaScript utility function, but that is not efficient.
- ???
- Some of Java exceptions or errors occur during class loading, linking or initialization. VJO runtime can provide equivalent behavior to throw runtime exceptions.
- Checked exceptions are not supported, as throws clause is not supported in VJO constructor and methods.
- Multiple catch blocks are simulated with multiple if-else blocks inside a single catch block
- Java Throwable, Exception, Error, and RuntimeException are mapped to VJO equivalents. Application defined exceptions can be translated as other Java sources that satisfy translation prerequisites.
Execution
Java Virtual Machine | |
| |
|
| ||
Loading of Classes and Interfaces |
| ||
Linking of Classes and Interfaces | |
||
Initialization of Classes and Interfaces | |
| |
Creation of new Classes and Interfaces | |
||
Finalization of Class Instances | | ||
Unloading of Classes and Interfaces | |
Please note:
- This section is about runtime execution, mostly relating to class and interface life cycle, which includes class loading, linking, initialization, creation, finalization and unloading, performed by JVM.
- All translated VJO types are loaded as normal JavaScript sources, linked, initialized, and instantiated by VJO runtime.
- VJO RT provides verification and resolution but Static fields are not initialized with default values
- There is no equivalent mechanism in JavaScript as Java finalizer. This is JavaScript language limitation that cannot be simulated in VJO runtime.
Please refer to Ref [3] for more details about VJO type life cycle..
Binary Compatibility
Blocks and Statements
Java Language Feature | |
| |||
|
| ||||
|
|
|
| ||
Normal and Abrupt Completion of Statements | |
| |||
Blocks | |
||||
Local Class Declarations | |
|
| ||
Local Variable Declaration Statements | |
|
|
| |
The Empty Statement | |
||||
Labeled Statements | |
| |||
Expression Statements | |
||||
The if Statements | |
||||
The assert Statements | | ||||
The switch Statements | |
||||
The while Statements | |
||||
The do Statements | |
||||
The for Statements | |
|
|||
The break Statements | |
||||
The continue Statement | |
||||
The return Statement | |
||||
The throw Statement | |
||||
The synchronized Statement | | ||||
The try Statement | |
|
|||
Please note:
- Normal and abrupt completion of statements in JavaScript behaves very similar as in Java, except:
- Evaluation of certain expressions may throw exceptions from the JVM, some may be simulated in VJO some doesn’t. Details are discussed in expression section.
- Block in Java and JavaScript are almost same except scoping. As Java scoping is more restrict than JavaScript, so translation works fine from Java to JavaScript, but not the reversed direction.
- Local class declaration is supported in VJO, except annotation
- Local variable declarations are translated to JavaScript variable declaration. However,
- The modifiers and type of the variable is simulated in VJO comments, as hint for VJET to provide equivalent syntax validation in compile time.
- Annotation is not supported.
- Most Java statements are directly translation to JavaScript statements, except:
- The enhanced for statement is simulated in VJO.
- The multi-catch statement is simulated with if-else statement within single catch statement.
- assert and synchronized statements are not supported.
Expressions
All Java expressions are supported, including arithmetic expressions, logical expressions, conditional expressions, assignment expressions, and method invocations etc.
Most of Java expressions can be directly translated to JavaScript expressions; however, there are some exceptions, especially relating to arithmetic and assignment expressions that involves conversion and promotion.
For example, cast expression is not supported in Java Script. Custom translation is needed to produce equivalent behavior.
Java: float f = (float)1/2;
JavaScript:var f = vjo.java.lang.Util.cast(1,'float')/2;
where vjo.java.lang.Util is an util class provided by VJO library.
Definite Assignment
All Java operators are supported, including arithmetic operations, logical operators, relational operators, conditional operators, and special operators such as instanceof .
Most of Java operators can be directly translated to JavaScript operators; however, there are some exceptions.
For example, in Java, int 1 divided by int 2 produces int 0. In JavaScript, 1 divided by 2 produces 0.5.
To keep same semantic behavior, JS parseInt function is included in the translated code to ensure equivalent behavior.
Java: int x = 1/2;
JavaScript:var x = parseInt(1/2);