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