Skip to main content

J2SE Public Beta Testing Call - Auto Java Update

8 replies [Last post]
stanleyh
Offline
Joined: 2004-02-02
Points: 0

J2SE Version 1.4.2_01 will be released with two new features:

* Auto Java Update
* Windows Install from the Web

Grab the chance to help Sun test these two Java software features
starting June 23 through July 11, 2003 plus the chance to get a cool
T-shirt. Testing will include downloading, installing, and updating a
test version of the J2SE Java Runtime Environment (JRE) v5.5.5.

Get the testing details now at:

http://java.sun.com/j2se/5.5.5/

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
osbald
Offline
Joined: 2003-06-13
Points: 0

Well I've got a whole host of comments I'd like to make, and would if only your feedback site was actually working.. Here's what I found:

Auto Java Update

Of course I've attacked this as your average co-operate user, someone with user domain login to a vanilla Windows XP box - no security polices in force, plain average and increasingly reflects the situation the majority of business users. Installing update as a developer with his own heavily customised build of Win 2000 with all the admin rights going doesn't make much sense here - I can install runtimes with my eyes shut.

First off tried to install j2re-5_5_5-test-windows-i586-iftw.exe ; got stoped-in-my-tracks pretty quickly with the message "This account does not have sufficient privileges to install the Java VM".
[i]Actually because I hadn't logged into this XP box before I got a "Cannot proceed with current Internet connection settings" message first, because it had defaulted to modem settings and not the LAN. Thought that was a good catch on your side ~ normally installshield would just barf.[/i]

Bug#4657166 says that since hooper, the install program will request an elevated login prompt (like it does for the control panel tools).. this didn't happen with 5.5.5 (or 1.4.2 - in fact I've only ever seen this with j2ee 1.4 installs).

Tried upgrading my user privs to the machine (required admin login) to power user, didn't get any further with the j2re-5_5_5-test-windows-i586-iftw.exe. So next I followed the instructions in Bug#4431060 about configuring the local polices (lots of regedit as admin) to allow installers to run themselves with enhanced privileges - again apparently fixed since hooper - again it didn't work with 5.5.5 same old "This account does not have sufficient privileges".

So eventually I gave in and logged in as the local admin to complete the install process. But is this really acceptable to expect every user on the network to have been granted administrator rights? Once I was admin everything worked seamlessly. After installing I went into the plugin control panel and checked the auto update settings which were "Ask before downloading and installing" and check daily.

Next playing joe average again I assumed our kindly sys_admin had left the building (after installing the runtime for me) and logged back in as my domain user. Going back to the update settings I noticed they had changed to "Ask before installing" and check weekly? Why are these suddenly different? isn't it going to upset people if you're going to be downloading 20megs without asking first? and since when does Sun release runtimes on a weekly (let alone daily) basis?

Onto the next step, clicking on "update now"; now I'm presented with another error (but by now familiar) message "Please login to an account with administrative permissions" - of course update is running with my user privileges, as are all java programs - playing second fiddle to any security polices Windows see fit to enforce. Will this message be repeated daily or weekly? whenever it tries and fails to update? how tired will that get?
The upshot of this is that unless the administrator comes back and logs in at 7pm on a Sunday evening the automatic update isn't going to succeed (ok - or he clicks the manual update button) basically the runtime isn't going to get updated in the normal course of events. Not a desirable feature of a Java Update program.

Furthermore I noticed that logged in as my domain user I cant change many of the settings in the Java plugin panel, guess I don't have the privileges. So its not possible to turn off the automatic updates, cant change how often they happen or what prompts are created. Nor could I turn off the plugin or opt out of the Internet Explorer integration.. they're may be others - but you get the idea.. not so good.

Of course I haven't done the update yet; but it's a moot point by now (not going to happen). My other major concern is how safe is it to start automatically updating runtimes anyway..? in my experience this is a very unsafe idea, many programs will simply break when faced with a new untested jvm.. I know Java magic should mean this isn't an issue but in the real world it can be critical (just as the IDEA boys why they ship a known jre). You might say, just because it's installed doesn't mean it gets used but unfortunatly web start complicates matters - first off web start gets reinstall led with the jvm wiping or reseating your active version - secondly most JNLP will request platforms like 1.3+, or 1.4 .. which will actively seek out an use the new JVM - It's easy to see the kinds of problems this is going to cause. Is joe bloggs the user best suited to be making these choices?
A means to opt in & out of the auto-updates would seem necessary based either on a domain-wide setting or a separate JVM install.. JVM with auto-update; JVM without..

OK, so I'm baised here http://www.javadesktop.org/forums/thread.jspa?threadID=84&tstart=0 - but I think these present some serious issues and challenges to the update teams if you're going to suceed (and I REALLY want you to) finally getting java on the desktop.

Auto-Update; What do we think of it so far..?

- Richard

PS: Now where's my T-Shirt ;)

stanleyh
Offline
Joined: 2004-02-02
Points: 0

Java Auto Update is aimed for users who has administrative privileges. The installer elevated priviledges problem is interesting, and we will take a closer look to see if the problem is introduced recently.

The other problem you ran into was related to the fact that UIs for Java Update were shown to normal users even they don't have permissions to modify the settings. We will fix this problem in the final release by removing/disabling the UI that doesn't make sense to general users from the control panel, so normal users won't be confused about the UI options.

Thanks for your detailed feedback.

Stanley

osbald
Offline
Joined: 2003-06-13
Points: 0

Hi Stanley,

Thanks for the reply, I was beginning to think you'd forgotten (ref Javalobby ;))

Does this mean that Java Update is still running for the 'normal' user but you'll be disabling their ability to change the Java Update Settings or Java Update itself will be disabled? Because the user won't actually be able to install any updates I'd prefer the latter - it was a bit of a worry that the options for normal users appeared to change to "download then ask" rather than "ask before downloading" and I was concerned about these users getting regular popup messages saying "you need admin rights" which would reflect badly on the product.

Being blunt it seems a serious limitation having an Auto Update that only works for Administrators - as I said these are the users who need the [b]*least*[/b] help installing the runtime. Are you only targeting home users? Local Admins are pretty rare in most cooperate networks, and those that do are often developers, who might well find having update kick in and interfere with my development settings, web start, build scripts et al. pretty frustrating. Noticed I couldn't debug any of my jsp's in tomcat after installing v5.5.5 - may have been some other gremlin, after uninstalling v5.5.5 and reinstalling 1.4.1 again (over the preexisting copy) it started working again.. Application dependence on known runtime versions (Not Sun's problem I know - but still very common) is going to be a serious issue.

Having Java on the desktop is goint to be great! but if it breaks on every third silent update, all things Java are going to look really bad - and people don't need any more arguements to use against JFC/Swing apps (..it's too slow, it's a memory hog, it's a cpu hog, it's broken my favourite chat/banking/game applet, it's hard to install & configure the proxy / firewall settings.. yadda yadda yadda..). Has anyone floated ideas on how a domain administrator might be able to veto updates for the whole organisation until sufficient internal security & compatibility checks have been completed on the new JVM in question?
On a similar note it might be worth mooting changes to the JNLP spec to allow developers to specify an upper limit on the JRE version their app has been tested on. Currently developers are encouraged to use version strings like "1.3+" or "1.4+ " but this will actively seek out new (and untested) runtimes in the new Auto Update regime. To date this hasn't been much of an issue, as users don't typically tend to update their own runtimes (just accept what they've been given) - but now you guys are changing the rules. For certain developers will need to take more care.

On a different tangent I'd like to ask about whether Java Update is planned to supersede some of the 'other' runtime installation routines; I mean on Windows alone I count at least three different runtime installation routes. There's the normal .exe install we all know about (which Auto Update will supplement), there's the Java Plugin One-Click ActiveX install from browsers and the automatic runtime download/install built into Java Web Start. The 'other' installation routes just haven't been getting full support from Sun (see the regular complaints on the JDC WebStart/Plugin forums), they're neither stable or predictable - It seems a good idea to bring the all the updates under one fully supported umbrella project.. Is this going to be Java Update?

- Richard

stanleyh
Offline
Joined: 2004-02-02
Points: 0

Hi Richard,

I was on vacation last week. ;)

Java Update will be disabled and not running for 'normal' users, because they don't have the security priviledge required to run the installer. Thus, normal users won't keep getting the popup messages even if an update is available.

Java Update is mainly targeted for consumers, and this mechanism will ensure they have the latest runtime on their systems. For developers who don't want their Java runtime being updated regularly, they may turn it off. This is also one of the reasons why the default notification policy is "Before download and install", so developers' machines are not updated without the their agreement. For corporate that want to disable the update altogether, we will also provide a way to do that, so the administrators will be able to fully control their system environment for deployment.

The ceiling version policy for Java Web Start is intesting, and we will investigate it.

Java Update is not for superseding other installation routines, but it is for supplementing others. In future releases, we are looking at combining the overall installation experience in general in all cases, so the installation and the updates will be more predictable and easier to maintain.

osbald
Offline
Joined: 2003-06-13
Points: 0

Thanks for taking the time to reply Stanley (and not rising to my brusque northern manner;)) - That's quite helpful and allays a number of my Auto Update fears. Still a bit of a shame about the admin rights, with any luck the msi elevated privileges thing might provide some answers - couldn't find any Microsoft documentation on how admins can set this up domain-wide. Short of that I could only think of dodgy hacks like running the update process with admin rights (if that's even possible in windows) - I'm now sure you guys have covered all these issues before. It'd be a step forward for us if we could even get the normal runtime .exe to install with such elevated rights for enterprise users. Similar to a domain admin being able to set the Java Update Policy it'd also be useful for them to be able to set the Web Start security sandbox settings (coming in 1.5) and install/remove security certificates on a domain-wide basis. More enterprise / intranet options would defiantly be a nice to have.

[i]Thinking further on this issue has anyone seen a rise in popularity of enterprises using terminal services on Windows XP to offer the traditional Unix like Client/Server dumb terminals? In which case many of the install problems vanish because the runtime only needs installing once for all users (and it's the administrators job).[/i]

The 'ceiling version policy' for Java Web Start is a much better way of putting the original suggestion. I can see developers might want to do two things with this - either choose an older pre-installed jvm suggested by the policy (or initiate download of same) ..otherwise allowing the user to progress with the newer runtime but show a warning that it has not been approved (proceed at your own risk). Hmmm - the first option seems the better of the two on second thoughts.

The idea about being able to use update to supersede some of the other installers was a bit off the wall, you've obviously put a lot of work into the patch system and it makes the pre-exiting 'one-big-lump' installers (and web starts jar-diffs) look pretty rudimentary; excuse the developer in me for thinking about code reuse ;). I've also been looking over some of the JavaOne slides; I take it when you talk about patches you mean _01, _02 ..revisions? what I'm trying to say is whether update is intended to serve known runtime versions every three months or so (guesstimate) or trickle hotfixes on a more regular basis with known milestones 1.4.2_02, 1.5.1 etc.. every so often - just wondering about how the runtime versioning system is likely to continue working.

Thinking of which I'm sure Auto Update is sending the updates in a secure signed manner? This is something I'm sure some of our more Java friendly clients / system admins will ask - whether it presents any security risk (other than possible compatibility issues). I'm sure some would also prefer to serve runtimes from some local intranet location - which might answer the desire to give admins veto rights (above) but more difficult to ensure the security of the updates I'm sure.

Difficult pleasing everybody isn't it..

- Richard

stanleyh
Offline
Joined: 2004-02-02
Points: 0

Here are some links related to how to setup elevated privileges on the system:

http://support.installshield.com/kb/view.asp?articleid=q105140
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/set...

Setting up elevated privilege within the domain may require use of group policy. General users can also trigger the elevated privilege support on 2000/XP if they rename the installer to setup.exe or install.exe. See this link for details:

http://www.installsite.org/pages/en/w2k_oldsetup.htm

The capability of setting up configuration (e.g. security policy, certificates, etc.) for multiple users in webstart is what we call "Central Administration" support, and it will be part of 1.5.

The runtime versioning scheme will continue as it is today, e.g. _01, _02, etc., and it is the patch I talked about. What we will change is the way we package the binaries within _0x releases. Instead of bundling up everything in the installer, we will apply Install-On-Demand and patching scheme to ensure only a small patch will be downloaded to generate the _0x image.

Java Runtime delivered through Java Update will be one of the _0x releases. However, it doesn't mean Java Update will push every _0x release to the end users; as a rule of thumb, only _0x release that contains critical fixes (e.g. security fix, crash fix, etc.) relevant to end users will be pushed through Java Update.

In terms of security, every binary downloaded through Java Update will be subjected to specific integrity check and digital signature checking. This is to avoid security problem demonstrated by other update systems, e.g. DNS spoofing, that download location is used as part of the trust policy which is insecure.

Serving the runtime from a different location, e.g. intranet web server instead of java.sun.com, is a capability that we already have in the system. However, this capability was built for a different intent and will need to be fine-tuned more, so this capability will not be available to the public in the first version of Java Update.

osbald
Offline
Joined: 2003-06-13
Points: 0

Thanks again Stanley! I'll try to get hold of a fresh w2k server to try the group policy method and report back when I next have a free window at work. The second set of instructions on the installshield page looked very like that details in one of the bugreports I'd previously tried with 142beta and v5.5.5 - I couldn't get this to work, would be nice to hear from anybody else whose had more successes with elevated installer privs and hear from anybody with interesting/successful methods for runtime rollouts in general. (Especially in locked-down enterprise situations).

Might be worth creating a Javapedia entry to document some of these installation war stories in the meantime. Anyone looking for more information on deployment issues should check out the new guides in the 1.4.2 documentation :- look for the 'Guide to Features - Java Platform' section under which is a 'Deployment' sub-heading with guides to Java Pugin & Java Web Start (I assume Java Update docs will appear somewhere here in a future release). The Java Plugin guide tells you about the ActiveX one-click install process and the Java Web Start notes on packaging apps into a web archive, versioning and jar-diffs can be particularly useful for enterprise situations.

No big surprises on the auto update versioning front then - I can see how it can be frustrating for all parties concerned when a jvm is released with some silly little feature that could be rectified with a simple hotfix rather than wait for a whole new release; but set versions make my life easier.

There's obviously a lot of stuff been packed into 1.5 ~ everybody (java.blogs) seems preoccupied with the language features like generics & autoboxing, but looking over the javaone slides there's a great many less obvious (but no less important) new features and enhancements to pretty much all of the APIs. I've been wondering whether Sun was likely to market 1.5 as Java 3.0 for a while now, largely because 1.5 is probably the biggest leap (I can remember) since 1.1 to 1.2. But aside from that at the same time Java Update it would appear is trying to make the developers pre-occupation with version numbers irrelevant - once a Java update enabled runtime is active it simply boils down to whether a user has Java installed or not. It certainly suggests I shouldn't have to spend quite so much time worrying about making my code backwards compatible.

- Richard

zander
Offline
Joined: 2003-06-13
Points: 0

I hope sun reads my feedback here :)
It would be wise to FIRST check for OS, and THEN for browser. Eliminates all those bug-reports from annoyed konqueror/etc. fans :)