Skip to main content

Roadmap for Java Applets?

No replies
falde
Offline
Joined: 2006-11-05
Points: 0

Is there a roadmap for Java Applets?

As you may have noticed Flash currently dominates the Applet field even if the new JavaScript engines, HTML5 and WebGL will put some pressure on Adobe.

However the idea of running code inside the browser originate with Java which is still a superior technology compared to JavaScript or flash.

While Adobe is borrowing more from Java then JavaScript, the now JavaScript engines compiles the code to an internal bytecode format, and then to Native. With Java there is no in-browser code compilation stage. The use of bytecode and JAR-files makes Java more standardized, leaner and requires less computation before execution.

However there is obviously some issues that is holding Java Applets back that we need to identify and resolve. I can describe some, but I am not certain that I cover all of it.

1) Speed. The Java Applet plugin is notorious for being slow. Some of this is probably addressed by the Jigsaw project. The only way to know for sure is to implement a performance test kit for functionality commonly used in Flash and JavaScript, which is what we are competing with.

2) Multimedia. Java Media Framework was promising but seams to be dead. JavaFX have more multimedia support but it cannot easily be used from within AWT or Swing. HTML5 has "video" support but does not standardize codecs, which makes it weak compared to Flash that has a standard set of codecs. This is a natural opportunity for Java to be hijack the expected success of HTML5 by shipping an attractive media player. While Flash currently dominates the multimedia segment it is notorious for its speed problems. Downloading a youtube clip and playing it in VLC gives a huge difference in performance, possibly because VLC is far better when it comes to using hardware acceleration. If I am not mistaken VLC and Java has compatible licenses *hint*.

3) Flash 3D and WebGL. The obvious response to WebGL would be to make a subset of JOGL or LWJGL available as a part of the standard Java library. While they can currently be used trough JNLP that is not acceptable to most developers and users. We cannot demand that kind of user interaction when Flash and JavaScript does not. Java does have a clear advantage here. While WebGL have a port of Quake II, we have that and more. We have RuneScape, Worm Online, Poxnora, Minecraft... and probably a lot more.

4) GWT. Now that is one of the more perverse thing I have seen, it pretty much takes Java code and generates not a Java Applet but JavaScript, and has a partial implementation of the Java libraries in JavaScript. The obvious response to that is making something that can take similar Java code and generate a Java Applet. That should be significantly easier, as we do not have to reimplement Java functionality in a script language...

5) JavaScript an itself is an abomination. The fact that downloading and running a text-based script in many cases is more efficient then downloading and running JIT-able bytecode is seen as an utter failure for Java. If we wish to change that we must make sure that there is no use case ever where Java Applets is inefficient compared to JavaScript. Hopefully Jigsaw may be enough for that. However if it does not, we will have to eliminate whatever disadvantage is left. Seriously, we can not let a script language outperform Java.

Also there is another related issue that I will address here. It is not specific to Java Applets but it may have an impact on the speed of development.

This is the issue of how to create and maintain bindings. There are totally over 40 binding libraries to OpenGL, one can only imagine the amount of resources that consumes. I did not limit this search to Java since that is my point. Why have a language-specific binding mechanism for each language, and then maintain over 40 libraries that pretty much does the same thing?

As I was a Windows programmers in the past I am familiar with Microsofts solution to this. It is not perfect and I am not suggesting cloning it. However the beauty with COM is that we never had to do bindings for every possible language. We only had to support the COM standard and then COM took care of everything else, languages supporting COM did not have to implement bindings for COM libraries. If any glue was needed, it could be automatically generated.

Of course COM has many drawbacks. The most important one for us it that it is (mostly) a Windows-only solution.

However the basic design principles of COM is something we can learn from, in order to eliminate the need for 40 different OpenGL binding projects. While there is products that can create JNI bindings for COM objects which I think shows the vadility of such a design. Of course we cannot use something that requires COM, as that would restrict us to Windows. But we can use the idea.

As JNI lays the basic foundation for this I do not think that such a project needs any changes in the JVM. In fact o do not think we should make anything that requires changes in the JVM.

It would however imply changes in the core Java libraries. Not because we have to do such changes, but because much of the code there is bindings to external libraries and such bindings should not be maintained as Java-only bindings. However, this is outside the scope of the Applet discussion.

However what I am implying is that there should be a language-independent OpenGL library that can be used not only by Java but also by Haskell, Lua and Perl... to mention only a few of the languages that have language-dependent bindings to OpenGL.