I've just noticed that in https://jdk6.dev.java.net/testProperty.html the version download is listed as only applying to WebStart and not also for Applet's.
Old-style (non-JNLP) applets use a different mechanism for versioning jars than Java Web Start does.
To be honest I am not sure how the new functionality interoperates with new-style applets launched via JNLP. We have an open bug about jar versioning in the context of JNLP applets that we're still investigating.
My main interest has been WebStart rather than applets, but 6u10 means the same solutions now apply to both.
If you can host the DownloadServlet, then jardiff can dramatically improve the time taken to get an updated version.
Using versions also reduces the time taken to test that the current version is up to date. If nothing has changed, it (should) only take a single round trip to verify the date of the JNLP file. The latest build means that this should also work with a cheap hosting solution as no configuration/servlet is needed. In this case you would lose jardiff, but gain lots of extra bandwidth. The loss of jardiff could be mitigated by keeping the size of individual jar files down and hoping that updates don't affect too many of them.
A possible nice addition would be a DownloadServlet that could send a redirect to the client for items that could be more efficiently retrieved elsewhere. This would allow the initial download to be retrieved from a fast host, while returning jardiff updates directly. The idea here is that you host the DownloadServlet yourself (on a relatively slow connection) but also post copies of larger resources on a cheap hosting service. The download servlet can then estimate if the jardiff can be sent more quickly than the complete update. It might even upload frequently requested jardiffs to the fast host and send redirects for those too.
> A possible nice addition would be a DownloadServlet
> that could send a redirect to the client for items
> that could be more efficiently retrieved elsewhere.
> This would allow the initial download to be retrieved
> from a fast host, while returning jardiff updates
> directly. The idea here is that you host the
> DownloadServlet yourself (on a relatively slow
> connection) but also post copies of larger resources
> on a cheap hosting service. The download servlet can
> then estimate if the jardiff can be sent more quickly
> than the complete update. It might even upload
> frequently requested jardiffs to the fast host and
> send redirects for those too.
This sounds like a good idea. I would encourage you to consider starting a java.net project to do this. You might be able to drum up some support from developers on these forums, including the Java Web Start forum. Right now within Sun we are fully booked and are currently focusing on solutions that don't involve server-side support, but I agree that with the right server infrastructure (and hopefully only a little bit) you can get significant improvements.
I am reasonably familiar with the DownloadServlet (I have an internal extension that accepts uploads, and manages version ids). This proposal would (I think) need changes to the client as well to get it to accept the redirect. Is the client side code available?
It might be useful if the redirect was accompanied by an MD5 digest of the file so that the client could be sure it received the intended file. We could even encrypt the file and supply the key with the redirect. The redirect could then provide speed without sacrificing security for those that need it.
P.S. I did start on a project within JDIC to provide a PHP version of the DownLoad servlet. Unfortunately weaknesses in PHP and hosting support made this more difficult than I had hoped. Your recent changes to remove the need for special server features make that work largely redundant.
Glad the new plug-in is mostly working for you.
> The browser status bar (in IE or FF) is no longer
> getting status updates with Plugin2. Is
> AppletContext.showStatus() not going to print stuff
> to the browser bar anymore, or is that feature just
> not implemented yet? Currently, when
> AppletContext.showStatus() is called with Plugin2,
> the string goes to the Applet console as "Applet
> status: %s".
Are you sure this isn't working? This was integrated in 6u10 build 12 under 6620516. If it is not working, could you please provide a small and self-contained test case?
> Another anomaly I noticed was that my applet flashes
> on FF3 Beta 4 (and not on FF2 or IE6). When
> sure what the deal is there, some painting issues wrt
> plugin on FF3 maybe? I do not have any black CSS
> styles in the parent HTML or black background
> painting anywhere in the applet as far as I know, so
> either the plugin or FF3 is painting all black.
If you can provide a small test case for this as well we'll look into it. Note that we already have an outstanding bug, 6673601, about repainting / flashing issues during applet startup.
> Finally, I'd like to make one feature request before
> you close the book on plugin2. If you're going to
> add parameters and attributes to the plugin2 now, I
> figured I might as well make the request for just one
> more new parameter. :) Could you allow the plugin
> to download the Applet jar via Bit Torrent as a first
> choice (and then plain old HTTP request as a
> fallback/after a timeout?) I don't have the
> bandwidth to serve massive amounts of concurrent
> requests for my applet jar, which is why I went
> through the trouble to implement an AJAX waiting room
> to throttle requests. But, if the Java plugin
> shipped with a mature free software Bit Torrent
> library to optionally execute my download, why, that
> would really save me on bandwidth and save my users
That's a fairly radical proposal. I can tell you quite frankly that there is no way we are going to have time to consider incorporating such a feature in 6u10, but we could possibly consider it for a future release or update release. You should feel free to file an RFE about it, but please carefully think it through and come up with a solid proposal for how it might work.
> Are you sure this isn't working? This was integrated
> in 6u10 build 12 under 6620516. If it is not working,
> could you please provide a small and self-contained
> test case?
Your comment here made me think that my configuration was borked, so obvious a feature change could not be missing. So, looking at java version names and whatnot, I did discover that the plugin the browser was selecting was a Dec07 JDK7 build I had installed in January. I had forgotten about that, and my JAVA_HOME is not set to that install, so the only place it was showing up was in the browser. After whacking away at the registry and file system, I purged that JDK7 and all other 6 series, and reinstalled the beta JDK1.6.0_10.
On my applet console and on the java command line, I now see the correct "JDK1.6.0_10-beta" version number confirmed for both plugin and JRE. Sigh, version hell, I wish this stuff was easier.
Anyhow, with the right JRE installed, the plugin behavior is better. I do see the browser's status bar change (on both IE and FF) with my AppletContext.showStatus() calls. However, I do still see "Applet context: %s" messages printed to the applet console as well. Is this beta behavior, do you plan to remove the messages from the applet console for the shipping release of the plugin? (Or am I still borked?)
The 1.6.0_10 plugin still shows a black flash when the applet is first displayed on FF3 beta 4. I will try to rig up a simple applet that displays the effect and file a bug report. The black flash is not apparent to me on IE6 or FF2 with 1.6.0_10-beta.
> That's a fairly radical proposal. I can tell you
> quite frankly that there is no way we are going to
> have time to consider incorporating such a feature in
> 6u10, but we could possibly consider it for a future
> release or update release. You should feel free to
> file an RFE about it, but please carefully think it
> through and come up with a solid proposal for how it
> might work.
I understand this is radical sounding, and your response is what I was hoping for. I trust you're not just humoring me here. It's ok if my ideas cannot be incorporated in this release, although the sooner the better. Every release is just a stopgap for the next one; my feature can hop on the next train or two when they pull into the station. :)
I would like to do a good job with this Bit Torrent RFE. I will search for examples to base mine off of and guides on how to write one. Do you have a favorite RFE that was successfully implemented that I can base mine off of? Also, just off the cuff, do you think I will have better luck gaining acceptance of my RFE by suggesting Bit Torrent as the peer-to-peer transport technology or a Sun technology like JINI? I can list merits to picking either in my mind.
I may not have time to begin work on my bug report or RFE until the weekend.
> Anyhow, with the right JRE installed, the plugin
> behavior is better. I do see the browser's status
> bar change (on both IE and FF) with my
> AppletContext.showStatus() calls. However, I do
> still see "Applet context: %s" messages printed to
> the applet console as well. Is this beta behavior,
> do you plan to remove the messages from the applet
> console for the shipping release of the plugin? (Or
> am I still borked?)
I've filed 6681823 to track this issue. It will show up on the Sun Bug Database in a day or two. We'll fix it soon.
> The 1.6.0_10 plugin still shows a black flash when
> the applet is first displayed on FF3 beta 4. I will
> try to rig up a simple applet that displays the
> effect and file a bug report. The black flash is not
> apparent to me on IE6 or FF2 with 1.6.0_10-beta.
Please post your test case here. I'll either file the bug on your behalf or attach it to the preexisting bug 6673601.
> I would like to do a good job with this Bit Torrent
> RFE. I will search for examples to base mine off of
> and guides on how to write one. Do you have a
> favorite RFE that was successfully implemented that I
> can base mine off of? Also, just off the cuff, do
> you think I will have better luck gaining acceptance
> of my RFE by suggesting Bit Torrent as the
> peer-to-peer transport technology or a Sun technology
> like JINI? I can list merits to picking either in my
I'd suggest looking at http://bugs.sun.com/view_bug.do?bug_id=6606784 .
Saw a video of you on Ajaxian talking about plugin2, you're a great spokesman for Java and Sun! I hope I get the chance to thank you in person someday for the work you are doing here.
> Please post your test case here. I'll either file the
> bug on your behalf or attach it to the preexisting
> bug 6673601.
I made up a testcase for the black screen issue I was seeing on Firefox 3.
I get the applet to draw properly by subsequently resizing the form element that contains the applet. This resize appears to kickstart the plugin or the applet and gets it to draw the applet into the browser correctly. I do not see the black screen issue on IE6. If I position the applet absolutely or relatively, it trips the applet to redraw as well.
In case my problem is hardware/OS dependent, I am seeing this effect on WinXP SP2, Lenovo Thinkpad T60p, ATI Mobility FireGL V5200. My Java Console says:
Java Plug-in 1.6.0_10-beta
Using JRE version 1.6.0_10-beta Java HotSpot(TM) Client VM
Thanks again for everything,
"...here's why: when a client calls me for an applet jar, he is making the request for my jar, on my terms. "
I really disagree with that assumption. I think exactly the opposite is true. I think I should give the applet to the client on his/her terms to the best of my ability -- excluding support for Microsofts old VM of course :-)
We all here on this forum could probably come up with examples and counter examples but I think the over riding consideration is the same used by business in general, "...the customer is always right..."
On the other hand, I think the Plugin2 development team should pull out all the stops and really make Java better than Flash and QT for deployment of multi-media applets.
How they would do that I don't know but it would be really great to be the big dog for once instead of the apologist -- as in -- sorry that the applet didn't run, did you try to set the JVM memory parameters higher in the Java Control Panel? etc.
Or sorry it my applet doesn't run in BrowserX. Did you try it in BrowserY?
I have a lot of time invested as a Java programmer specializing in Java applets and I'm really tired of eating crow...
The mode of transport for the applet jar is selected by me today, not by my users. I can specify http or https, and they just have to take it. So far, I haven't had any complaints.
Extra large scale software deployments use Bit Torrent today as their software distribution mechanism. World of Warcraft is the most interesting example I've seen. Do their users complain? Yes, lotsa bellyaching! Last I heard, they had 8 million subscribers and climbing, so they're not doing too bad - and I'm sure they're saving heaps of money on bandwidth savings.
Anyways, I think there's a precedent for laying the distribution costs onto my users. Heck, right now I'm not even charging my users for service (my choice), so they could show some gratitude by doing their part! :)
Savvy users would disable the bit torrent feature anyhow, and unsavvy ones wouldn't know nor care that it was running. How different is this from skype's leeching of your bandwidth in order to give everyone something sweet: free worldwide phone calls? I want to give you something sweet: CardMeeting! :P And what about browser cookies or CPUID? Sure the savvy users cried foul ... at first, and today those savvy users regularly run spyware blockers to crunch the cookies or turn off CPUID in their BIOS.
What I'm noticing is, you're playing the savvy user - and you're spreading some early warning FUD here. But I'd ask for you to get a little visionary too: we could make applets a whole new kind of cool here if we could work out the jar distribution. You wanna drop a new 10 meg jar on your community once a week and load it with -Xmx256m? "Ok, not a problem boss, don't even need to upgrade the internet connection. The new plugin makes it possible." Do you want Applets not to suck anymore, or what? Sounds like you have languished like me. Plugin2 is looking really sharp as it is, now let's kick it up a notch!
Maybe my idea isn't going to work for whatever technical reason that I can't fathom. Simply as a tech, I am looking at the free/open source bit torrent libraries available on Java, and I see they're some of the finest implementations there are. Why NOT leverage these gems in the plugin for [i]all[/i] of our collective gains?
I have an idea --
Why do you write a Java Plugin that uses BT to the max and prove your concept both in technical feasibility; usability in a real WAN; acceptable by the masses on all browsers using all the various flavors of Java.
Kick it up a notch. Show us what you got.
Sounds like you got a real winning idea. Shouldn't be hard to get some VC and become a millionaire. I'm convinced...
Heck yeah! And if Sun isn't into it, maybe Googlicious would be. Could get a SoC student to prototype something for us.
I honestly don't know how I could pitch something like this to a VC. But, I don't think a focused addition to the plugin requires separate funding. I think the most critical thing something like this needs is total buy-in from Sun and a certified spec from them as to what they would expect. Beyond that perhaps the implementation could be community driven rather than an internal effort if the work was too much for Sun to take on. I would be interested in participating in something like that since it directly helps me, and I have Java/C++ chops to boot. If Sun wasn't hip to this idea, then it's a non-starter; its gotta be in the reference implementation of Java to be worth anything.
What say you, Sun? Are Bit Torrent'ed or JINI'd applet jars too far out an idea? (C'mon, please say no!) If you're not into it, then I'll need you to take back all that stuff you said about the network being the computer before. :)
I'd vote against BitTorrent for one reason: performance.
It's not that a BitTorrent component is a radical idea. It's that it requires a long startup time. If applets were to run of it I'd expect startup times counted in minutes, not seconds, and that's simply not an option.
Why so negative on ol' BT? I think your notion of 'slow' really depends on the number of seeds/peers and one's firewall settings. With my situation, we're looking at people connected to my server for many hours. Potentially, (if everyone has the new plugin), I could have 10-20 seeds serving on my behalf at any one time.
I thought I was careful to suggest that BT would/could be a primary distribution mechanism, but one's client could fallback to HTTP after a timeout if the BT wasn't performing.
Anyhow, just to give you an idea of the problem with these here applets ... When my site is busy and teams are trying to login all at once, users can see 90+ second download times, even with my AJAX waiting room making them get in line and throttling their applet startups. I don't think the answer is for me is necessarily getting better bandwidth since I could use any extra bandwidth I buy for other useful things than simply passing out applet jars.
Given my paltry connectivity to the internet right now, are you telling me 20+ seeds on a BT swarm couldn't do a better job than my 90+ second HTTP unicast stream? I think a BT swarm could do MUCH better than me at this point.
Another reason I question your negativity is that today's slow is tomorrow's not-so-slow. The question is always scale. How many people can I reach with my applet? Today or tomorrow, how much I can scale and how wide my reach is is dictated by how much money I pump into the thing. I'm just saying that Bit Torrent distribution [i]as an option[/i] potentially cuts a large amount of that cost for me, especially while I'm bootstrapping something big.
Applet sandbox security says I gotta serve my own Jar if that Jar is going to contact me. Fine, I'll serve it, I'd just like some more creative options on how I serve it.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.