Interesting project, nice work 8)
I see that the code contains some android source, what’s that used for?
I recently started using JSweet for running java in the browser and it has worked well. Though I’m quite hopeless at using it, mostly because I’m a javascript noob.
Due to Oracle not actively developing the java client side graphics and UI libraries Swing and JavaFX, the future-proof alternative is to run things in the browser which requires no installation and has webGL via javascript.
Can you explain how your project is different to these existing frameworks?
JSweet http://www.jsweet.org/
Google’s GWT http://www.gwtproject.org/
Or Google’s new J2CL https://github.com/google/j2cl
Thanks for response.
Android is just a trial to parse a dex file (basically a jar file, but better organized). Maybe sometime it will be able to run Android apps.
Thanks for the projects, I knew about GWT. My project is more like it as jsweet. It runs the originall java application. It prints even usual java stacktraces on crash.
Interesting thing is, that the JVM programmed in Javascript does not need a heap and therefore no garbage collector is needed: it can store the objects directly in the local variables array of the Frame instead of the pointer to the heap.
So you just delegate the garbage collector task to the browser.
Wow, your skills and investigations have let you explore and master the deep internals of the JVM, impressive. You might be interested in Emscripten which looks like it might be the most performant way to run code in the browser. Our very own @KaiHH (httpdigest) looked into it a few years ago. There’s some interesting dialogue here:
Of course your project wouldn’t compile and run Swing or AWT using javascript, so I assume that it only does ‘headless’ things for now, outputting System.out.println?
Is it or would it be possible to manipulate the HTML DOM from Java code? Can you call javascript libraries such as webGL or Three.js from your Java code? JSweet does this, but the JS library must have a sort of stub of java classes compiled to mirror it which makes it a bit cumbersome since you often can’t simply use these existing JS libraries, some prior setup is required which I’m yet to figure out.
Would be interesting to know where you intend to take this project considering that JSweet and other solutions already exist.
I’m not saying that you’ve pointlessly re-invented the wheel, because there is clearly an evolution in the Java -> Javascript transpiler landscape with Google moving focus from GWT to J2CL (as well as Go and Dart) and then also JSweet and https://www.openxava.org/ are somewhat popular too so there’s many competing ideas about the best way to overcome the shortcomings of javascript’s tooling and confusing language features.
I could port swing to it. Maybe sometime. But for now there is a DOM-manipulation Library which has similar methods known from javascript (getElementById, createElement, etc). It has also webgl-bindings. The example project shows a 3D Cube rendered with webgl. That is why I posted it here: you could port opengl-games to browser.
Some advantages to do it in Java would be:
you can use all the tools avaliable for Java development.
the JVM could automatically optimise the code (method inlining, redundancy removement) even before a Browser do further Javascript optimisations.
Emscripten is also an interesting topic. Currenty I am developing a further JVM implementation with plain C. This impelementation actually needs a Garbage Collector. Maybe it could be compiled to webassembly than…
EDIT: I am planning to implement the JDWP (Java Debuging Wire Protocol). With this you could debug the Java-Application with an IDE (for Example intellij) while it is runnig in the browser.
Maybe a little bit offtopic and a slightly different usecase: I recently used vaadin flow for a project which lets you build an entire webapp with pure Java. No HTML or CSS required. My guess would be that they recreated the entire DOM in Java to make that work. I like it for prototyping but from my experiences it is often a pretty big black box.
Ok, TeaVM is actually convincing. Thank you for the tip. It has an interesting multithreading approath:
“TeaVM supports threads. JavaScript does not provide APIs to create threads (WebWorkers are not threads, since they don’t allow to share state between workers). TeaVM is capable of transforming methods to continuation-passing style. This makes possible to emulate multiple logical threads in one physical thread. TeaVM threads are, in fact, green threads.”.
Earlier there was a posibility to have sharedmemory between webworkers in JavaScript (SharedArrayBuffer), but this feature was dropped because of the meldown and spectre vulnerabilities.
The tooling benefit, that’s a big plus. But I can’t see how it’s possible to take advantage of Java hotspot VM optimisations and JavaScript Chrome V8 optimisations. I mean, they’re separate programs and your code is running in the browser with say chrome V8 only. I think that chrome v8’s optimisations are the only ones you can benefit from.
I know two bytecode-optimisation techniques: ahead of time compilation and just in time compilation. In both cases you can do some optimisations. For example you can inline all the final getter and setter methods. But yeah there are optimiations that can be done only at runtime with a “just in time compiler”. For example you could gather statistics about method invocations and inline all the final “hot” methods.
There are two interesting bytecode-instructions to invoke a method on an Object:
INVOKESPECIAL and INVOKEVIRTUAL
INVOKEVIRTUAL searches for the method based on its class. This is necessary because the method could be overriden by a subclass. For example:
String s="";
Object o=s;
//following code invokes the method hashCode which should be located in the class String
o.hashCode();
On the other hand INVOKESPECIAL invokes a method directly without searching. It could be for example a constructor or a method which is private (called in its own class). INVOKESPECIAL is way faster.
To optimize the code you could convert any INVOKEVIRTUAL instruction to INVOKESPECIAL when you can guarantee that the method will not be overriden. This is the case for final methods.
A just in time compiler could furthermore simply mark every method is “final” and drop this assumption when it finds an override.
Sounds interesting. How would one use, for example, webgpu when it comes out in the future with this? Or webgl now? It would be nice to tap in to javascript specific graphics libraries.