Native apps with Java

Tomáš Zíma tomas at tzima.cz
Fri Apr 29 15:06:42 UTC 2016


Hi,

While transcompilation from Java bytecode to native machine code is 
theoretically possible, there are some glitches that render it rather 
impractical in my opinion.

The most simple approach (and also most reliable for that matter) would 
be to implement a light-weight JVM and pack precompiled *.class files 
directly to its binary. Such light-weight JVM would probably perform 
really slow compared to standard "full" JVM, but this way "all Java" 
would work normally.

Other approach is to deeply analyze Java source code or compiled 
bytecode and generate optimized native code. It is, however, a little 
more complicated than that because such transcompiler would have to 
consider things such as these and come with an appropriate solution:
   * reflection
   * dynamic class loading (note: it IS possible to define class from 
bytecode at runtime using a custom ClassLoader)

Speaking of second point, we come to an understanding that, at some 
cases, generated native code would have to contain bytecode interpreter 
(JVM).

One would also have to include/link all library code that is used, 
including the native code (via JNI), to the generated binary.

Implementing a full transcompiler which would in all possible cases 
behave exactly the same as standard JVM, is extremely difficult and we 
would probably end-up having something like JVM-with-bytecode-included 
at some cases anyway, without gaining any, or near any, performance boost.

Incomplete implementation, something like a strict subset of Java, is 
rather simple, but would it actually be useful? I'm afraid not. 
Unfortunately, for platforms or environments where JRE is not possible 
or desirable to install, Java is not a platform of choice. Use something 
else instead.

Best regards.
- tzima

On 29.4.2016 12:55, Behrang Saeedzadeh wrote:
> Hi,
>
> First, apologies if this is not the best place to discuss topics of this
> kind (if it is not, could you please point me to the correct mailing list?)
>
> But isn't it the time for it to be possible to build *native* Java apps
> that can be submitted to Mac App Store, iOS App Store, Windows App (?)
> Store, and potentially software centers of various Linux distros?
>
> * RoboVM is almost dying
> * Today I just learned about Gulon (gluonhq.com <http://t.co/KmtoyHxriE>),
> but it depended on RoboVM's compiler
> * Some time ago Fernando Cassia (via this mailing list) pointed me to
> ExcelsiorJET
> and JWrapper (and looks like he also had mentioned Gulon too)
>
> It is now possible for C#, Ruby, and JavaScript developers to build native
> mobile and desktop apps with Xamarin, RubyMotion, React Native, React
> Native Desktop (https://github.com/ptmt/react-native-desktop), etc. but
> there's not a reliable way to build native desktop/mobile apps with JavaFX.
> As I mentioned earlier RoboVM is almost dead, Gluon depended on it, etc.
> etc.
>
> I wish Oracle (maybe with the help of other JCP members or Java
> stakeholders) could build a free or commercial tool to fill this void.
>
> I want to build a JavaFX based app that has native-like performance and
> memory footprint and submit it to Mac App Store but the options are not
> that many or are very expensive.
>
> Just my $0.02.
>
> Best regards,
> Behrang Saeedzadeh




More information about the discuss mailing list