Skip to main content

Plugin2 design could use a little love - too harsh

4 replies [Last post]
davester
Offline
Joined: 2007-01-26
Points: 0

Dear Plugin2 designers/developers,

I have been working on an applet for over a year now that has been PAINSTAKINGLY crafted to support Java all the way back to JRE 1.3.1. I employed tons of HTML/CSS, servlet, and AJAX tricks to make your plugin start, crash rarely, and (as reliably as you will let me with the Plugin1) have Java interact with JavaScript in the browser.

I have to support such ancient JRE's because my clients work in cruddy IT departments that don't care about their users and they have desktops that got a 1.3 or a 1.4 certified and never upgraded for whatever reason. Asking them to upgrade is like speaking moon language and you get laughed at. Asking me to decide to choose between plugin1 and plugin2 is equally painful.

I see statements in your https://jdk6.dev.java.net/plugin2/ page that disturb me. And I would like to request, before you really unleash plugin2 onto the scene, that you consider my requests for changes. If you are going to upgrade the plugin (THANK YOU), and you're going to enable it by default, I think it's reasonable for me to expect some sort of wiggle room such that my tags will work ok for pre-1.6u10 Java's as well give some new benefits to the post 1.6u10 Java's.

Here are the features I rely on in plugin1 -

For the IE browser, I use the following object tag:

For non-IE browsers, I use the following object tag:

And for the Java-to-JS communications, I use:

java.applet.AppletContext.showDocument(uri, target);

where uri coming from me can either be a javascript: or http: url. And target is an iframe that is homed at the same context root as the applet. Please do not make any new policies about what uri can or cannot be - just pass it to the browser as-is in plugin2, just like you did in plugin1. In other words, don't run it through URL first to check for correctness or whatever, just trust the browsers to do the right thing. As I have been made painfully aware, showDocument() is my only reliable way to talk to JavaScript in plugin1, so I would like that to perform equivalently in plugin2.

I would also like to request that you NOT mark type="application/x-java-applet;version=1.3.1" as deprecated on the object tags. That is REALLY vital to good object tag behavior on pre-1.6u10 Java's. I like the new syntax of , that is so much easier to understand. I would just like to be given a little wiggle room here and have type="application/x-java-applet;version=1.3.1" be treated as the equivalent of in the new plugin and not be deprecated along with jpi_version (which I agree, should die a horrible death.)

And of course, assuming equivalence with java_version, I request that I be allowed to use the type="application/x-java-applet;version=1.3.1" attribute alongside the new param tags for java_arguments, separate_jvm, etc, and have those work as documented... (Man, I can't wait to see those arguments in action! Wahoo!!)

Plugin2 is going to lead to a radically improved applet environment! Thank you so much for making this much needed upgrade, I'm really looking forward to seeing Java expand on the desktop as a result. Please don't forget the "write once, run anywhere" motto, please make sure plugin2 is not hostile to unfortunate plugin1 users!

Cheers,
Dave Woldrich
http://CardMeeting.com

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
davester
Offline
Joined: 2007-01-26
Points: 0

Hi kbr,

I upon closer reading that I mistyped when I said I would use the following tag under my IE object tag:

That's asking to give me a JRE in the 1.3 family and ONLY in that family, which is not what I'm aiming at.

Instead, I will use the following tag for IE:

which I expect should give the user a JRE that is 1.3.1 or later.

Now, the language and descriptions on the https://jdk6.dev.java.net/plugin2/version-selection/ page seems to be very family focused, not showing minor version numbers demonstrated in the values for java_version when combined with the + or *.

I just want to make sure that it will be legal to specify

in plugin2 and have that still mean "load highest family/version/minor JRE greater than or equal to 1.3.1". I do not want to have to say

because 1.3.0 is not feature complete enough for my app and I don't want to inadvertently load it in the impossible case that someone has 1.3.0 and tries to run my app. 1.3.1 is the floor for my app and I'd like to support the unfortunate souls that are stuck at that decrepit level. I know I'm sounding nitpicky here, but if I ever find myself forced to upgrade to the 1.4 family, I'm going to want to do the same thing (never load 1.4.0/1 and only load 1.4.2 and higher.)

Ok, sorry, I read now that the plugin2 isn't going to support 1.3.1, it's only going to support 1.4.2 and higher. I guess that's an fine choice, given that you will let me support plugin1 users with my tags while also optionally tapping the new features of plugin2 for those users that have it. So maybe it only makes sense to specify the following for my IE tag ...

I am comfortable with that, that is what I will do. Nevertheless, I still think the java_version should understand and accept minor version (and update for that matter) with + or *, just for maximum flexibility.

Thanks again,
Dave Woldrich
http://CardMeeting.com

kbr
Offline
Joined: 2003-06-16
Points: 0

One point. Only the new plug-in pays attention to (or ever will pay attention to) the new "java_version" parameter. It's technically infeasible to ever backport support for obeying this parameter in any circumstances to the old plug-in.

Since the new plug-in will first be released with Java SE 6 Update 10, if you say

this is a no-op. If the new plug-in is available to pay attention to this tag, it will inherently have a later release than 1.4 available.

So basically you don't need to change your applet tag at all.

The java_version parameter is mainly intended for enterprises which QA their applets against either a particular family or a particular release and want to be able to require that only that family or version is used to run the applet. We generally advise against this, because later Java releases are supposed to be backward compatible, but there are certainly valid use cases for it which is why we provide the new functionality.

kbr
Offline
Joined: 2003-06-16
Points: 0

Thanks very much for your careful feedback on the new plug-in.

With the new plug-in we want to get as close to 100% backward compatibility as possible. If a regression in behavior or functionality is technically feasible to fix, we will fix it. We don't want you to have to make a decision between supporting the old and the new plug-ins.

Here are some responses to your specific concerns:

> Please do
> not make any new policies about what uri can or
> cannot be - just pass it to the browser as-is in
> plugin2, just like you did in plugin1. In other
> words, don't run it through URL first to check for
> correctness or whatever, just trust the browsers to
> do the right thing. As I have been made painfully
> aware, showDocument() is my only reliable way to talk
> to JavaScript in plugin1, so I would like that to
> perform equivalently in plugin2.

I've checked the code and I believe this should behave exactly the same in the new plug-in as in the old one. Note that AppletContext.showDocument() takes a URL as argument, not a String, so it has to at least be a well-formed URL. Note though that we've tested this functionality internally with both http: and javascript: URLs and both should be working exactly as in the old plug-in.

> I would also like to request that you NOT mark
> type="application/x-java-applet;version=1.3.1" as
> deprecated on the object tags. That is REALLY vital
> to good object tag behavior on pre-1.6u10 Java's. I
> like the new syntax of > value="1.3.1*">, that is so much easier to
> understand. I would just like to be given a little
> wiggle room here and have
> type="application/x-java-applet;version=1.3.1" be
> treated as the equivalent of > name="java_version" value="1.3.1*"> in the new plugin
> and not be deprecated along with jpi_version (which I
> agree, should die a horrible death.)

Don't worry -- if you request 1.3.1 in the object tag's type attribute then the new plug-in will simply ignore it and run the applet on the current (latest) JRE version, which is probably what you want to have happen. Please note that from a semantic standpoint the version is and always has been a minimum version request, not a family version request, so as per the new version selection documentation (https://jdk6.dev.java.net/plugin2/version-selection/) it would be translated to "1.3.1+" anyway, which would still cause the applet to be run on the latest JRE version.

> And of course, assuming equivalence with
> java_version, I request that I be allowed to use the
> type="application/x-java-applet;version=1.3.1"
> attribute alongside the new param tags for
> java_arguments, separate_jvm, etc, and have those
> work as documented... (Man, I can't wait to see
> those arguments in action! Wahoo!!)

This already works. All version requests bottom out into the same underlying mechanism. I don't remember whether we've currently specified which one wins if you have redundant version requests. We can try to formalize this if it is important to you.

> Plugin2 is going to lead to a radically improved
> applet environment! Thank you so much for making
> this much needed upgrade, I'm really looking forward
> to seeing Java expand on the desktop as a result.
> Please don't forget the "write once, run anywhere"
> motto, please make sure plugin2 is not hostile to
> unfortunate plugin1 users!

We are doing our best and need your feedback and in particular your help in testing the new plug-in. Based on the above I believe your applet should run just fine in the new plug-in. Please try it and post if you run into any problems.

davester
Offline
Joined: 2007-01-26
Points: 0

Hi kbr,

Thanks for the quick response! This is a hot topic, man I'm jazzed about the new Java. I haven't tested CardMeeting with the new plugin, but I shall forthwith and report if I see problems.

Anyhow, two quick comments on your response:

> > do the right thing. As I have been made painfully
> > aware, showDocument() is my only reliable way to
> talk
> > to JavaScript in plugin1, so I would like that to
> > perform equivalently in plugin2.
>
> I've checked the code and I believe this should
> behave exactly the same in the new plug-in as in the
> old one. Note that AppletContext.showDocument() takes
> a URL as argument, not a String, so it has to at
> least be a well-formed URL. Note though that we've
> tested this functionality internally with both http:
> and javascript: URLs and both should be working
> exactly as in the old plug-in.

Ok sounds like we are of the same mind. I've just had a run-in recently with AppletContext.showDocument() failing on Konqueror with javascript URL's due to some funky additional security some wiseguy thought he would inject into their plugin. I didn't want to see that become a pattern with Sun's standard implementation because having the javascript: url's work on showDocument() is *absolutely critical* to my maintaining a smooth user experience on the older JRE's.

> Don't worry -- if you request 1.3.1 in the object
> tag's type attribute then the new plug-in will simply
> ignore it and run the applet on the current (latest)
> JRE version, which is probably what you want to have
> happen. Please note that from a semantic standpoint
> the version is and always has been a minimum version
> request, not a family version request, so as per the
> new version selection documentation
> (https://jdk6.dev.java.net/plugin2/version-selection/)
> it would be translated to "1.3.1+" anyway, which
> would still cause the applet to be run on the latest
> JRE version.

Exactly. What have been expressing is a minimum version request where the plugin has the right to upgrade me to whatever major/minor version is installed that is greater than or equal to 1.3.1. I have never liked the idea of pegging my users to any specific version/update of the JRE, so these are the semantics I'd like to see from the java_version="1.3.1*" if I were to ever use that. And it sounds like I will.

> This already works. All version requests bottom out
> into the same underlying mechanism. I don't remember
> whether we've currently specified which one wins if
> you have redundant version requests. We can try to
> formalize this if it is important to you.

Referring to https://jdk6.dev.java.net/plugin2/version-selection, the page gives the following fair warnings about combining old and new styles:

"Specifying both the java_version parameter as well as either a static or family classid will result in undefined behavior."

and

"Note also that combining the version attribute with the java_version parameter is not supported. Specifying both the java_version parameter as well as a version attribute will result in undefined behavior."

I won't combine the attributes, that makes sense, however there are deprecation warnings as well:

On the use of type='application/x-java-applet;version=xxx' you say, "Note that this backward compatibility mechanism may be removed in a future release." That was the line that drove me to write. As long as you can assure me that you won't ever deprecate the type method of specifying the applet version (and not freakout if I specify something ancient like 1.3.1), then I think we're good.

Finally, as far as IE is concerned, I'm used to disappointment. You wouldn't believe the struggles and the ANGUISH I have endured to get things working just the way I like it. So, if you break me there, don't worry, I'll fix it. Looking at the discussion of the dynamic clsid, it sounds like you will work - and in fact, it looks like you will fill a hole in my IE tags with the java_version param. Before with plugin1, I wasn't ever able to find a way to specify the dynamic clsid AND also set a version floor of 1.3.1. And now I can! KUDOS!

Wow, I can't believe we're finally talking about spawning separate vm's for applets and setting max memory. FANTASTIC! I suppose the next thing you're going to tell me is that we're going to be able to do Applet-to-Applet and Applet-to-JavaScript mashups next with JavaBeans! ;)

Cheers,
Dave W.
http://CardMeeting.com