Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

Is it Time For a JVM-Based Web Browser?

03.01.2010
| 10339 views |
  • submit to reddit
There are currently two exciting platforms for which one can develop:
  • The Java Virtual Machine (JVM). Advantages: Great tools, hosts many languages, lots of free software is available for it (databases, support for many file formats, etc.), support for modularity (OSGi, Jigsaw).
  • The web browser. Advantages: Quickly trying out an application without downloading anything, URLs that encode application states and are bookmarkable, the ability to clone application states via tabs, integrated hypermedia.

Then how about combining these two platforms? It seems like a missed opportunity for the JVM that all major browser now have JITs for JavaScript, but none of them uses the JVM. What would a JVM-based web browser look like? It would be modular, every aspect of it would be extensible in Java. It would be host to a new kind of web/desktop application hybrid. If the JWebPane technique of porting Webkit to Java2D really works, then it can even provide a perfect web experience.
I do realize that applets go a long way in the direction of this vision, but many minor details add up so that one still feels the barrier between Java and the browser. I could never get excited about JavaFX, it always felt like Java was trying to be like Flash. But the idea of a JVM-based web browser, HotJava 2 if you will, does excite me in ways I cannot all explain rationally. I can see myself extending such a browser with many tools and writing all my future applications based on it.

Update: See my comment below on a refinement of these ideas.

From http://2ality.blogspot.com

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jilles Van Gurp replied on Mon, 2010/03/01 - 3:05am

Good luck building a rendering engine from scratch. Good luck making that perform well and then good luck trying to deliver a good plugin & multi media experience. And good luck trying to develop a user interface around that that people will actually want to use. Basically previous Java browser projects delivered underforming, feature incomplete, buggy browser engines embedded in a UI that at best would compare favourably to Mosaic 1.0. I don't think any of them ever came close to pulling off such stunts as making gmail usable or playing a youtube movie, which would have been a good benchmark for comaptibility about five years ago. 

There's a reason Java based browsers have failed miserably: they didn't solve a problem people actually had.

With four existing browser families (Webkit, mozilla, opera, ie) in the market across all relevant platforms, that is unlikely to change.

Han Theman replied on Mon, 2010/03/01 - 3:05am

Huh? There's a number of Java based browser projects out there. A pretty interesting one is: http://lobobrowser.org/java-browser.jsp Unfortunately, it's GPL infested, making it unsuitable as an extension / commercial application deployment platform. And the performance of Java is still a problem for these kinds of applications though.

Jose Maria Arranz replied on Mon, 2010/03/01 - 4:31am

Axel: I can see myself extending such a browser with many tools and writing all my future applications based on it.

I share your view for desktop, I think we should be able to build desktop applications based on web technologies reusing 99% of source code of the web version.

 

Roland Carlsson replied on Mon, 2010/03/01 - 6:56am

Why not build a javascript-replacement that can manupilate the the dom on the client with javacode instead of javascript. Use the existing redering-machines but being able to take advantage of the huge library with java-code.

Perhaps signed jars could break the cross-scripting limits of javascript to make the browser really useful as a desktop-replacement. 

Ronald Miura replied on Mon, 2010/03/01 - 8:32am

Where is the JWebPane?!?!?!?!

Axel Rauschmayer replied on Wed, 2010/03/03 - 8:04am in response to: Roland Carlsson

Right, maybe it is just a matter of replacing the JavaScript JIT in, say, Firefox with the JVM. I have not fully figured out what a JVM browser should look like, but I know that Java needs a compelling vision for the future. For me, GWT is an example of bringing excitement to the Java platform. Unfortunately, the client/server rift prevents a completely seamless user experience. Maybe if there was a way to dynamically switch between a browser-hosted and a server-hosted backend. Both would be JVM-based and the browser-hosted backend could be installed locally on demand. Kind of a Java Web Start for web applications.

Osvaldo Doederlein replied on Mon, 2010/03/01 - 9:24am

These decisions must be revisited from time to time; the fact that Pure-Java browsers sucked in the past doesn't mean that they will suck now. Some important factors:

  • Modern browsers have advanced JavaScript VMs, and modern webapps rely a lot on that, so the weight of that JSVM is much higher than in the past. I'd expect JRE 7 (due to invokedynamic) + a modern JS-on-JVM runtime ("Rhino on steroids") could be competitive, in both speed and resource usage, with the likes of Firefox+TraceMonkey, Chrome+V8 etc., for Web2.0 apps using tons of JS.
  • Browsers are also becoming heavier due to other concerns like security, e.g. using lots of processes to handle each tab or plugin, Java doesn't need this so the it would compensate part of the Java overheads
  • Java 2D&3D acceleration is much better than in the past. The rendering can be mostly offloaded to your GPU, even if this limits the browser to reasonably-modern machines with OpenGL2 or DX10 or better. You may just need a small native bridge (the JavaFX runtime already distributes that, and signed by Sun so it can be installed by applets and JAWS apps without security warings).
  • Running Applets would obviously be more efficient on a Java-centric browser ;-) Of course, this is only an advantage if applets become successful again.

Having said that, I tested the latest Lobo and its speed is good, resource usage average (significantly higher than Firefox but not scandalously so), but the rendering quality/completeness is still very poor. The project is clearly small and slow-moving - they have JavaFX integration but it's incredibly outdates (JavaFX 1.0 is bundled; can't even render the javafx.com homepage).

And I agree with Jilles - we need a strong motivation to want a pure Java browser, at least some niches that clearly benefit from it. Not just the nerdy motivation of showing off Java's capability. End-users won't care about the implementation platform. Microst has planned many years ago (original Longhorn plan) to rewrite MSIE as managed code (C#) and they didn't do it, I don't know if they have actually tried and failed, or if the backwards compatibility issue killed the idea in its infancy (people can't get rid of MSIE 6.0 support even to this date...). And .NET/C# was arguably a better platform for the job (more optimized for the client side; tightly integrated with the main desktop OS so the overheads can be partially hidden, etc.)

Jan Kotek replied on Mon, 2010/03/01 - 9:46am

 Such browser already exists. Supports javascript, java fx, CSS... 

http://lobobrowser.org/java-browser.jsp

 

Curt Cox replied on Mon, 2010/03/01 - 9:56am

There are plenty of pure open source Java browser pieces lying around, but I think the the only feasible approach to a pure Java browser that would be quickly usable, is to compile existing native sources to the JVM. http://nestedvm.ibex.org/ Once that is done, parts can be ported over to more suitable languages as needed. The initial driver for most of the porting will be speed.

Jose Maria Arranz replied on Mon, 2010/03/01 - 11:46am

Unfortunately Lobo/Cobra has long way to achieve decent support of standards otherwise it would be supported in ItsNat (I'm hungy of browsers).

Extending Batik to support HTML would be an interesting alternative, Batik is a nice pure Java SVG "web browser" and W3C DOM Core support rocks and there is very much work on CSS (for SVG). In ItsNat, Batik W3C DOM has been easily extended to support W3C DOM HTML APIs. Of course rendering is by far more complex.

 

Vincent DABURON replied on Mon, 2010/03/01 - 11:47am

Hello,

In 1999 - 2000 , i used Sun Hotjava  browser and Icebrowser on Sun Java station an Alcatel webphone.

I don't want to retry this difficult experience (bugs, no cookie support ...)

I prefere  control IE, Firefox or others classic web browers with good java mapping librairies.

Vincent.

Guido Amabili replied on Mon, 2010/03/01 - 12:41pm

What about Bolt ?

 

Jose Maria Arranz replied on Mon, 2010/03/01 - 1:00pm in response to: Guido Amabili

Bolt is a proxy based JavaME browser like Opera Mini, useless for desktop-like applications done with web technologies.

 

Anthony Goubard replied on Mon, 2010/03/01 - 1:14pm

At least some of the libraries exists: 

 

  • Flying Saucer for XHTML rendering
  • HTTPClient 4 for connection, cookies
  • JavaScript already integrated in Java
  • New Java plug-in since Java 6 update 10 (Sun may have some doc about it)
  • Already recently added in Java 6 mixing lightweight/heavyweight components in Swing
  • I would say NetBeans RCP for Tabs/Docking, bookmark management, plug-in management, help, ...

What's left?

 

  • Something that translates dirty html/Javascript in clean xhtml / javascript
  • Some glue code for all of the above
  • A lot of test / debugging / fixing
  • And to make it successful a lot of marketing

Good luck!

Anthony 

Cloves Almeida replied on Mon, 2010/03/01 - 5:23pm

If only I could write GWT apps without compiling to JavaScript...

David Lee replied on Mon, 2010/03/01 - 6:06pm

The time has passed for this.  Sun should have supported a java browser project back when they decided to kill hotjava. 

There certainly needs to be more non-developer focused Swing applications, but any new "big" effort on some killer java desktop app needs to be done in an area where a swing app has a good chance to win.   When you start thinking about ideas, you will no doubt end up thinking more in terms of the web and that just makes you wonder what could have been if Sun had fixed startup times for the JVM and overall performance sooner.   Applets would have been what flash and flex has become.  

The time has passed for a Java based browser, although I'd love to see one.  A browser that treated applets and webstart apps as first class citizens would have been nice back when developers thought these were going to be real players on the web.

 

Sreenath Ven replied on Mon, 2010/03/01 - 8:46pm

Java web browser would have been much better. But due to old browsers we had so far, will stop inovations...most of the sites have wrtten code specific to browsers and check teh headers before serving ;-)

Dominique De Vito replied on Tue, 2010/03/02 - 12:51am

I wrote in April 2009, HotJava may come back, due to existing, or coming, components, like JWebPane:
While time may come true a false advertisement, it could help HotJava's comeback. Remember HotJava !? Yes, the web browser implemented in Java. I don't know exactly if HotJava is going to come back, but the different pieces are there, existing in a better shape than before. So, let's take a look at different pieces that could be part of a new HotJava release, or that could make it a valuable browser...
Well, the programming model for such a Java browser is already there: it's GWT. I wrote about it in Google has released a (kind of) Java Browser Edition with GWT:
Few years ago, I wrote Why not running a Java Browser Edition on top of Firefox VM (Tamarin) ? after reading a post of Ethan Nicholas (SUN) about a forecasted Java 2 Browser Edition (renamed later as Java Kernel). AFAIK, such edition has never taken off. But I realized recently it lives under another form, quite according to my initial post's wishes; more and more pieces of a browser edition of Java run on top of JS engines, inside browsers, with the help , for example, of the GWT Java to JavaScript compiler.
And GWT is a good way to go due to the fact GWT and Jetpack are going to shake up the web-based (RIA) desktop application landscape.

But, unfortunately, the worst news is that SUN has missed a very important opportunity for JWebPane as I wrote in XML-based GUI programming is rising, but don't forget CSS too:
I wrote into my post HotJava may come back, due to existing, or coming, components, like JWebPane there was an opportunity to revivify a Java-based browser, that is a Java-based client-side platform, following Adobe which is providing a platform with Adobe AIR. According to JavaOne slides (see my post above), JWebPane looks very promising; the bad news is that JWebPane was announced a long, long time ago (since mid-2008 or even earlier), and looks like to live in limbo as nothing has been released (even if promised for the end of 2009). SUN has missed a very important opportunity with JWebPane (I am not the only one who think that, read here). JWebPane summarizes important SUN’s past drawbacks with bad and huge consequences unfortunately: development behind the door only, lack of news, failure to deliver on time important pieces of code... GUI with Java would have been changed with JWebPane being delivered 1 year ago...
Oracle could still revivify JWebPane to build a Java-based Adobe AIR competitor, but SUN/Oracle has lost a lot of time...

PS : a good way to bring webapp programming closer to Swing programming, and in order to help a new HotJava to come, here is an idea: " to bring GWT develop community to Swing, it could be interesting too, maybe as a Oracle investment, to implement GWT using Swing" (as I wrote here).

David Lee replied on Tue, 2010/03/02 - 9:29am in response to: Dominique De Vito

A java based browser not based 100% on java is a waste of time.  A java based browser is only needed for the statement it would make.  Most browser needs are pretty much already addressed. 

What would be the point of a java based browser based on AIR, Firefox or anything else ?

There java based X386 emulators, like this one - http://www-jpc.physics.ox.ac.uk/home_home.html. My point here is, this is not really practical, I'm not sure what problem is solves, but it's a truly impressive demonstration of what the JVM and Applets are capable of. A java based browser, at this point, would only serve to either make a statement or 2) serve as the best platform to run all of Java's web targeted technology.

Ricky Clarkson replied on Wed, 2010/03/03 - 6:10am

First, add native support to Java for MPEG-4 including H.264, so that your new browser has a chance of supporting media.

Aaron Digulla replied on Thu, 2010/03/04 - 10:21am

Why reinvent the wheel? There is SWT which has a browser widget. Granted, access to the DOM is painful but that can be solved if someone would care.

Then there is Webkit. And with Java 7 (where you actually have access to the sources), it should be possible to include Webkit to the build so it would be available anywhere.

These solutions would give access to exiting, reliable solutions instead of trying to kick of a project to write another browser (which will take years!).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.