applet emulation

[perimosocordiae]

One of the goals we've had for a long time is the ability to use Doppio as a drop-in replacement for the native Java applet runner plugin.

Here's a sketch of how I envision it working, from a user perspective:

• Navigate to a page with a Java applet embedded
• Click a bookmarklet that runs the applet with Doppio

The bookmarklet would:

• scrape the page source for the <applet> tag
• load Doppio
• replace the <applet> with a <canvas> of that same dimensions
• run the applet in Doppio

The hardest part is the last step, of course, because we'd need to emulate java.awt.* on the HTML canvas, and (naturally) AWT uses a metric ton of native function calls. Just like we did with Jazzlib for java.util.zip, we could use a mostly pure-Java implementation of AWT: the PJA Toolkit. Sadly, the project is a few major JRE versions out of date, and it would need a some significant effort to get in shape for Java 1.6. Alternatively, we can bite the bullet and implement all the natives ourselves. There's a test case for the most basic AWT usage in test/special/Gfx.java.

The other non-trivial piece of code is the applet harness itself. This would be responsible for creating the Applet object and calling its lifecycle methods init, start, stop, and destroy. We don't yet have a test case for this.

[emeryberger]

It sounds a little way off. Maybe a more profitable near term target would
be to provide support for a JVM language Like Scala or clojure...?

[Loccy]

As an end user (yes, we exist :-) I just wanted to lobby for some kind of graphics support.

As Emery knows, my use case for Doppio is within an online learning environment for teaching programming. This has been based around Javascript up until now, but thanks to Doppio it can spread its wings a little more and also be used on our introductory Java courses.

I'm not especially interested in applets per se, but I am very interested in some kind of graphics support, even if we were just talking something as small as a subset of Graphics shimming to a Canvas client side. Chances are I will end up attempting to hack something of that ilk together myself if no-one on Doppio proper is interested in this - but as I don't speak Coffeescript and I'm working directly with the (compiled) Javascript files, my stuff would probably be of limited use outside of my own project (although happy to share regardless).

[int3]

Misc notes for future reference:

• Graphics is currently outright disabled because java.awt.headless is set to true in system_properties.
• After toggling it to false, the next required step is to set java.awt.graphicsenv to the full name of the graphics environment class. I think if we try to emulate a native system, we should go with X11 instead of Cocoa. In that case the required property value should be sun.awt.x11graphicsenvironment. This also provides additional impetus for moving to OpenJDK's JRE instead of Apple's.

Also, re supporting Scala or Clojure first: I'm beginning to suspect that supporting these fancy JVM languages may actually be even more of a challenge than supporting graphics, because they use extensive reflection and dynamic bytecode loading / rewriting to achieve their magic on the JVM. We've gotten Kawa Scheme running, though, which is a start :)

[jvilk]

Applets require Swing. @lavelle has discovered that the Swing libraries repeatedly break their abstractions; e.g. rather than take in a FooBar, many interfaces take in a SunFooBar. It's impossible to extend these classes without modifying them, as they are marked final.

Bringing this to fruition will either require a fork of Swing, or significant hackery.

[Efreak]

Has anything changed regarding this issue? Considering this page it seems (from my likely ignorant view) that it should be comparatively trivial to remove the prefixes (compared to working around them).

Given the removal of java support from browsers, a project like this would be amazingly useful for old websites, whether for playing old games, embedding more useful applets, or just for simply viewing older pages--java applets weren't quite as ubiquitous as flash, but I recently came across a company whose neglected website used a several java applets for their menu. Combine this with shumway or gordon and the web archive for a good time.

[jvilk]

Hey @Efreak,

OpenJDK readily admits that OpenJDK's Swing/AWT implementation is not as portable as the AWT specification suggests.

Unfortunately, the current implementations do not abide by this
interface. In various places in Swing and AWT, this interface is
circumvented and OpenJDK specific implementation classes
(e.g. SunToolkit, SunGraphics2D) are called directly. This defeats the
whole purpose of having such an interface in the first place and makes
porting AWT to new platforms unnecessarily hard or impossible without
modifying Swing and AWT themselves. Not only does the code simply
assume that the current implementation is the OpenJDK implementation,
but the interface itself is often incomplete.

The linked project would be an ideal fit for Doppio, but it appears to be incomplete and seems to be either dead or on life support.

We do not have the resources at the moment to attempt an AWT port or to hack around AWT's hardcoded shenanigans. Since AWT/Swing is needed for most legacy applets, it seems like we are stuck until someone willing to take a stab at it tries to add support to DoppioJVM.

I hope that helps. Feel free to take a stab at adding this if it seems like something you're interested in. One potential starting point would be to integrate support for JavaFX into DoppioJVM, which uses a more portable stack. As mentioned in #373, others have implemented JavaFX support into an older version of DoppioJVM, so you could port their code to the latest version of DoppioJVM (after checking that the license is compatible, which I believe it is, of course!).

A crazy solution would be to try to compile an X server to JavaScript with something like Emscripten, or trying to port the X server to JavaScript so we can just re-use OpenJDK's AWT Linux backend.

[ExE-Boss]

I was thinking of doing #494 instead of a bookmarklet.

[jvilk]

Either way, the challenges remain the same. I can provide pointers to anyone willing to tackle the challenges, but I am unable to provide significant engineering support (other than code reviews for any PRs opened). So if you want to take a swing at this, @ExE-Boss, feel free! 😄

[bplevin36]

I'd like to take a stab at this, but a very focused one. I have some old applets lying around that performed some physics computations. I'd love to get them working in the browser, and I wouldn't need any AWT or Swing support for them, just the applet lifecycle harness. I've researched how to go about implementing this, based off the OpenJDK source and the IcedTea web plugin, but both of them seem to dramatically overcomplicate the implementation of the applet lifecycle. Is this something you've looked into at all or could give some pointers? Also, as a side question, is there anyway to run jdb with Doppio? That might help with seeing where things are getting hung up.

[antimeme]

Is there a mailing list or something equivalent for this effort? I'd like to help. I have lots of experience drawing on HTML canvas elements as well as creating Java applets. I'd like to be able to run applets on the web and I'm not afraid of mocking up java.awt.Graphics and java.applet.Applet to do it, but I'd like to coordinate with others and get help with doppio and JavaPoly, which are new to me.