 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Virtual Machine / June 2006Which Java version to target?
Are there any up-to-date statistics available that give a good idea of what Java version most web users have installed on their machines? I'm developing a java applet as part of a web site, and I'd like to know that most users will be able to view it without any issues - as it is, if I compile it to target JDK 1.5, all the machines other than my own that I've tested it on won't load the applet, and worse still, don't give any sensible user feedback as to why. I accept there will also be a percentage of users with an exceptionally old java version installed (or worse still, none at all), but I'd like to keep this to a minimum without sacrificing too many features that come with the later java versions. > Are there any up-to-date statistics available that give a good idea of > what Java version most web users have installed on their machines? [quoted text clipped - 8 lines] > minimum without sacrificing too many features that come with the later > java versions. well, i'd stay with 1.4.lat.est, then. that's what i hate about java - no upward compatibility. other than that, it's fun! - nate wizofaus, > Are there any up-to-date statistics available that give a good idea of > what Java version most web users have installed on their machines? Great question. And while we're at it, what percentage of websites have a Java component? Someone must keep track of this stuff. It might help promote Java's adoption. Sudden Disruption -- Sudden View... the radical option for editing text http://www.sudden.net/ http://suddendisruption.blogspot.com > Are there any up-to-date statistics available that give a good idea of > what Java version most web users have installed on their machines? With regards to Java penetration of the desktop browser, the latest stat is here: http://www.thecounter.com/stats/2006/June/java.php I would strongly suggest using 1.4x >> Are there any up-to-date statistics available that give a good idea of >> what Java version most web users have installed on their machines? > > [...] > > I would strongly suggest using 1.4x Based on what reasons? I assume most people use the Windows on-line automatic update thing, which means they'll be using 1.5. OTOH, perhaps lots of corporate machines are stuck on ye olde 1.4. Tom Hawtin  SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > > Are there any up-to-date statistics available that give a good idea of > > what Java version most web users have installed on their machines? [quoted text clipped - 4 lines] > > I would strongly suggest using 1.4x That's my current intention. It means no generics, which as a C++ programmer is frustrating, but I can live with it. The site you gave doesn't actually give any version information though, from what I can see. Presumably it's not too hard to throw together some javascript/java combination that will detect the current java version and give a sensible error if it's not adequate (or even present), along with a link to download a latest VM. > > I would strongly suggest using 1.4x > > That's my current intention. It means no generics, which as a C++ > programmer is frustrating, but I can live with it. Take heart ! The absence of generics will probably make this easier for you -- Java generics resemble C++ templates in so few ways that your C++ experience would be likely to get in the way. -- chris > > > I would strongly suggest using 1.4x > > [quoted text clipped - 4 lines] > you -- Java generics resemble C++ templates in so few ways that your C++ > experience would be likely to get in the way. True, but for instance, I just wasted at least an hour today trying to figure out why I was getting an ArrayStoreException - turned out it was because I was accidentally adding the wrong object type to a Vector (and subsequently converting it to an array). Being able to declare as a Vector< > with the right type would have saved me that drama, as the compiler would have picked it straight away. [me:] > > Take heart ! The absence of generics will probably make this easier > > for you -- Java generics resemble C++ templates in so few ways that [quoted text clipped - 4 lines] > because I was accidentally adding the wrong object type to a Vector > (and subsequently converting it to an array). I am surprised. -- chris > [me:] > > > Take heart ! The absence of generics will probably make this easier [quoted text clipped - 7 lines] > > I am surprised. Surprised by what? Maybe years as a C++ programmer has made me careless from being too reliant on the compiler catching my screw-ups... > > > True, but for instance, I just wasted at least an hour today trying to > > > figure out why I was getting an ArrayStoreException - turned out it [quoted text clipped - 6 lines] > careless from being too reliant on the compiler catching my > screw-ups... Maybe something of that sort. I work with dymamically-typed OO languages a lot, and in my experience such errors are very rare (hence my surprise). It's not that I take extra care to avoid type errors in an language without type checking -- it's just not natural to make them in the first place. So maybe you have become "careless", but to me it seems more likely that the way you stucture your code is fundamentally different from the way I structure mine. That would be supported by it taking so long to track down the error. On the rare occasions when I do make type errors, it is normally obvious in seconds, and fixed in not much longer. Or maybe you were just unlucky ;-) -- chris >>> Are there any up-to-date statistics available that give a good idea of >>> what Java version most web users have installed on their machines? [quoted text clipped - 6 lines] > That's my current intention. It means no generics, which as a C++ > programmer is frustrating, but I can live with it. That's odd. I haven't used it myself, but I'd read that Java's generics facility involves no changes to the bytecode language. What happens if you try to compile with javac -source 1.5 -target 1.4 --Mike Amling >>> I would strongly suggest using 1.4x >> [quoted text clipped - 3 lines] > That's odd. I haven't used it myself, but I'd read that Java's > generics facility involves no changes to the bytecode language. The bytecode instructions themselves remain the same, but there are extra attributes added to the class files. > What > happens if you try to compile with > javac -source 1.5 -target 1.4 Try it. It wont. 1.5 has the undocumented and unsupported -source jsr14 (IIRC). Does anyone have any figures for which versions browsers have installed? The online installer for Windows should have updated most to 1.5. Windows/Solaris/Linux users that have used offline installers in the last year and three quarters will presumably mostly installed 1.5. No idea about Mac users, other than Apple is usually around a year behind. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > > What > > happens if you try to compile with [quoted text clipped - 9 lines] > last year and three quarters will presumably mostly installed 1.5. No > idea about Mac users, other than Apple is usually around a year behind. Most of the Windows systems I've tried it on only have 1.4.2_03, so that's my target at this point. But apparently even that's not enough - there are things that fail mysteriously under that version that work fine when you have the 1.5 JRE installed (e.g. JFrame.add() vs JFrame.setContentPane()), so you absolutely have to test on a system that only has 1.4.2 installed. The advantages of using Generics don't seem enough to be worth the risk that something's going to be behave unpredictably on another system, so I'm just getting used to having my code littered with casts. The fact that it took till version 1.5 of Java until there were typed resizable collections in the language is a little baffling to me. > Most of the Windows systems I've tried it on only have 1.4.2_03, so Seems a bit old. 1.4.2 is up to at least 1.4.2_11 (some of those security updates). > that's my target at this point. But apparently even that's not enough > - there are things that fail mysteriously under that version that work > fine when you have the 1.5 JRE installed (e.g. JFrame.add() vs > JFrame.setContentPane()), so you absolutely have to test on a system > that only has 1.4.2 installed. I'm sure you can develop it on a machine that has both 1.5 and 1.4.2 installed. > I'm just getting used to having my code littered with casts. The fact > that it took till version 1.5 of Java until there were typed resizable > collections in the language is a little baffling to me. It was dragged out, but it isn't so easy to retrofit such a feature. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > > I would strongly suggest using 1.4x > > That's my current intention. It means no generics, which as a C++ > programmer is frustrating, but I can live with it. It isnt too hard to use java -target 1.4 => target the 1.4 jvm using the java 1.5 compiler. Theoretically .... > I'm developing a java applet as part of a web site, and I'd like to > know that most users will be able to view it without any issues - as it > is, if I compile it to target JDK 1.5, all the machines other than my > own that I've tested it on won't load the applet, and worse still, > don't give any sensible user feedback as to why. It does not have to be that way. E.G. 1. An applet that uses generics can be compiled with a class format of 1.4. Then Java 1.4 can load the applet and pop a dialog warning the user that it requires 1.5. 2. A Java 1.1 applet can load an entire other applet (so it can check for necessary Java and load the 1.5 applet) 3. JWS wrapping the applet can specify a Java minimum version. HTH Andrew T. > .... > > I'm developing a java applet as part of a web site, and I'd like to [quoted text clipped - 8 lines] > format of 1.4. Then Java 1.4 can load the applet and pop a dialog > warning the user that it requires 1.5. That interests me...but at least with NetBeans, I haven't been able to get it to target an earlier version. You say a warning - what's likely to occur if they continue to use the application? > 2. A Java 1.1 applet can load an entire other applet (so it can check > for necessary Java and load the 1.5 applet) It does seem from what I've read elsewhere that this is the only reliable way of gracefully handling older JVM/JRE installations that works across all browsers. > 3. JWS wrapping the applet can specify a Java minimum version. I gather JWS is java web start - which seems to be related to starting standalone applications, which I've no need to do at this point. The main criteria I have for the application is for it to "just work": that is, I should be able to walk up to almost any reasonably up-to-date system, access the relavent web page, and have the applet available and functioning. Anything that requires any sort of download or setup procedure is a no-no. Of course, there will always be a percentage of users whose systems aren't adequately configured, and I want to be able to handle those as gracefully as possible, but the main aim is to keep those cases to a minimum. > The main criteria I have for the application is for it to "just work": > that is, I should be able to walk up to almost any reasonably [quoted text clipped - 5 lines] > gracefully as possible, but the main aim is to keep those cases to a > minimum. i hear ya. - nate > > .... > > > I'm developing a java applet as part of a web site, and I'd like to > > > know that most users will be able to view it without any issues ... > > 1. An applet that uses generics can be compiled with a class > > format of 1.4. Then Java 1.4 can load the applet and pop a dialog > > warning the user that it requires 1.5. > > That interests me...but at least with NetBeans, I haven't been able to > get it to target an earlier version. The commands are in the basic tools distributed with the SDK, but you need access to the earlier JRE version to make the process work correctly. I expect Netbeans has ways to connect into that, but I'm not here to tell you how to work an IDE I don't use (often). >..You say a warning - what's likely > to occur if they continue to use the application? A variety of things that usually result in exceptions or errors. > > 2. A Java 1.1 applet can load an entire other applet (so it can check > > for necessary Java and load the 1.5 applet) > > It does seem from what I've read elsewhere that this is the only > reliable way of gracefully handling older JVM/JRE installations that > works across all browsers. Nope. Some browsers have no Java at all. Your best bet for them is the (HTML 4.01 invalid) nested OBJECT/EMBED elements. > > 3. JWS wrapping the applet can specify a Java minimum version. > > > I gather JWS is java web start - which seems to be related to starting > standalone applications, which I've no need to do at this point. Nope. JWS can be used to launch applets as well. (If I had more time I'd hunt down the URL of an applet/ application I wrote that is JWS'd in both modes..) Andrew T. ... > > I gather JWS is java web start - which seems to be related to starting > > standalone applications, which I've no need to do at this point. > > Nope. JWS can be used to launch applets as well. > (If I had more time I'd hunt down the URL of an applet/ > application I wrote that is JWS'd in both modes..) E.G. http://www.physci.org/pc/jtest.jnlp http://www.physci.org/pc/jtest-applet.jnlp HTH Andrew T. > That interests me...but at least with NetBeans, I haven't been able to > get it to target an earlier version. Right click on your project, then choose Properties In the "Source" node, choose Source level: 1.4 Then click on the "Compiling" node, add "-target 1.4" (without the quotes) into the input field labelled "Additional Compiler Options" Or - as an alternative - use a JDK 1.4 for compiling inside NetBeans (Set it up through Tools -> Java Platform manager, then select it in the "Libraries" node of your project properties) Thomas > In the "Source" node, choose Source level: 1.4 > > Then click on the "Compiling" node, add "-target 1.4" (without the > quotes) into the input field labelled "Additional Compiler Options" You should also use -bootclasspath to point to the 1.4 rt.jar, unless you want to get totally confused. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >Reply to article by: wizofaus@hotmail.com >Date written: 12 Jun 2006 17:25:52 -0700 >MsgID:<1150158352.799695.267550@i40g2000cwc.googlegroups.com> >Are there any up-to-date statistics available that give a good idea of >what Java version most web users have installed on their machines? >I'm developing a java applet as part of a web site, and I'd like to >know that most users will be able to view it without any issues - as it [quoted text clipped - 5 lines] >minimum without sacrificing too many features that come with the later >java versions. This is the web and you should use HTML, DHTML, CSS, animated gifs, jpg, zips, javascript, etc, whenever and wherever possible. There is no good reason to use JAVA unless you have something necessary for your audience that can only conveyed using JAVA. Flash and JAVA and other technology should be reserved for rare occasions and compatibility should be restricted to no more than two revisions back. That means when using advanced technology, you should alienate those in your audience who refuse to keep up with technology. Since the higher the technology the more of your audience you alienate, hence the reason to keep it to a minimum. The Sage ============================================================= http://members.cox.net/the.sage/index.htm "All those painted screens erected by man to shut out reality -- history, religion, duty, social position -- all were illusions, mere opium fantasies" John Fowles, The French Lieutenant's Woman ============================================================= > This is the web and you should use HTML, DHTML, CSS, animated gifs, jpg, > zips, > javascript, etc, whenever and wherever possible. There is no good reason > to use > JAVA unless you have something necessary for your audience that can only > conveyed using JAVA. From what I heard, every browser has a slightly different API exposed to JavaScript. If you don't want to write browser specific code, Java might be the way to go. > Flash and JAVA and other technology should be reserved for > rare occasions and compatibility should be restricted to no more than two [quoted text clipped - 5 lines] > keep > it to a minimum. Are you saying the OP should go with the more recent technology, or go with older technology? - Oliver In comp.lang.java.advocacy, Oliver Wong <owong@castortech.com> wrote on Wed, 14 Jun 2006 13:46:22 GMT <OqUjg.39447$771.33987@edtnps89>: >> This is the web and you should use HTML, DHTML, CSS, >> animated gifs, jpg, zips, javascript, etc, whenever [quoted text clipped - 5 lines] > JavaScript. If you don't want to write browser specific code, Java might be > the way to go. Java applets are far heavier than Javascript. Of course applets in this context appear to be a bodge to work around a broken implementation of what's supposed to be standard Javascript. But at least applets are single-behavior -- if the environment's set up properly and the proper tags are used. <APPLET> has been deprecated, and <OBJECT> as suggested by W3 doesn't quite work. IE needs something *very* specific -- and in fact it looks an awful lot like an ActiveX reference (which makes sense since the Java plugin is an ActiveX implementation, which just happens to sandbox Java). <APPLET> was nice and clean, and <OBJECT> as specified by W3 isn't too bad, but Microsoft goofed even that up. Thanks, Microsoft, for breaking *both*. </sarcasm> In any event, Java .jar files *ARE* zip archives, with some minor addons (the only one I'm aware of is META-INF/MANIFEST.MF). >> Flash and JAVA and other technology should be reserved for >> rare occasions and compatibility should be restricted to no more than two [quoted text clipped - 8 lines] > Are you saying the OP should go with the more recent technology, or go > with older technology? Go with technology that supports the most revenue [*]. This may be specific to the business one's in; for example, if one knows that the customers will be Linux, then one can either go with a Firefox-only solution (great, especially with embedded SVGs) or with a solution that is as light as possible in the goofiness possible with Javascript, applets, JNLP/Java Web Start, layering, and XML transformations (since browsers such as dillo and lynx don't appreciate all of the niceties thereof -- in fact, they don't really appreciate *any* thereof). With an IE-only solution, one might be able to have slightly more flexibility (since IE attempts to do it all) but one also has to deal with IE's brokenness in a number of key areas, such as embedded SVGs, CSS2, and PNG transparency. Longer term, I for one hope IE's idiocies are dealt with, either by shooting IE, or by Microsoft fixing its bugs nice and robustly. (Given their track record, I'd worry.) Unfortunately, IE is the dominant browser. > - Oliver [*] customers roughly = revenue but it's not 1-1, obviously. Signature#191, ewill3@earthlink.net Windows Vista. Because it's time to refresh your hardware. Trust us. > >Reply to article by: wizofaus@hotmail.com > >Date written: 12 Jun 2006 17:25:52 -0700 > >MsgID:<1150158352.799695.267550@i40g2000cwc.googlegroups.com> > > >Are there any up-to-date statistics available that give a good idea of > >what Java version most web users have installed on their machines? <snip> > This is the web and you should use HTML, DHTML, CSS, animated gifs, jpg, zips, > javascript, etc, whenever and wherever possible. There is no good reason to use [quoted text clipped - 7 lines] > > The Sage The applet is essentially a WYSIWYG graphical form editor - supports drawing boxes, lines, text-boxes, images etc. on to a form, and moving, resizing etc. with the mouse. I don't doubt that it might (at a stretch) be possible with Javascript, but Javascript simply doesn't have the support libraries available that Java does. It's the only part of the application so far that requires Java: the rest is all CGI-backed DHTML. And yes, I generally agree that trying to support old technology for the sake of a larger market share is generally a short-sighted plan, but it's basically about striking a reasonable balance: there's no point trying to take advantage of every last little feature of the latest and greatest version of a particular technology if only 1% of your intended user base will be able to run your software, and equally, it's foolish to battle on with ancient feature-poor technology just for the sake of being able to support a handful of extra users that within a year or so will no doubt end up upgrading their systems anyway. wizofaus, > > This is the web and you should use HTML, DHTML, CSS, animated gifs, jpg, zips, > > javascript, etc Excellent advice Sage. As simple as possible, but no simpler. > latest and greatest version of a particular technology if only 1% of > your intended user base will be able to run your software, and equally, > it's foolish to battle on with ancient feature-poor technology just for It's the old law of disproportionality. Shoot for the sweet spot in the middle. f.ck the fringes. They'll be addressed by some nich market anyway. > Being able to declare as a Vector< > with the right type would have saved me that > drama, as the compiler would have picked it straight away. The strength of strong typing originally brought to the world by Modula-2. It was called the bondage and discipline language and lots of people hated it - right up until they started debugging.. The more you are FORCED to define, the less will be assumed. Beware the assumption. Sudden Disruption -- Sudden View... the radical option for editing text http://www.sudden.net/ http://suddendisruption.blogspot.com > The applet is essentially a WYSIWYG graphical form editor - supports > drawing boxes, lines, text-boxes, images etc. on to a form, and moving, > resizing etc. with the mouse. I don't doubt that it might (at a > stretch) be possible with Javascript, but Javascript simply doesn't > have the support libraries available that Java does. You might be interested in http://www.ajaxsketch.com/ - Oliver >> The applet is essentially a WYSIWYG graphical form editor - supports >> drawing boxes, lines, text-boxes, images etc. on to a form, and [quoted text clipped - 3 lines] > > You might be interested in http://www.ajaxsketch.com/ Nice... Their motto is "Ajax for everyone...", so I tried it in IE... "OOPS! - Firefox 1.5 (or higher) Required..." :-D SignatureDag. > >> The applet is essentially a WYSIWYG graphical form editor - supports > >> drawing boxes, lines, text-boxes, images etc. on to a form, and [quoted text clipped - 9 lines] > > "OOPS! - Firefox 1.5 (or higher) Required..." It's certainly impressive for what it is (though obviously incomplete - undo/redo appears not to work, and I couldn't see anywhere to set the rounded corners on rects), but anything that doesn't work under even the latest IE is hardly viable at this point. I actually wanted to use SVG originally as the basis for my form editor, but SVG doesn't natively support embedding HTML text. Mine has an in-place text editor that is basically a mini-word-processor, allowing the control of text formatting, paragraph alignment, bullets & numberings etc. etc. I actually know this much is quite doable in Javascript, as I've seen it done (FCKEditor), but it was reasonably straightforward in Java, using the HTMLEditorKit/JTextPane classes (although it needed a lot of tweaking to get things to behave the way they should). Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.