Universal Java allows developers to write code once and run it anywhere, including on servers, desktops, mobiles, and IoT devices. Java code is portable because it compiles to bytecode that runs on the Java Virtual Machine (JVM), which exists for most platforms. Some key aspects that enable portability include:
1. Separating platform-independent business logic from platform-specific UI code
2. Using common language features and libraries for cross-platform code
3. Transpiling Java to other languages like JavaScript for web apps
4. Ahead-of-time compilation to native code for better performance on devices
The document discusses strategies for writing portable Java code and provides examples using shared business
2. Disclaimer
• No advice
– This website contains general information about legal matters. The information is not advice, and should
not be treated as such.
• Limitation of warranties
– The legal information on this website is provided “as is” without any representations or warranties, express
or implied. The presenter makes no representations or warranties in relation to the legal information on
this website. Without prejudice to the generality of the foregoing paragraph, The presenter does not
warrant that:
• the legal information on this presentation will be constantly available, or available at all; or
• the legal information on this presentation is complete, true, accurate, up-to-date, or non-misleading.
• Professional assistance
– You must not rely on the information on this website as an alternative to legal advice from your attorney or
other professional legal services provider.
– If you have any specific questions about any legal matter you should consult your attorney or other
professional legal services provider. You should never delay seeking legal advice, disregard legal advice, or
commence or discontinue any legal action because of information on this website.
• Liability
– Nothing in this legal disclaimer will limit any of our liabilities in any way that is not permitted under
applicable law, or exclude any of our liabilities that may not be excluded under applicable law.
• This legal disclaimer
– This legal advice disclaimer is based on a free SEQ Legal form. SEQ Legal also supply premium forms
including email disclaimer forms
3. About the Speaker
Philippe Riand
– CTO of Trilog Group and Darwino
– Former application development
chief architect for IBM Collaboration
Services
– Chief architect, and inventor, of IBM
Domino XPages
– Author of many OpenNTF projects
4. About Darwino
A distributed app-development platform for the rapid creation of
collaborative applications (primarily Mobile, Cloud and IOT).
– Facilitates focus on the application logic;
– Encapsulates services within comprehensive and portable APIs;
– Incorporates an advanced JSON document store (atop of RDBMS),
both mobile and server;
– Enables synchronization (aka, replication) from Enterprise systems
and provides a seamless offline capability;
• Have a built-in, high fidelity, 2 way replication connector with IBM
Domino
– Java-based, and uses familiar constructs, UI.
5. Agenda
• Why Java?
• Java Pieces
• Writing Portable Code with Java
• Use Cases and Demos
• Conclusion
7. Why Java?
• As a language/platform
– Java is the one of the most popular and used language
– Java virtually runs on every platforms, albeit some differences
• Server, desktops, mobile, IOT
– Java has the biggest ecosystem, set of libraries and development
tools
– The JVM and runtime libraries can run several other languages
• For the enterprise
– Scales well in term of team size
– Libraries are Enterprise level code (Apache, Google Core…)
– Strong security model
– Error handling prevents crashes
– Easy to find skills on the market
11. Java Languages
• At the beginning, Java is a programming language
– Defined by the JLS, Java Language Specification
– Originally compiles to byte code, for the JVM
– Depends on a minimum runtime library (ex: String, Class…)
• Many scripting languages are running on the Java platform
– JavaScript (Nashorn), Ruby, Python…
– Byte code has been enhanced to better support scripting languages
• General purposes/functional languages
– Groovy, Scala, Kotlin, Clojure
– Even Swift (RemObject Silver), C#...
• The languages targeting the Java platform can share the libraries
and interact with each other
12. Main Execution Platform : Java JVM
• The stock Java compiler generates byte code
(“.class” files) that will be then executed by the
Java Virtual Machine. Class files can eventually
be aggregated into archive files (.jar)
• The byte code can be interpreted or on the fly
converted to machine code by the JVM (this is
called “just in time compiler”)
• There are many JVM implementations available
for a wide range of operating systems (IBM J9,
Oracle VM, …), as well as many other open
source implementations
– Oracle’s is now open source through OpenJDK
– IBM’s is being open sourced
Source Code
Class HelloWorld {
…
public static void main() {
…
}
}
0A F5 89 19 … 7F 3C
Byte Code
Java HelloWorld
JVM
13. Execution Platform : Android VM
• Google introduced a new byte code
format for Android called “dex” (Dalvik
Executable), optimized for mobile
devices
• It generates smaller files with byte
code that can be processed faster by
the JIT
– ART, released with Android 5.0 also now
pre-compiles the classes (AOT)
• The existing compiled libraries can be
used as is
• Has side effects with dynamic
languages, like Groovy, or Java libraries
containing resources
Source Code
Class HelloWorld {
…
public static void main() {
…
}
}
0A F5 89 19 … 7F 3C
Byte Code
Adb shell … HelloWorld
Dalvik/ART VM
07 6A 46 … 8F 33 15 AC
Dalvik JAR
14. Execution Platform: Transpilers and AOT
• Transpilers
– Java transpilers convert java source code to another language
• Google GWT converts Java to JavaScript
• J2OBJC converts Java to Objective “C”
• JUniversal… but abandoned by Microsoft
– Java class transpilers converts .class file to source code
• J2C, Haxe…
• Ahead of Time compilers – AOT
– AOT compilers statically generate machine code from either the
source code, or even better the compiled “.class” files
• Excelsior JET (Desktop: Windows, OSX & Linux)
• Multi OS Engine (MOE)
• Avian, RoboVM, GCJ, XMLVM…
15. Java Runtime Libraries
• Java comes with a set of classes ready to use, provided by a
runtime library implementation.
– Some are tied to the language (ex: String, Class, …). These classes
must be available in order to run a Java program.
– Some are just portable services (ex: java.io.*, java.net.*...). They are
not strictly part of the language specification, and may vary
between implementations.
– Some can be platform specific, or even JVM/target environment
specific (com.ibm.*, …)
• The use of a runtime library matters a lot as it defines the
available APIs and their behaviors
– Oracle JVM, Android… have different classes, or different
implementations of the same classes
16. The Landscape of Java Runtime Libraries
Apache
Harmony
OpenJDK
Android
Dalvik
Android ART
ART Next
GNU
Classpath
Environment
specific
- GWT, J2OBJC
- CodenameOne
- Avian
- JUniversal
- …
ART Next
- GJC
- Other OS projects
- Oracle Hotspot
- IBM J9
Sun JDK
- Android 1-4
- Android 5-6
- Android 7+
18. Writing Portable Java
• There are two kinds of code that must be separated
– The code that is platform independent (ex: business logic)
• Executed as is on all the target platforms
• Should only use common language and library characteristics
– The one that depends on the platform (ex: mobile UI)
• One set of code per platform
• That should be well isolated into specific projects
=> A typical portable application is made of several projects
– Shared code
– Target platform specific projects (or shell)
19. Native UIs Strategies
• Strategies for portable native APIs
– The minimum common denominator
• AWT
– UI frameworks written in Java
• Swing, JavaFX
• CodenameOne, Nuvos, …
– Advanced wrappers with extensions to supplement missing native
implementations
• SWT
• Directly use the native, not portable APIs
– Cocoa, Win32, Android, Qt…
• Using direct API calls: JNI, JNA
• Using advanced native API bridges: NAT/J, Bro
21. Trilog’s ProjExec: the Gantt Component
• Projects are accessed through different Pages/Component/APIs
– Have an existing Java Applet Gantt
• Need a new JavaScript implementation as Java Applet are deprecated
– Need a REST APIs exposing the business objects to remote clients
• Actions on a project carry a lot of complex business logic
– To provide the best user experience, the Gantt UI Component
should execute the business logic locally
– The same business logic should run on the server as well (REST APIs
and data integrity/security)
• We need a single implementation that runs everywhere
– Existing code is in the Java Applet
– Don’t want to rewrite it in JavaScript (cost, server technology, team
scalability…)
22. Trilog’s ProjExec: the Gantt Component
• Solution:
– The business logic is written in Java and well isolated in its own
project
• Use the common platform characteristics
• No external dependency
– Executes natively on the server and Applet, while it is
transpiled to JavaScript using GWT
• The exact same code is executed on both client and server
– The browser UI is native HTML/Javascript
• Actually, built using GWT and GXT, but straight HTML/JS can be used
– Opens the door to a pure mobile implementation
– Close to what Google does with ‘Inbox’
24. Trilog’s ProjExec: the Gantt Component
• Lessons learned
– We needed a few wrappers that abstract runtime specific APIs
• JSON, Timezone…
– Integrates well with a maven based build
– Share the unit tests between the implementations
– Java VM & transpiled JavaScript can have slight decimal
calculation differences
– GWT 2.8 features a nice new JSInterop capability to be
leveraged
26. Demo of a Multi Platform Web Hybrid Application
• Demo application targeting web browsers, Mobile and Desktop
– Application business logic shared, all in Java
– Core runtime libraries, including third party, all in Java
– Web technologies used for the application UI
– Mixed-in native UI for standard components (ex: settings dialog)
28. Pure Native UIs in Java
• Available Solutions
– CodenameOne
• Commercial and OpenSource product (GPL)
• Limited runtime library, cumbersome build and debugging process, no
interface builder…
– RoboVM
• Very efficient solution but no longer a supported product (killed by MS)
• There is a maintained branch on Github, mostly to support LibGDX:
https://github.com/MobiDevelop/robovm
– 1 Yr old code based, with missing features (debugger, interface builder…)
– We contributed some code (maven integration…)
– Multi OS Engine (aka Intel INDE or Intel MOE)
• Acquired by Intel in 2015 from Migeran
• Now fully open source, under the Apache 2.0 license
– https://github.com/multi-os-engine, https://multi-os-engine.org/
29. Open Source Multi OS Engine
• Features
– Targets iOS & Android, more to come!
– AOT & Android ART VM interpreter
– On Device Debugging Support
– Android studio integration
– Java to Native Binding NAT/J
• Automatic Native Binding Generation
• Access Objective-C Language Features in Java
– Android & iOS Interface Builder Integration
• On the work:
– Eclipse integration
– Maven integration
32. Other Areas for Java
• Java is part of IoT’s future
– Samsung ARTIK
• IDE powered by Eclipse Che
• Extensive Java SDK
– Intel MOE makes it possible to target IoT
• Easy for any POSIX compliant OS
– Google Brillo, Fluschia
• Highly portable to other systems
– Java transpilers targeting IoT devices
• C++ transpiler – to be released to darwino.org (OpenNTF)
• And Games…
– LibGDX
– jMonkeyEngine
33. Multi-platform Java: What Technologies to Use?
• Server
– JVM
• Desktop
– JVM
– AOT (MOE, Jet, RoboVM)
• Android
– Native Dalvik/ART VMs
• iOS
– AOT (MOE, RoboVM, Avian…)
– Transpiler (j2objc)
• HTML
– GWT (JSweet…)
• Oracle: Mobile OpenJDK 9 with “zero interpreter” for iOS. AOT
might be in progress