What is wrong with Applets?

[jesbox]

There is major momentum for JavaScript and in some ways Flash to make
active code to run in the web browser.

The Java Applet technology seems largely forgotten. Are there
technical reasons for not using Java Applets?

If someone made something like AJAX but using Applets for the client-
side execution, how would that compare to the omnipresent JavaScript
solutions??

Are there issues with browser compatibility, security or inferior
functionality? Are Applets actually better but neglected??

Thanks for your insights on this topic.

 

[Joshua Cranmer]

There is major momentum for JavaScript and in some ways Flash to make
active code to run in the web browser.

The Java Applet technology seems largely forgotten. Are there
technical reasons for not using Java Applets?

Java has suffered from a noticeably long load time, so people do notice
when applets are loading.

AJAX also has somewhat looser security controls (you can load any HTTP
page you want with XHR (if you do a few things, none of which involves
signing your code), Java limits you to connections to your source server).

Predominantly, I think the major reason for the drop in use of Java
applets is that they stand out more in terms of UI. AJAX displays
basically using the same techniques as the webpage, so the UI is a lot
more seamless; Java applets will typically be using default Swing or AWT
settings, so they really stick out if they have anything hinting at UI.

If someone made something like AJAX but using Applets for the client-
side execution, how would that compare to the omnipresent JavaScript
solutions??

I'm not quite sure what you're asking here. Applets have pretty much
been more featureful than AJAX since AJAX was first contrived. Perhaps
people may find it just too hard to prototype stuff quickly in Java
compared to JS, but I've found that not to be the case whenever I've tried.

Are there issues with browser compatibility, security or inferior
functionality? Are Applets actually better but neglected??

Ultimately, I think applets are much more powerful than "Web 2.0" tools.
However, they do have very noticeable issues in terms of startup
performance and UI seamlessness.

 

[Arne Vajhøj]

There is major momentum for JavaScript and in some ways Flash to make
active code to run in the web browser.

The Java Applet technology seems largely forgotten. Are there
technical reasons for not using Java Applets?

If someone made something like AJAX but using Applets for the client-
side execution, how would that compare to the omnipresent JavaScript
solutions??

Are there issues with browser compatibility, security or inferior
functionality? Are Applets actually better but neglected??

I think it is a combination of many things:
- a version mess with very old MS Java version and a rather
wide range of SUN Java versions out there
- Java is not as good for the flashy stuff as Flash and SL, we
need to use JavaFX to compete in that area and not that many
have started using JavaFX
- most Java people work with Java EE and those people prefer
all the logic server side
- Java applets are not in fashion today

Arne

 

[Roedy Green]

There is major momentum for JavaScript and in some ways Flash to make
active code to run in the web browser.

The Java Applet technology seems largely forgotten. Are there
technical reasons for not using Java Applets?

If someone made something like AJAX but using Applets for the client-
side execution, how would that compare to the omnipresent JavaScript
solutions??

Are there issues with browser compatibility, security or inferior
functionality? Are Applets actually better but neglected??

I would like to see JavaScript disappear. My objections are:
1. It is inefficient to use pass around source code.
2. the language itself is Mickey Mouse.
3. It never works the same way on two different browsers.

It has succeeded because it can do things that Java itself cannot.
There is no inherent reason that should be so. Perhaps it is just the
Sun likes things to be multiplatform and the JavaScript people do not.

Apple is partly the villain there. They have been deliberately
screwing up Java and promoting JavaScript for their iPhone iPad toys.

 

[Arved Sandstrom]

I think it is a combination of many things:
- a version mess with very old MS Java version and a rather
wide range of SUN Java versions out there
- Java is not as good for the flashy stuff as Flash and SL, we
need to use JavaFX to compete in that area and not that many
have started using JavaFX

I personally may never start - the samples on javafx.com hang both
Safari and Firefox on Mac OS X 10.6, and go into error dialog loops in
Firefox on Ubuntu 9.10. None of these browsers have any problems running
applets, and the JRE versions are completely updated. If that's the
state of the art I'll stick with all the other approaches that actually
work, thank you very much.

- most Java people work with Java EE and those people prefer
all the logic server side

I don't know if that's it - I'm OK with logic on the client, whether
that's a PDA or a smartphone or a browser on a desktop. I just happen to
believe that so long as our most serious problems lie with producing
reliable, easy-to-maintain, correct code, why are we dicking around with
visual effects?

I also happen to believe that users of our UIs want clear, intuitive
interfaces, not dressed-up circus shows. If you think you need Flash or
JavaFX or any of that other stuff to sell your interface then you're
already on the wrong road. IMHO.

- Java applets are not in fashion today

Arne

AHS

 

[Arved Sandstrom]

I would like to see JavaScript disappear. My objections are:
1. It is inefficient to use pass around source code.

What's more inefficient is to keep on calling the server to render new
pages or page sections to do something that the browser can do by
processing JavaScript.

2. the language itself is Mickey Mouse.

How so? For its intended purpose it works reasonably well.

3. It never works the same way on two different browsers.

On modern or fairly modern browsers you sort of have to try to make it
work different on different browsers. I can think of a couple of largish
J2EE web apps I work with right now that have JavaScript libraries like
Prototype and script.aculo.us included in pages, plus all the script
introduced by using JSF, plus plenty of Javascript page logic included
by the application. We're talking dozens through hundreds to some cases
thousands of lines of Javascript per page. All pages work without any
changes in IE6 through IE8, work with a handful of minor tweaks in
Firefox and Safari, and not so many more minor tweaks for Chrome and Opera.

Mind you, the stuff we use JavaScript for falls within what I consider
to be its reasonable boundaries, so maybe that's why we don't run into
problems.

It has succeeded because it can do things that Java itself cannot.

Pretty good reason, don't you think?

There is no inherent reason that should be so. Perhaps it is just the
Sun likes things to be multiplatform and the JavaScript people do not.

Apple is partly the villain there. They have been deliberately
screwing up Java and promoting JavaScript for their iPhone iPad toys.

Screwing up Java? This is what I'm running on Mac OS X 10.6.2 right now
(I haven't done my 10.6.3 upgrade yet):

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

I run NetBeans 6.8, Eclipse 3.5, and any number of Java EE 5/6 servers
on that laptop, and I can't say I have noticed that Java is screwed up.

AHS

 

[Arne Vajhøj]

Apple is partly the villain there. They have been deliberately
screwing up Java and promoting JavaScript for their iPhone iPad toys.

Screwing up Java? This is what I'm running on Mac OS X 10.6.2 right now
(I haven't done my 10.6.3 upgrade yet):

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

I run NetBeans 6.8, Eclipse 3.5, and any number of Java EE 5/6 servers
on that laptop, and I can't say I have noticed that Java is screwed up.[/QUOTE]

Roedy did write iPhone and iPad.

Somehow I think you are running those IDE's and app servers on
a Mac computer and not on iPhone/iPad.

Arne

 

[Stefan Ram]

Java applets will typically be using default Swing or AWT
settings, so they really stick out if they have anything hinting at UI.

By default, but they also could be hidden and modify the DOM:

»Through either the JavaScript DOM APIs or the
Java Common DOM APIs, the Java applet can modify
the web page dynamically«

https://jdk6.dev.java.net/plugin2/liveconnect/

 

[Arne Vajhøj]

I would like to see JavaScript disappear. My objections are:
1. It is inefficient to use pass around source code.

JavaScript can be compressed quite well. It does not need to
be a problem.

2. the language itself is Mickey Mouse.

It was designed for another purpose than Java.

I can not see a problem with the language for web client
side code.

3. It never works the same way on two different browsers.

Lot of it does.

Code can be written portable or non-portable.

It is very difficult to create a language that prevents
people from writing non-portable code.

> Perhaps it is just the
Sun likes things to be multiplatform and the JavaScript people do not.

Nonsense.

JavaScript is standardized under ECMA & ISO.

Implementations does implement the standard.

Apple is partly the villain there. They have been deliberately
screwing up Java and promoting JavaScript for their iPhone iPad toys.

Apple is pushing Objective-C instead of Java.

Most likely noone at Apple considered Java and JavaScript
to be alternatives.

Arne

 

[Arved Sandstrom]

Screwing up Java? This is what I'm running on Mac OS X 10.6.2 right now
(I haven't done my 10.6.3 upgrade yet):

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

I run NetBeans 6.8, Eclipse 3.5, and any number of Java EE 5/6 servers
on that laptop, and I can't say I have noticed that Java is screwed up.

Roedy did write iPhone and iPad.

Somehow I think you are running those IDE's and app servers on
a Mac computer and not on iPhone/iPad.

Arne
[/QUOTE]
I saw the iPhone/iPad part, but given the fact that Apple hasn't been
screwing up Java for anything else, which was my point, I'm somewhat
dubious that they are expending effort on screwing it up for anything.

If Apple is in fact pushing JavaScript for iPad/iPhone (and they could
well be, I don't develop for either device) all that means is that they
are pushing JavaScript. Not deliberately crippling Java, nor even not
supporting it. And if this is true then perhaps it means that Apple
thinks JavaScript is well-suited even if Roedy does not.

AHS

 

[Daniel Pitts]

By default, but they also could be hidden and modify the DOM:

»Through either the JavaScript DOM APIs or the
Java Common DOM APIs, the Java applet can modify
the web page dynamically«

https://jdk6.dev.java.net/plugin2/liveconnect/

True, but I have personally experienced issues (freezing, strange
behavior, etc...) with multi-threaded applets that rely on that
functionality (even when doing appropriate synchronizing and using the
DOM dispatcher thread).

Not to mention the JSObject interface is very buggy. There are
work-arounds, but none as good as I'd like.

I wrote about such a work-around here:

<http://virtualinfinity.net/wordpress/tools/2008/10/11/javascript-and-java-applets/>

 

[Richard Maher]

Hi Daniel,

True, but I have personally experienced issues (freezing, strange
behavior, etc...) with multi-threaded applets that rely on that
functionality (even when doing appropriate synchronizing and using the
DOM dispatcher thread).

Can you please explain further on how you are "using the DOM dispatcher
thread"? Are you still talking about the Liveconnect JSObject interface or
the Common DOM APIs?

How are you telling your JSObject.call() to execute on the "DOM dispatcher
thread" and, with reference to the following link, what choice do we have?
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html

Cheers Richard Maher

 

[Arne Vajhøj]

On 09-04-2010 20:25, Arved Sandstrom wrote:
[lots of stuff that I agree with]

Roedy Green wrote:
Apple is partly the villain there. They have been deliberately
screwing up Java and promoting JavaScript for their iPhone iPad toys.

Screwing up Java? This is what I'm running on Mac OS X 10.6.2 right now
(I haven't done my 10.6.3 upgrade yet):

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

I run NetBeans 6.8, Eclipse 3.5, and any number of Java EE 5/6 servers
on that laptop, and I can't say I have noticed that Java is screwed up.

Roedy did write iPhone and iPad.

Somehow I think you are running those IDE's and app servers on
a Mac computer and not on iPhone/iPad.

I saw the iPhone/iPad part, but given the fact that Apple hasn't been
screwing up Java for anything else, which was my point, I'm somewhat
dubious that they are expending effort on screwing it up for anything.

If Apple is in fact pushing JavaScript for iPad/iPhone (and they could
well be, I don't develop for either device) all that means is that they
are pushing JavaScript. Not deliberately crippling Java, nor even not
supporting it. And if this is true then perhaps it means that Apple
thinks JavaScript is well-suited even if Roedy does not.

Apple are pushing very hard a no-VM policy on iPhone and iPad. So
no Java, no Flash, no CLR etc..

Arne

 

[jesbox]

 From Apples developer licence agreement for iPhone: [ ... ]
Applications must be originally written in Objective-C, C, C++, or
JavaScript as executed by the iPhone OS WebKit engine, and only code
written in C, C++, and Objective-C may compile and directly link against
the Documented APIs [...]

I get a clear impression that Java Applet (and JavaFX) is at least on
par with JavaScript etc. Of course there are differences, but I am
glad to hear that Applets are not obsolete or inferior as I was
fearing. So in many cases it would make sense to build both server-
side and client-side using Java. Probably it deserves to happen more
often. At least enterprise solutions would tolerate client start-up
times, if that remains an issue.

A notable exception is the iPhone/iPad platform where the JVM and Java
language is obviously forbidden.


Thanks for your answers!

(I can't resist to ask. Surely it would be possible to write a JVM in
JavaScript for iPhone? )

 

[Joshua Cranmer]

(I can't resist to ask. Surely it would be possible to write a JVM in
JavaScript for iPhone? )

Somehow I doubt the iPhone app reviewers would approve it. But given
that their approval process appears to mostly rely on a dart board....

 

[Andrew Thompson]

...So in many cases it would make sense to build both server-
side and client-side using Java. ..

The 'client-side Java' of that equation does not
need to be an embedded applet. It could be a plain
old desktop application, or a frame/applet launched
using JWS.

 

[Martin Gregorie]

(I can't resist to ask. Surely it would be possible to write a JVM in
JavaScript for iPhone? )

Its forbidden. The latest Jobsian Edict bans indirect execution, i.e.
using any type of intermediate code interpreter. I suspect this is
largely due to Steve throwing his teddy at Flash, but nonetheless its
part of the recently updated list of published hurdles that third party
apps must jump to get into the AppStore.

 

[Stefan Ram]

Its forbidden. The latest Jobsian Edict bans indirect execution, i.e.
using any type of intermediate code interpreter.

Formally, any program that takes any input is an interpreter
of a certain language. For example, when a program just has
two buttons [next] and [quit], the user input language is

<start> ::= { [next] } [quit] .

(I.e., an arbitrary repetition of [next], terminated by [quit].)

And as soon as the software has a configuration, this even
is a /stored source code/ of the configuration language
this software interprets at every start.

 

[Daniel Pitts]

Its forbidden. The latest Jobsian Edict bans indirect execution, i.e.
using any type of intermediate code interpreter. I suspect this is
largely due to Steve throwing his teddy at Flash, but nonetheless its
part of the recently updated list of published hurdles that third party
apps must jump to get into the AppStore.

Well, Apple probably can't do anything about a JVM implemented in WebKit
compatible JavaScript.

Although, the performance would likely be so abysmal that they wouldn't
need to do anything about it.

Hmm, actually. It would be interesting to see a HotSpot implementation
that converts from JVM ByteCode into JavaScript Then, hopefully the
JavaScript implementation could HotSpot the result even further! Rube
Goldberg, we need you!

 

[Daniel Pitts]

Hi Daniel,



Can you please explain further on how you are "using the DOM dispatcher
thread"? Are you still talking about the Liveconnect JSObject interface or
the Common DOM APIs?

I'm talking about the DOMService/DOMAction interface in:

How are you telling your JSObject.call() to execute on the "DOM dispatcher
thread" and, with reference to the following link, what choice do we have?
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_execution.html

I'm not telling the method to execute anywhere. I'm executing it myself
through the DOMAction/DOMService API mentioned above.