HotJava - precisely why won't it run?

[Bob Nelson]

Yes, I know that HotJava was primarily a ``proof of concept'' and has long
been abandoned. And no, I have no intent to actually use it as web browser.

But after re-reading PvdL's ``Just Java'' and Gosling's ``The Java Language
Environment'' white paper emphasizing ``future proofing'' of software, I
wonder what precisely keeps HotJava from running with current JVMs.

Invocation of HotJava fails in various inelegant ways depending on the
platform (Solaris 10x86, Solaris 9 Sparc and Linux). So, what precisely
prevents this ``write once, run anywhere'' application only a decade old
from running now?

 

[Knute Johnson]

Yes, I know that HotJava was primarily a ``proof of concept'' and has long
been abandoned. And no, I have no intent to actually use it as web browser.

But after re-reading PvdL's ``Just Java'' and Gosling's ``The Java Language
Environment'' white paper emphasizing ``future proofing'' of software, I
wonder what precisely keeps HotJava from running with current JVMs.

Invocation of HotJava fails in various inelegant ways depending on the
platform (Solaris 10x86, Solaris 9 Sparc and Linux). So, what precisely
prevents this ``write once, run anywhere'' application only a decade old
from running now?

Where did you find it? I'd like to try it, maybe I can give you a clue.

 

[EJP]

But after re-reading PvdL's ``Just Java'' and Gosling's ``The Java Language
Environment'' white paper emphasizing ``future proofing'' of software, I
wonder what precisely keeps HotJava from running with current JVMs.

Is there any evidence that it doesn't?

My impression is that Sun just decided not to get into the browser business.

 

[Bob Nelson]

Where did you find it? I'd like to try it, maybe I can give you a clue.

http://java.sun.com/products/archive/hotjava/index.html

 

[Bob Nelson]

Is there any evidence that it doesn't?

On Linux (I'll post the results on Solaris SPARC if desired):

java -cp /opt/HotJava/Browser.jar
sunw.hotjava.Main -Dhotjava.home=/opt/HotJava
Exception in thread "main" java.lang.NoClassDefFoundError:
sun/net/ProgressData at
sunw.hotjava.HJWindowManager.createFrame(HJWindowManager.java:166)
at sunw.hotjava.Main.main(Main.java:188)
Caused by: java.lang.ClassNotFoundException: sun.net.ProgressData
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 2 more

 

[EJP]

java -cp /opt/HotJava/Browser.jar
sunw.hotjava.Main -Dhotjava.home=/opt/HotJava
Exception in thread "main" java.lang.NoClassDefFoundError:

So 'what precisely keeps HotJava from running with current JVMs' is that
it relies on a sun.* class that isn't there any more.

 

[Knute Johnson]

So 'what precisely keeps HotJava from running with current JVMs' is that
it relies on a sun.* class that isn't there any more.

I installed the version 3.0 that you pointed to and it works fine if you
install the JRE that comes with it. On Win XP anyway.

 

[Roedy Green]

Invocation of HotJava fails in various inelegant ways depending on the
platform (Solaris 10x86, Solaris 9 Sparc and Linux). So, what precisely
prevents this ``write once, run anywhere'' application only a decade old
from running now?

from my point of view, it never did run. It was hopelessly buggy and
slow.

 

[thufir]

from my point of view, it never did run. It was hopelessly buggy and
slow.

I don't understand why it never took. Or, more to the point, why Mozilla
didn't just decide to use Java.


-Thufir

 

[Arne Vajhøj]

I don't understand why it never took. Or, more to the point, why Mozilla
didn't just decide to use Java.

I can think of several possible reasons:

1) they inherited the NetScape code that was not in Java
2) for a browser to be really good it need to be tightly
integrated with the OS - difficult to do in pure Java - and
with a bunch of JNI modules there are not so much point
3) many people like Java but there are also people who do
not like Java (the use of Java in OOo was heavy debated
AFAIK)

Arne

 

[Logan Shaw]

I don't understand why it never took. Or, more to the point, why Mozilla
didn't just decide to use Java.

I don't actually know the answer to this question, but was there
a freely-available, Java-native JPEG decoder at the time the Mozilla
project started? That could be one reason. What about PNG and GIF?

Also, there is the small matter of maintaining compatibility with
existing Netscape plugin binaries.

I'm not saying these were insurmountable obstacles, but they could
have factored into the decision.

- Logan

 

[Stefan Ram]

I don't actually know the answer to this question, but was there
a freely-available, Java-native JPEG decoder at the time the Mozilla
project started?

Some problems with Corel Office were more fresh in memory and
possibly there was no Netbeans yet to show what Java can do.