The Artima Developer Community
Sponsored Link

Java Community News
Java Browser Edition?

10 replies on 1 page. Most recent reply: Apr 13, 2006 9:14 AM by Dick Ford

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 10 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Java Browser Edition? Posted: Apr 5, 2006 9:15 AM
Reply to this message Reply
Summary
While Java got its start with applets, client-side Java never came close in popularity to Java on the server. Instead, Flash and AJAX emerged to supplant Java applets in rich-client applications running inside a browser. Yet, Java has much to offer to rich-client apps. A recent blog post explores how Java might stage a comeback inside the browser.
Advertisement

In the beginning there were applets, and they seemed like a brilliant idea: Run small applications that can take advantage of the full Java APIs and JVM inside a browser, alleviating the need to pre-install software. While the first applets showed the promise of that concept, incompatible browser implementations made the applet user experience a miserable one, replete with browser-freezes, crashes, and long download delays.

Meanwhile, Java's center of activity moved to the server, and for many years user interaction with enterprise Java apps were relegated to simple HTML-based output. More recently, AJAX and Flash have promised to bring back some of the interactivity originally envisioned in applets.

However, AJAX is no Java. During the ten years since the first applets debuted, tremendous progress has been made in both Java APIs and JVM performance. In many ways, AJAX is where Java UIs were ten years ago. Further, it is likely that AJAX will encounter the same problems Java UI toolkits, such as Swing, had to solve during its long development. Layouts and event handling in a multithreaded context are but two such examples.

The fruits of ten years of Java UI development are high-quality libraries for layouts, data binding, validation, as well as a plethora of polished UI widgets. Unfortunately, many server-side developers are still not familiar with client-side Java projects, such as SwingLabs, that provide UI components on top of Swing.

Instead of reinventing the wheel, why not make Java finally work inside the browser? That's the question Ethan Nicholas ponders in a recent blog entry:

There is no question that the idea of Java in the browser is currently dead, but I don't think it's too late for a comeback. Java is so much better than competing technologies that it's almost absurd. If Sun were to deliver on these features, I would switch to using Java in the browser in a heartbeat.
Ethan then outlines a path for Java to reclaim the browser, including a special JRE Browser Edition:
The most important part will be segmenting up the JRE into chunks which can be (automatically) downloaded and installed separately. I very much doubt that most Rich Internet Applications need JNDI support, for instance, or the ability to do XSLT transformations. By carefully choosing the core set of features to bundle, the JRE size could be drastically reduced.

Do you think that client-side Java has a chance to reclaim its place in browser-based rich-client applications?


Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: Java Browser Edition? Posted: Apr 5, 2006 11:14 AM
Reply to this message Reply
I would certainly like to see this.

But not without some ambivalence. Populating the web with isolated, opaque binary objects is a dubious path.

Something (substantially) modified to compete more with JavaScript + DOM might be better than just a Flash alternative.

V.H.Indukumar

Posts: 28
Nickname: vhi
Registered: Apr, 2005

Re: Java Browser Edition? Posted: Apr 6, 2006 12:54 AM
Reply to this message Reply
I doubt it.. Sun has only limited resources, and of those it seems that only a very few actually understand the necessity of good user experience. They have good engineers, but mediocre user interface specialists who do not care about user experience (ease of installation, good looking UI etc). It simply is not in Sun's culture.

Michael Stover

Posts: 28
Nickname: mstover
Registered: Jul, 2005

Re: Java Browser Edition? Posted: Apr 6, 2006 6:35 AM
Reply to this message Reply
I would like to see the idea of the Java Browser coupled with the auto-discovery and mobile code of Jini - the Jini Web, if you will. Where your Java client app seamlessly runs plugins (ala Eclipse) downloaded from a Jini network. Where instead of hopping via hypertext links from website to website, you hop via interface API's from rich-client-app to rich-client-app.

It's not a replacement for http and html and the web, but it would allow the web to go back to what it does best - display linked documents.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

would've, could've, should've Posted: Apr 6, 2006 7:46 AM
Reply to this message Reply
The demise of the applet is partially bad timing and bad moves on Sun's part. It was bad timing because back then most people were still on dialup. On the other hand, Sun has never really understood the desktop - from Swing, to a completely transparent install of the JRE.

I think the Yahoo blogger is a bit confused though. He doesn't really care about the JRE. He wants Flash or WPF/E that can be scripted with Java and all the libraries that are already out there. But he also seems to think that Flash is all about Flex 1.5, which it's not.

Sun could've done something years ago, but didn't. It'll be Flash and WPF/E.

muecker

Posts: 1
Nickname: muecker
Registered: Feb, 2003

Re: Java Browser Edition? Posted: Apr 6, 2006 12:21 PM
Reply to this message Reply
I would like to see a consistent JRE for the browser. When I first worked with Java applets, my experience was that they worked correctly only on the current version of Java and the browser could only support one version of the plugin and one version of the JRE. If you developed for JRE 1.3, your applet had numerous problems if you upgraded to JRE 1.4. If multiple teams across an organization developed applets, each had to be at the same version of the JRE or there would be conflicts.

I think the same concept should be applied to desktop Swing applications. I have multiple Java applications on my workstation and each is distributed with its own copy of the complete JRE it needs at runtime. Each application requires 20+ meg of RAM to execute because each application has to start its own heavy-weight JVM.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: would've, could've, should've Posted: Apr 6, 2006 12:28 PM
Reply to this message Reply
Does anyone know if the whole "Web Standards" movement standardizes things well enough to support applets across browsers? That could make a big difference, but I would still expect it to be a slow resurgence, based on seamless experiences and word of mouth.

Even though I've seen some very good applets lately, "Java on the Browser" seems to produce a bad taste in the mouth of the web surfer. Whereas Flash is already out there, and generally just works.

But here's something: I'm using Flash instead of Java as the delivery vehicle for "Thinking in C" and future eSeminars primarily because of the (lack of) sound support in Java. That's where I ran into the wall: I wanted to play MP3 narrations along with slides, and the standard Java library doesn't support MP3 -- which is ridiculous if you think about it. The JMF may be working now, but it has been very buggy in the past. And apparently there are 3rd party MP3 players which didn't exist at the time I started researching this project.

It would have been much easier for me to create a Java application than to learn Flex, but Flash just works across platforms, and doesn't have as many installation issues or resistance as Java does.

Ethan Nicholas

Posts: 1
Nickname: enicholas
Registered: Apr, 2006

Re: would've, could've, should've Posted: Apr 7, 2006 5:50 PM
Reply to this message Reply
I think the Yahoo blogger is a bit confused though. He doesn't really care about the JRE. He wants Flash or WPF/E that can be scripted with Java and all the libraries that are already out there. But he also seems to think that Flash is all about Flex 1.5, which it's not.

I'm not sure how you could have read what I wrote and come to the conclusion that I'm not interested in the JRE; I certainly am. I just want a better installation and startup experience.

And I am perfectly well aware that Flash isn't all about Flex. I'm not looking to replace the perfectly legitimate use of Flash for interactive movies, which is why I didn't bother to mention it. I'm looking to replace the bastardized use of Flash for things for which it is horribly ill-suited -- things like Flex and Lazlo. Java is (almost) a much, much better framework for "real" applications than any of the Flash-based technologies, but its installation process and start-up time make it unusable.

Dalibor Topic

Posts: 26
Nickname: robilad
Registered: Mar, 2006

Re: Java Browser Edition? Posted: Apr 8, 2006 9:19 AM
Reply to this message Reply
> <p>Do you think that client-side Java has a chance to
> reclaim its place in browser-based rich-client
> applications?</p>

No. Sun has no business need that would make it necessary for them to let people mix and match J2SE as they like and redistribute the results. Microsoft paid 2bn for trying that with Sun's code base.

Until someone who really, really needs to put Java in a browser puts their money into GNU Classpath, and the free VM implementations, client side Java is not going to really matter in a browser.

cheers,
dalibor topic

P Fraser

Posts: 2
Nickname: pfraser
Registered: Apr, 2006

and beware the XAML -seriously Posted: Apr 11, 2006 3:19 PM
Reply to this message Reply
While the Java community frets about Rails -the real threat is Microsoft WPF/E & XAML.

As a UI platform, HTML *is* awful. The only reason we tolerate it is a)the deployment angle b)the more subtle "data as interface" effect.

But at the end of the day we are faking a real UI. We have done it for so long now we have forgotten we are faking it. Ajax won't save the old girl. We need to run real code, against real, consistent, client side APIs.

IF someone could make something as deployable as HTML, as designable, without the downsides -it would be a killer.

And someone is: Microsoft.

Imagine rolling spruced up, multimedia HTML, SVG, and XUL, in one -with (critically) the markup creating native objects for your code to work with. As many or as few hooks into the client OS as you could negotiate, and (to some extent anyway), running cross platform. That is WPF/XAML.

Java has nothing to compete with this as far as I can see. Everything is either something old rehashed, (sometimes just renamed -Eclipse as a rich client platform) or the same old UI technology marked up in XML. XAML killers these are not.

The extra-scary angle is captured by Bruce Eckel's comments above about how Flash just works. Yes, Flash is often more appropriate where an Applet might once have been. But from a Java advocacy perspective (not necessarily Bruce's job -and not mine btw) the love of Flash by the wider Java community is like Ford saying "let's leave making compacts to Toyota, they are so good at it". Are you in the game or not? Before it can take on XAML, "Java Browser Edition" (I prefer "Java Client Edition") needs to take on Flash.

At the end of the day, Java relies on HTML for continuing viability. And HTML looks exposed to me. Don't expect HTML to evolve much while IE has so much market share -because Bill knows that everything he does for IE is a gift to Google. Bill is apparently so determined to make XAML irresistible to Google and their ilk -that he is prepared to make it run beyond Windows.

Out there somewhere on SourceForge is a quiet little Java project, implementing XAML in Java. This should be the most hotly contested project going -and should evoke the same responses from Java people as Mono does from the Linux community -for exactly the same reasons.

pf

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: and beware the XAML -seriously Posted: Apr 13, 2006 9:14 AM
Reply to this message Reply
Agree with everything you said about WPF/E and XAML. If I was Adobe, I'd be very worried and I'm sure they are behind closed doors, while publicly their MVP bloggers and others will poo-poo it.

I think the killer thing about WPF/E is that you won't have to use actionscript or have a compiler to produce the code. It's just markup and javascript if you want. It'll be much easier for 3rd parties to write tools and easier for all those millions of javascript programmers to dive into. And of course, you can also use "real" languages like C# if you want. It'll include a subset of the .NET runtime. Mono is already out there, so all it takes is someone to write the Firefox-Unix/Cairo plugin.

Flash has some impressive market penetration numbers, but Microsoft has the ultimate distribution channel and they'll also be doing the Mac port themselves. And of course it's not just IE, they've already got it running on Firefox internally.

If anything this will just raise the bar for so-called web apps. As Peter pointed out, HTML as a UI platform is just horrible. You can Ajaxify all this stuff all you want, but at the end of the day it's still HTML.

In any case, I'd rather use a consistent platform to do real web apps with. DHTML is fine for document-centric sites, but I'm not going to mess with that stuff for real apps. I know others would rather do whatever it takes to not rely on a plugin though and there seems to be some decent solutions out there - Is Tibco any good?

Flat View: This topic has 10 replies on 1 page
Topic: Java Browser Edition? Previous Topic   Next Topic Topic: Blandware has released AtLeap 0.5 Final

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use