Chet Haase's Blog

Java on Vista: Yes, it Works

The Rumor

Hey, I like a rumor as much as anybody (Hey, did you hear that Larry Ellison is acquiring Europe?). But when the rumor is clearly wrong and it involves a project that I'm actually working on, I feel obliged to correct the misinformation (as did Java 2D's Dmitri Trembovetski, who has responded to the relevant threads in the next paragraph.  Go Dmitri!).

There was a post on Microsoft Watch, Windows Vista: Aero Glass and Java Don't Mix, last week that claimed that Java does not work on Windows Vista.  OSNews also picked it up. Then Javalobby picked it up on a forum entitled "Running Java on Vista Disabled Aero/Glass UI Effects". Imagine my surprise when I received the Javalobby newsletter with the subject "Java and Vista Not Playing Well Together".

I especially love this quote on Microsoft Watch:

Sun Microsystems would do well to give a ring to one of the interop contacts at Microsoft that came out of the firms' historic make-nice agreement back in 2004, and figure out how to make Java apps first-class Vista citizens.

Thanks for the tip, Jason; I'll pick up that phone right now...

So: Is the rumor true? Did Sun actually forget about Vista ("Whoops!") completely?

The Truth

Nope. The rumor is not true; we actually work great on Vista. (The rumor about Larry, on the other hand...).  In fact, we have been tuned into this release and making Java work on it since it was named after a breed of cattle.  Between regular calls with Microsoft, interaction with their engineers when problems or questions arose, and regular testing and engineering during Vista's development, we have been building a rock-solid release of Java for Vista.

So how did this bizarre rumor originate? Well, older versions of Java do have problems on Vista, and that's what the original report was about; someone tried running some older version of Java on Vista and noted some problems.  But that's like saying that your favorite XBox game, Bloody Mess X, doesn't work on XBox360.  Of course it doesn't; the original game was written for a completely different system.  Why should you expect it to work out of the [x]box on this new platform?  Presumably, given the popularity of Bloody Mess X, the developers are working on a port of the game to the new console ("Even more blood!"), so you will still be able to run your favorite game on this new system.

The port is the key; the new system is different enough in its fundamentals that software for the older system would not just work, but had to be ported.  It would be great if your game just worked.  Just like it would be great if Java just happened to work on Vista with no changes. But it just didn't happen that way; the platforms are different enough that changes are necessary.

It's the same thing here; Vista is not just XP++; there are fundamentally new things about the system that makes older software break. Is all software broken?  Probably not.  But the more of the system an application uses, the more likely it is to run into issues where the system has changed, and need to react to those issues.  In our case, Java is not just a simple win32 GUI application; it is a runtime platform with deep rooted needs in the operating system, the networking stack, the security model, the graphics system, ... if any of these change significantly, then we need to change our software in reaction. And in the case of Vista, it has been an ongoing process of learning, testing, debugging, submitting bugs against Microsoft, fixing our bugs, re-testing, ....  And since Vista has been a moving platform during the Java SE 6 development process, we've been in this development cycle continually with every new drop of Vista (they are still releasing weekly builds for us to test; we just found a bug in RC1 that has since been fixed in the latest release we got yesterday).

But the extra hassles of debugging a moving platform does not mean that we are unaware of the issues and haven't actually been fixing them; Vista has been one of the highest priorities for our Java SE 6 work.  In fact, Java SE 6 has been working quite well on Vista for months.  Some of the more obvious bugs (like Java 2D's disabling the Aero Glass whizzy desktop management system) have been fixed and available in snapshot releases of Java SE 6 for many months. And as we fixed problems in Java SE 6 (our primary platform for Vista support), we have also been backporting the more important fixes to older releases so that we can provide updates to these releases for customers that require the older releases to work on Vista as well.

As pictures are worth between 999 and 1,001 words, here are a few to help you see where we are at.  These are screenshots of Java GUI applications running on the latest versions of Vista (two of the SwingSet2 demo, one of Azureus, and one of Swing-based NetBeans 6):

The Problems We Fixed

Since this is a tech blog (okay, apart from the occasional geeky humor tangents, like this, this, this, and this) and not a whitepaper, I get to dive into a little more detail than I would otherwise.  In a whitepaper, we might say something like "We work well on Vista" and then defer to a PR representative whom you can call to have them say the same thing (with a lot more words).  But I'm thinking that Java developers might actually be interested in some of the technical details that we had to deal with to make our stuff work on Vista.  Those looking for things to occupy their time can chase down the real details in our bug database, of course, but I'll hit some of the highlights here:

Aero Glass

The "Aero Glass" desktop is enabled by the Desktop Window Manager (DWM) of Vista.  This system runs the desktop graphics on top of Direct3D.  All "windows" on the desktop are actually texture maps which are composited together onto the screen.  This system enables various effects that you can see on the screen, including: translucent title bars, application previews in the task bar, and the new Alt-Tab and Cmd-Tab functionality for switching between applications.

Problem 1: DWM disabling

• Symptom: On older releases of Java (1.4.2, 1.5 prior to update 8, SE 6 snapshots before about April of 2006), running a Java application would "punt the DWM", or would effectively disable the Aero Glass effect.  When you launch Java, you will see a change in the desktop appearance, the window borders will turn opaque, you will lose some of the whizzy effects, and you will essentially get more of a XP look & feel for your application windows.
• Problem: Java 2D uses DirectX for creating the Swing back buffer (and other offscreen images) and for copying these images to the screen.  Part of our sanity-check that the DirectX system is functional is to verify whether we can "lock" the screen, which gives us the capability to write or read pixels directly from the screen (we actually no longer use this facility for onscreen pixels; locking the screen to do this ends up causing artifacts with GDI graphics like software cursors and fading menu effects).  Locking the screen is also the easiest way (unfortunately) to flush the current queue of graphics commands (something that is necessary when someone calls Toolkit.sync(), for example). Locking is also a good way to just sanity-check that things are functional with DirectX before we start depending on it.  But locking is also, unfortunately, the quickest way to make the DWM punt on Vista; because of the new composited-desktop approach, applications in DWM no longer have direct access to the screen itself.  If an application demands access (such as through this older DirectDraw interface), Vista will oblige the request, but only by first disabling DWM, and thus disabling Aero Glass.
• Solution:  We found less obvious ways of doing what we needed (sanity-checking DirectDraw as well as flushing the graphics queue) and no longer lock the screen.  This avoids the DWM punt and makes Java run much more seamlessly on Vista.

Problem 2: Graphics artifacts (black rectangles)

• Symptom: Once we had fixed the DWM-punting bug above, we unmasked the problem that Swing windows would sometimes be littered with black boxes or draw the content in the wrong place.  The problems were intermittent and depended somewhat on the particular graphics operations that were taking place (scrolling or moving JInternalFrames around seemed particularly problematic).
• Problem : Desktop Java ends up using both DirectX and GDI to draw content into a Java window.  We use GDI for basic windowing functions such as creating the window and other heavyweight components that Swing uses underneath.  We use DirectX to get some of the more advanced 2D capabilities that Swing benefits from, such as caching the back buffer in video memory for accelerated copies to the screen. This worked fine on Windows pre-Vista ; GDI would draw directly to the screen, Direct X would copy directly to the screen, and life was good.  But in the new composited-desktop world of Vista, this system breaks down.  GDI is now rendered in software into a GDI texture map, DirectX is rendered into a different texture map, and, like small kids crammed together into the back seat on a long car trip, they simply don't play well together. Our use of both rendering systems for the same windows simply causes mayhem in the Vista rendering system and artifacts on the screen. The response we got from Microsoft when we pointed out the issue was akin to "Ohhhhhh - you're doing that?  That'll never work". See Greg Schechter's blog on the topic for more details.
• Solution: The quickest solution was to simply disable our use of DirectX on Vista.  We are basically forced to use one or the other: GDI or DirectX.  We cannot avoid GDI because we need access to basic window system capabilities, so DirectX had to go. There is a more complete solution in the works (for Java SE 7) that will involve a much more complete implementation on top of Direct3D with a more involved and capable buffering system that will allow us to use DirectX in a much more Vista-friendly manner.  But until we have finished that work (how is it going, Dmitri?) we will be using a software-rendering approach on Vista.  The graphics performance geek in me is not overjoyed about the solution; of course I want to see as much hardware acceleration used as possible. All of the time. For everything. But in reality, typical Vista machines (which will be pretty beefy) running typical Swing applications (with basic, static GUIs) will run absolutely fine.  In fact, given our basic level of acceleration so far, many current systems with decent CPUs (not just the high-end ones) run typical Swing applications faster than they would with this level of acceleration; it all depends on the combination of system resources and application requirements.

Swing Native Look & Feel

Vista has a completely new look & feel.  Beyond the Aero Glass effects discussed above, there are simply new themes and new looks to the buttons, the windows, and all of the other normal desktop widgets.  But Vista did not simply tweak the XP look & feel resources; they implemented these new looks through a completely different mechanism.  And they added animation to some of these widgets.  Swing's old approach of using the XP look & feel resources had to be re-thought in the context of this new world.

Problem 1: New native look & feel

• Symptom: A Swing application using the native look & feel on older Java releases actually does look native on Vista; it just happens to look like a native Windows 2000 application.
• Problem: In Windows XP, Swing derived its native look & feel from resources on the system which XP itself used.  So, essentially, we were using the same core resources as XP itself to make our components look native.  However, there were some corner cases in which this did not work on XP.  Even more problematic, Vista uses a completely new system with new resource locations and formats.  So not only did we not look Vista-native on Vista; we didn't even look XP-native (because the XP resources no longer exist).
• Solution: In Java SE 6, the Swing native look & feel for both Windows and GTK was re-written to use the native platform rendering engine to draw Swing widgets.  Instead of our old approach of using the native resources and doing our own rendering, we actually call the native rendering system to draw the widgets for us (on Windows, this is done through the UXTheme API). This means that we are finally able to achieve true native fidelity for these components because, by definition, our components are drawn in the same way that the native components are.  Not only did this fix corner cases for our XP look & feel, we also made our native look & feel work successfully on Vista.  More information about this work can be found on Bino George's and my blogs. The fix has been available in Java SE 6 snapshots since as early as build 14 (for reference, we're now past build 100).  The work has also been backported to J2SE 1.5, and is available in the currently available 1.5 update.  There have been ongoing fixes to other minor issues in native look & feel since then (Vista draws some components in new ways, which we needed to incorporate into our implementation).

Problem 2: Native look & feel animation

• Symptom: Some Vista components animate between different states. For example, moving the mouse over a button will cause a cross fade between the default state and the mouseover state.  Meanwhile, Swing components (like pre-Vista Windows native desktop components) have always simply switched between these states.  So where you might see an animation on a component in a native Vista application, you would see a simple (non-animated) state change in Swing.
• Problem: There was no animation system on older operating systems; components simply changed state and would be drawn in the appropriate way for that new state. In order to handle this change in behavior, we had to implement new logic to change the appearance over time.
• Solution: Igor Kushnirsky implemented Swing animation support in build 97 of Java SE 6 (the latest snapshot release on the download site has these fixes).  There are still some cases not completely handled (for example: progress bars have an animating "sparkle" every second or so that we do not currently render), but things look good in general.  Further fixes are planned for Java SE 6 update releases as well as Java SE 7.

Deployment

One of the more major areas of change in Vista affected the deployment team.  Vista has made some significant changes in its security system, in an attempt to make it more difficult for malicious software to gain control on the machine's resources.  For example, the user is now prompted when an application needs access to a system resource such as the registry; they will get a dialog asking whether they approve this access, and asking them for the Administrator password if they are not logged in as the administrator already.  Internet Explorer 7 (IE7) takes this a step further and protects that entire process from accessing the raw system, so that even if an application inside the browser gains access to the system, it can only perform operations inside the very restricted sandbox that the browser offers.

These changes had wide-reaching implications for our various deployment pieces, including the Installer, Java Update, Java Plug-in, and Java Web Start.  Many of the issues were overlapping, so I'll just cover the general areas of problems that we had to overcome.

Problem 1: Administrative Privileges Required

There were many cases in which we need administrator privileges in order to perform a necessary deployment task.  This includes storing things to registry keys, writing to locations on disk, and executing processes.

• Symptom: Some installer/uninstaller situations would not work correctly, some things that were formerly unknown to the user would now be more visible (for example, Java Update would ask at every login whether you wanted to let it run), and some things would need to ask your permission to write to a location that would not normally be available to a process.
• Problem: Vista tries to lock down system access as much as possible.  Some processes (such as installers) need "elevated privileges" that require user permissions to run.  In some situations, we would run an installer as an exec'd process, which would fail because there was no opportunity to ask the user for appropriate permission.  Similarly, Java Update would need elevated privileges in order to check for an update; since update runs at every login, this would happen whenever the user logged in (which, frankly, gets pretty annoying).
• Solution: We figured out ways to run the installer without resorting to exec'ing processes, so those problems were fixed.  There is no easy answer to the Java Update problem, so we simply reduced the frequency at which Update runs.

Problem 2: IE7 Sandbox

IE7 on Vista is really clamping down on security holes, but restricting access to the filesystem from the browser process and everything associated with it.  This means that Java Plug-in, which runs as an ActiveX control within IE7, is wholly contained within that IE7 sandbox.  This has various implications, from the ability to save into arbitrary locations to the ability to read from and write to the normal deployment installation directory (which Java Plug-in shares with Java Web Start).

• Symptom: Java Plug-in was unable to cache jarfiles and share other data with Java Web Start and the Java Control Panel. 
• Problem : Java Web Start and Java Control Panel run as standalone processes, and therefore have no trouble reading and writing to necessary places on disk (such as the usual deployment directory).  Java Plug-in, however, could not access these directories, and would thus end up writing to a new virtualized location on disk which could not be seen by these other applications.  We could no longer share the information between these very related applications. It was also not clear whether the virtualized directory used by Plug-in would actually be persistent; there was no guarantee that these virtualized locations were permanent.
• Solution: Later releases of Vista provide a persistent directory that all processes can reach.  The directory is within the sandboxed area that the IE7 browser can write to, so the overall filesystem is still protected, but as long as other non-IE7 processes (such as Java Web Start and the Java Control Panel) can reach this location, we have the sharing we need.  We chose this directory to house our deployment directory so that all of our Java deployment components could use and share it effectively.

Problem 2a: Vista and IE7 Sandboxes: The Unfixable

There is an issue worth noting here than cannot be fixed: IE7 on Vista will not let us access the file system outside the IE7 sandbox for applets.  This means that even "signed" applets have no permission to write to arbitrary locations on disk.  This behavior differs from the old behavior of applets on Windows, but given the restrictions of IE7, there is really no way around the problem.  Applications will need to adjust and write to locations that are reachable from their applications.  Note that if an applet simply needs to save information and access it later, this is completely possible; the information will reside in the sandboxed area of the browser.  But if they want to save information in a place that is accessible by other applications, that is trickier since applets cannot save outside of this area and the area may not be obvious to applications outside the browser.

There is another related issue also worth noting: Vista itself has proclaimed various directories off-limits for writing.  For example, it is no longer possible (or at least no longer trivial) to save files to the root directory (C:\) or to other system-level folders; non-administrator users are typically restricted to writing only within their home directories.  This change will affect not only applets, like the IE7 sandbox constraints noted above, but also standalone and Java Web Start applications.  This is obviously not a Java-specific problem, but is one that our users must deal with just like they will have to deal with it in other native applications; files must be saved in Vista-friendly locations.

Problem Summary

That's it for the techy details.  Hopefully you found it interesting; my purpose in detailing this stuff was not to bore or frighten you with the details, but rather to interest you in the relatively huge changes that Vista required from us, and to show why simply running out of the box on Vista was not really feasible for such a large and diverse platform as Java.  But, again, we did the work, we work well, and we encourage you take the time to run Java SE 6 on Vista to see how well it all works together for your applications.

The Plan

Many people reading this might be wondering about things beyond the bugs we fixed, for example: "When can I get a release of Java that works well on Vista?".  Well, here is the plan.

Java SE 6 is the Best Solution for Vista

First of all, you should note that the primary delivery of Java for Vista is Java SE 6; that release has received most of our focus during the Vista beta release timeframe, and it is where most of the fixes to the known problems currently reside.  We are just finishing up that release and it should be done and shipping by sometime next month.*

In the meantime, we encourage you to go to the Java SE 6 download site and get the latest snapshot for testing; the release is pretty close to final, so it is working very well at this point. In particular, all of the serious Vista problems have been fixed in this release for months, so it is a particularly good test vehicle for Java on Vista.

It is also worth mentioning that we are still aggressively pursuing OEM deals. We have distribution agreements with over 20 PC manufacturers, including all the top 10. They have all been helping us test Java SE 6 as they prepare their new lines of Vista-based systems for shipment, so that Java SE 6 will just be there on any of their new systems running Vista.  By the way; if you have a local PC maker who you prefer over the big guys (or if that is your business), let them know they can sign up to bundle Sun's Java Runtime on their systems, just like Dell, HP, Sony, and all the others do just by going to http://java.com/pcoem.

J2SE 1.5 Will Also Work

Many of the Vista fixes have already been, or will soon be, back-ported to J2SE 1.5.  However, don't look for everything to work exactly the same; our primary focus was to make Java SE 6 the main release vehicle for Vista. In an ideal world with infinite engineers working on everything, perhaps we would make sure everything worked the same everywhere.  But here in the Real World, we have to pick our battles, and the battle we picked this time was to make the new release the primary one for Vista.  Besides the effort of simply moving code back and forth between releases, there are architectural differences between some areas of the current and older releases that makes porting efforts more difficult and time-intensive, so we carefully choose what to back-port, based on a cost-benefit tradeoff. 

J2SE 1.5 should work fine, but there may be some nuances that may not be as perfect.  For example, the basic Swing native look & feel work has been back-ported, so that Swing native look & feel applications look like native applications on Vista; however, some additional Vista-specific fixes in this area (such as component animation) may not be back-ported, so the fidelity may not be as close as that in Java SE 6.

Some of the Vista fixes are already in the current release of J2SE 1.5 (as of this writing, update 9 is available on the java.sun.com download site ).  For example, the "Aero Glass" issues described above were addressed way back in update 8.  But the full gamut of Vista work that we feel is necessary for J2SE 1.5 should be available in update 11, which we hope to release around January of 2007.*

J2SE 1.4.2 Will Basically Work...

We plan to also backport necessary fixes to 1.4.2.  However, the same caveat goes for 1.4.2 that I detailed for 1.5, but even more so; we plan to fix only the necessary items to make 1.4.2 work on Vista, not to spend much time improving upon the basics.  A good example is native look & feel.  The rearchitecture of Swing's native look & feel engine involves a lot of code; we do not feel that it is worth the time and risk porting this code to this older platform with Java SE 6 being the primary release vehicle.  We see 1.4.2 as being functional, usable, and perfect for situations where a customer is absolutely locked into that particular release for now.  But we encourage developers and customers to migrate to a more full-feature Vista release soon.

We plan to ship this Vista-enabled update of 1.4.2 sometime following the Vista release of J2SE 1.5. I hope this will be in the first quarter of 2007*, but details are still being nailed down.  Our primary focus now is on finishing Java SE 6 and making it a stellar release, then jumping immediately onto the J2SE 1.5 update to make sure that it has the Vista support it needs.  Then when we are satisfied that these vehicles are robust, we can address Vista on J2SE 1.4.2.

* Don't quote me too exactly on dates.  First of all, I'm an engineer.  You should really talk to a business person that does this kind of stuff for a living if you want official dates and commitments.  These dates are pretty solid based on our schedules and projections, but you're a software person (aren't you?  how'd you get to this blog otherwise?) and understand that software release dates, like flies on your lunch, can move quickly as you get close to them.

Comments

• Schweeet!
  
  Dmitri

  Posted by: trembovetski on October 06, 2006 at 02:42 PM

• Chet, this is a great post and very positive news that we are pleased to hear. Thanks for the detailed info, and let's see what we can do to make sure to help set the record straight.
  
  Rick Ross,
  Javalobby

  Posted by: rickross on October 06, 2006 at 02:53 PM

• Would that be SE 6 snapshots before June of 2006 instead of 2005?

  Posted by: kirillcool on October 06, 2006 at 03:17 PM

• Kirill: I'm not sure where I got "2005", or even "June"; I think I was confusing some memories about when we realized the problem and when we actually fixed it. In tracking down more info on this, it looks like that fix was promoted in March of 2006. I've corrected the article to read "April of 2006"...

  Posted by: chet on October 06, 2006 at 03:27 PM

• Chet - great work and great write-up. Not sure when i'll get around to buy Vista (probably in a year when i'll upgrade my PC), but these changes are really necessary to help Java "fight" against Flex / Flash / Apollo bunch. And having OEMs doesn't hurt a single bit...

  Posted by: kirillcool on October 06, 2006 at 03:31 PM

• Hi Chet, really interesting - thanks for letting us know. So I gather that Java2D's default pipeline won't have any hardware acceleration since direct-X isn't possible. That's OK since like you say software mode is often faster on fast computers, but will Java2D's Direct-3D & OGL pipelines still run 'super-fly' fast?
  I posted about this on JGO too: Vista & HW accel
  Thanks, Keith.

  Posted by: commanderkeith on October 06, 2006 at 11:05 PM

• ...since it was named after a breed of cattle , As pictures are worth between 999 and 1,001 words,...
  Glad to know that the along with serious technical content, humor still finds a place. :-)
  -Bharath (The "Intrepid Reader")

  Posted by: bharathch on October 06, 2006 at 11:56 PM

• Interesting stuff. I'm particularly excited by the Direct3D solution you mention. I know a Direct3D pipeline exists already but it sounds like there's alot more to come (it also sounds like a massive undertaking!). Hope to hear more about this in future.

  Posted by: benloud on October 07, 2006 at 12:46 AM

• Thanks for the update, looks like the MS devs caused the Swing devs quite some pain ;-)

  Posted by: francisdb on October 07, 2006 at 06:04 AM

• So you mean the native Vista look and feel will be...native.
  I know this is not Javalobby, but does this mean the Swing/SWT war is over, Swing being able to do both native and "not native" ?

  Posted by: nopjn on October 07, 2006 at 07:23 AM

• keith: D3D and OGL will still be available via command-line flags, just as they are on XP, it's just that D3D (and DX) aren't enabled by default.

  francisdb: It's worth noting that the MS devs were actually quite helpful to us. The architectural differences in Vista, on the other hand...

  nopjn: Swing and SWT still have different approaches to rendering. We now use the native rendering engine to draw Swing components, but that's different from SWT's approach of actually using the native components. These different approaches should create components that look the same to the user, but one is a lightweight (and image that Swing copies to the window) and one is a heavyweight (a component that SWT creates using the native component). I certainly hope that our truer native look means that the debates will end, but architectural differences still exist....

  Posted by: chet on October 07, 2006 at 08:25 AM

• I hope they will end it.
  Those architectural differences are Swing's strength :)
  I can't remember if I ever said to someone "no, that's not possible in Swing", but I do remember saying "asks your graphic designers to draw what you want, and I'll do it pixel per pixel".
  
  Keep on the excellent work.

  Posted by: nopjn on October 07, 2006 at 11:20 AM

• Chet - and not even that, since the animations are emulated in Swing (and some of them are not yet there). Do you have the complete enumation of the feel (accelerators, mnemonics, ...)

  Posted by: kirillcool on October 07, 2006 at 11:34 AM

• enumation -> emulation

  Posted by: kirillcool on October 07, 2006 at 11:43 AM

• Folks on the Apache Ant 1.7.0 Beta haven't taken a liking to Vista. Take a read of the Ant 1.7.0 Beta documentation:

  There are reports of problems with Windows Vista security bringing up dialog boxes asking if the user wants to run an untrusted executable during an ant run, such as when the task runs the jarsigner.exe program. This is beyond Ant's control, and stems from the OS trying to provide some illusion of security by being reluctant to run unsigned native executables. The latest Java versions appear to resolve this problem by having signed binaries.

  Posted by: phlogistic on October 08, 2006 at 08:41 AM

• Interesting - so the Swing project has accepted that SWT's native rendering implementation is a better solution versus writing thousands of lines of Java code trying to emulate the native OS windowing. Wonder if that had to do with the open-minded thinking of Schwartz? If so Sun's looking like a good investment.

  Posted by: phlogistic on October 08, 2006 at 08:51 AM

• phlogistic: I think you're missing the point. Swing is no more SWT like than before, they are still totally different approaches. It's just that Swing now uses the OS to paint things like button backgrounds and scrollbar thumbs etc. But its only the painting. But the components themselves and the logic behind them are still written in Java. Whereas SWT literally creates instances of the platforms components. The Win L&F looks absolutely fantastic (thanks Josh!)

  Posted by: benloud on October 08, 2006 at 09:46 AM

• A challenge: show us Aerith running on Vista ;)

  Posted by: benloud on October 08, 2006 at 10:08 AM

• Great stuff Chet, super informative post!!! For the animation stuff, did you guys use any of the code in your animation framework or is it a totally different codebase? (well I guess I culd just download the code and check, just being lazy :-) Also for the little sparkle progress bar anim, is there a bug report for it so we can track it's progress? Did a quick search but found nothing on it.

  Posted by: augusto on October 09, 2006 at 08:15 AM

• The main animations should be enough. I don't see the need to have all the tiny little animations implemented. All we need is a global feeling of responsiveness.
  Look at Internet Explorer on XP and tell me if the scroll bar reacts to the mouse like it does in the file explorer.

  Posted by: nopjn on October 09, 2006 at 11:37 AM

• Is there a video of the Vista/Aero progress bar animation online anywhere? I'm just curious what exactly we're up against.

  Posted by: afishionado on October 09, 2006 at 02:14 PM

• -

  .

  .

  .

  .

  Are we ever going to have cool Transparent Windows Feature in Java ?

  .

  .

  .

  -

  Posted by: kishoresjava on October 10, 2006 at 11:53 AM

• Regarding "Vista and IE7 Sandboxes: The Unfixable". My experiments show that there is a workaround. If: - the applet site is in the trusted sites zone AND - this zone has the protected mode off (default) AND - we remove the https only restriction the (signed) applet will have read/write access outside the virtual area. Am I wrong? Do I miss something? Did Microsoft change this recently?

  Posted by: baftos on October 10, 2006 at 01:19 PM

• Chet - great, great post. This is a good page to show people all the great and extensive work the Swing team does! And all the really cool internals that go into it. BTW, I've installed Vista and I can't stand it. Everything few minutes the whole screen goes into warp mode and I have to give the system permission to do the simplest thing. I guess that's necessary (for those who need virus software anyway), but people will backlash. Maybe MS can adopt the Java security model! Having a cross-vendor effort to build trusted applications (like WebStart/java Plugin) would be helpful. Anyway, if it sounds like Java will be lame because of all these popups, it's because Vista is lame, not Java.

  Posted by: michaelbushe on October 10, 2006 at 06:30 PM

• So, I've downloaded the latest Java build (whatever was on the dev site as of today) and the latest Vista download available and gave the new swingy-ness a tour.. It kicked me out of Aero at every turn. I was unable to replicate the screenshots you have posted here. I want to make Vista RC2 my primary OS for a bit to just try out the feature set, but the constant window manager changing when I launch and quit my java apps is making me queasy.. In this case, it's Java that wins though, I'll hold off on Vista until Java works on it, but pretty please with sugar on top, soon :-)

  Posted by: amalter on October 11, 2006 at 03:39 PM

• amalter: We haven't seen this problem in our development or testing so far. Can you post (or email) some info regarding Vista build #, java -version output, and some system specifics? Also, did you install Vista from scratch, or do an upgrade? Thanks - Chet.

  Posted by: chet on October 11, 2006 at 05:29 PM

• amalter: I just checked java.com, and the current version offered there appears to be J2SE 5.0 update 6 ... which still exhibits the Aero-punting you describe. This problem was fixed in update 8. Fortunately, java.sun.com offers a more up-to-date version you can grab in the meantime: http://java.sun.com/javase/downloads/index.jsp (look for the update 9 JRE or JDK). Or, you can grab a snapshot of the latest Java SE 6 JDK here: http://download.java.net/jdk6/binaries/. Note that the best Vista releases will be the Java SE 6 release in its final/official release (when it's done, Real Soon Now), or update 11 of J2SE 5.0, as detailed in the blog above...

  Posted by: chet on October 11, 2006 at 07:10 PM

• For future refernce, What auto download page should I use in my JNLP when porting Java Web Start Applications to Vista?

  Posted by: skalvi on October 22, 2006 at 04:16 PM

• selfless: hey Chet, was just planning to test run the java desktop and web applications that have developed on vista which have planned to install this weekend. this information would be very useful in efficiently testing the java applications on vista

  Posted by: selfless on October 24, 2006 at 02:28 AM

• Hi - thanks for that informative summary. One thing that we have not gotten to work on Vista is automatic plugin installation. I just tested the Java experience of our website as a customer who does not have Java installed would experience it - terrible. If we use APPLET tags on IE, we at least get to show a link to java.com. However, we used to use an OBJECT tag which would auto-install the plug-in. The problem ist that there is no auto-download for 1.6! See here: http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/autodl-files.html No mention of Java 6 anywhere. So if we use our old OBJECT tag, it will install Java 1.5 on our customer's VISTA machines. We have already tested that, and unsurprisingly, this results in non-working applets, us having to tell them to uninstall, etc. A mess. Now we reverted back to APPLET tags. Firefox on Vista will also auto-install Java 1.5, basically resulting in a broken Java experience. Firefox does not even display the alternate link in the APPLET tag - instead it's too smart for its own good and pretty much automatically installs 1.5 for the user. I will report this problem with Firefox and the java bug parade. Summary: Java on Vista: Yes, it works. BUT...

  Posted by: nheger on January 05, 2007 at 09:17 PM

• How can we find out the details about how to specify this persistent directory? A lot of programs are going to be broken as of 30 January and it is important to get out the details of the workaround.

  Posted by: segalsegal on January 26, 2007 at 08:14 AM

• I've fiddled with signed applets on Vista and can provide some details about a workaround for file writing.

  If an applet tries to write a file to an arbitrary location, Internet Explorer 7 considers this an error. From Netscape, the file writing is allowed, but a file that was directed to be written at c:\foldername is re-routed instead to C:\Users\theirUserName\AppData\Local\VirtualStore\foldername.

  A workaround is to choose the location c:\Users\theirUserName\AppData\LocalLow\foldername instead. From both Netscape and IE7, file writing is allowed here and no re-routing to a virtual folder is done. The Java System property user.home gives you the needed information about the relevant drive and user name.

  For those who want the ability to write files more generally, apparently Sun could make this happen through modifications on its end, as detailed at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6504236. Another solution is Java Web Start, but the LocalLow procedure outlined above may be the form most likely to be allowed on many networks.

  Posted by: segalsegal on February 05, 2007 at 12:18 PM

• Auto Download of Java 6 is available.

  The naming of the autodl-files are a little different for Java 6 than they were for Java 5.0.

  http://java.sun.com/update/1.5.0/jinstall-1_5_0_03-windows-i586.cab

  http://java.sun.com/update/1.6.0/jinstall-6-windows-i586.cab

  Posted by: ngthomas on February 15, 2007 at 05:22 PM

• Since this was the starting point for my solution to the problem of Java not working properly with Firefox 2 using Vista, I thought I'd post the solution I found. I just got a new box from Dell and it came preinstalled with Vista Home Premium. My problem started when I tried to use Firefox to download off of Sourceforge an app I commonly use, and then later when I tried to use the Java-based live draft app to draft my fantasy baseball team on Yahoo Sports. Both of these efforts failed. As soon as Java began to load on Firefox it would lock it up. Oddly enough I was having no trouble using the same version of Firefox (2.0.0.2) on several XP machines. I went back to Vista and tried to accomplish the same tasks using IE7. Everything worked. So I started searching for a solution - which lead me to Mr. Hasse's blog here - and then lead me to the following site: http://kb.mozillazine.org/Firefox_:_FAQs_:_Install_Java which led me to another site: http://www.java.com/en/download/windows_manual2.jsp This is where the solution was found. When I clicked on the "Verify Installation" button, it returned an OEM version of the JRE. I had already installed the JDK 6, so I had assumed that it would overwrite any current JRE with the JRE that comes with the JDK. I may be mistaken there - it may be the case that the JDK install doesn't include the latest JRE - but I always thought it did. Regardless it hadn't touch the preinstalled JRE, so I went back to the Manual Install page and manually installed the latest JRE. When this was finished I checked the version again. This time it returned 1.6.0 without the OEM tag appended on the end of it. I went back to Firefox, and verified that I could download the app from Sourceforge and that I could use the live draft app on Yahoo Sports. Both worked fine this time. Now normally, I'm not a conspiracy nut, but it seems odd to me that the installed OEM JRE worked fine with IE7, but not with Firefox. It seems to me that Microsoft just might be doing things that cause Firefox headaches, realizing that most people aren't going to do what I just did so that Firefox and Java play nicely together, but instead will assume that Firefox is flawed in some way, and just use IE7 in the future. Regardless, if you were having the same troubles I was having with Firefox locking up when it tried to use Java, try manually installing the JRE. I imagine it will fix the problem.

  Posted by: lkh07 on February 24, 2007 at 06:09 PM

• x64 Java6 on Vista.. has become a linux experience.. no environment variables are set.. no control panel icons are available.. useless for the average user.. what good is Vista x64 to me if i can't run my favorite apps ? :(

  Posted by: brunis on March 07, 2007 at 02:36 AM

• Is there some way from Java that I can find out whether the applet is running in IE7's protected mode? At the very least, I'd like to warn the user and/or disable certain features of the applet.

  Posted by: riordanmr on March 14, 2007 at 08:22 AM

• Hi All, Despite the fact that quite a few of you seem to agree that Java works on Vista, I still can't explain why applets always crash on IE7 running on Vista business.

  Posted by: massimo71 on April 16, 2007 at 03:06 AM

• massimo71: Can you provide any more information on what exactly is crashing? What release of Java are you running? Hopefully it's SE 6; as the blog entry tries to make clear, SE 6 is the best Vista platform currently. Also, any concrete examples of applets that crash (URLs) would be helpful.

  Chet.

  Posted by: chet on April 16, 2007 at 10:50 AM

• Hi Chet, I've got the latest JSE 6.1. I've tried to run quite a few applets through IE7. Any selection from a site like http://javaboutique.internet.com/ always shows the same behavior: the applet will appear and try to load but the progress bar will stop almost immediately; at the same time the status bar on IE7 will say that the applet has loaded successfully. Sometimes IE7 stops responding. It freezes and you have to kill the process through Task Manager. I'm running Vista Business, and I'm connecting to the Internet via a DG348G router. Browsing the web is not an issue (I thought there might be issues with firewall settings). This behavior sort of mirrors Firefox's. FF starts loading a page but stops halfway, and never completes the task. Any idea is much appreciated. Thanks for your time Max

  Posted by: massimo71 on April 16, 2007 at 01:49 PM

• Max: I'm not seeing it. I just installed 6 update 1 and ran some sample applets on that site in IE7 and didn't see a problem. I tried Aero on and off to make sure there was nothing funky with the glass theme, but it didn't make a difference. I'm running Vista Ultimate. I don't know how much that varies from Vista Business, but I would think they would be substantially similar in the areas that count here. Sounds like this is a problem for you with any applet, but if you could tell me a particular applet you've failed with, it would help. For example, I was able to run this one: http://javaboutique.internet.com/CrossFader/. Does it work for you?

  Chet.

  Posted by: chet on April 16, 2007 at 02:13 PM

• Chet: The applet you mentioned doesn't work. This problem doesn't seem to be related to any particular applet. But when I tried to 'validate' the installation of the JRE on the Sun website, the JRE was recognized. I believe that uses an applet too. Do you think it might be something to do with read/write permission on a specific directory that Vista doesn't allow? I've noticed that every time I start the OS the C:\UserName directory has only Read permission.
  
  Thanks

  Posted by: massimo71 on April 16, 2007 at 03:15 PM

• Chet: Someone in a forum suggested I look at disabling TCP autotuning. Any thought on that?
  Thanks

  Posted by: massimo71 on April 16, 2007 at 03:48 PM

• Update: Problem fixed. Sort of. The culprit turned out to be my router - a Netgear DG348G. Even with the latest firmware upgrade apparently it doesn't like the TCP autotuning that Vista comes with. Easy enough, what I had to do was disable the autotuning. Have a look at this blog for the full story.
  
  Incidentally that also fixed the other problem I had with Firefox 2. However - interestingly - none of this bothered IE7. Hmmm...
  
  Anyways, all java applets now seem to load fine.
  
  Max

  Posted by: massimo71 on April 17, 2007 at 02:01 PM

• I installed Sun Java Version 6 Update 1 on my Windows Vista Home Premium computer for about the 3rd time. Whenever I attempt to view an applet stationery in Windows Mail. The Windows Mail program is shut down. In order to get Windows Mail to work again, I have to quick delete that particular stationery. If I uninstall the Java program, I can't view that program saying I need to install Java, but it dowsn't shut down the entire program. It is a no-win situation, but I'm going to unstall the Sun Java program again. I just don't believe it's capable of working with all aspects of Vista. jazup

  Posted by: jazup on June 09, 2007 at 04:51 AM

• jazup: I haven't seen this problem. I'm not familiar with 'applet stationery in Windows Mail' so I should check that out. In the meantime, I assume you are installing some flavor of SE 6, right? If you can specify the verion you've tried to install, it would help track down the problem.

  Chet.

  Posted by: chet on June 09, 2007 at 07:29 AM

• I installed Sun Java Version 6 Update 1 as recommended on the Sun Microsystems site as the correct version which would be compatible with Windows Vista. I don't know what you mean by "some flavor of SE 6". I am running Vista version 6.0.6000 Build 6000, which was pre-installed on my HP Pavillion computer, if that's what you mean. I don't know anything about an "SE 6" program. Would like you to know that I went to the following site and in my IE7 browser the javascript worked fine, but when I sent the page as an email to myself, it locked me out of Windows Mail again. http://javaboutique.internet.com/CrossFader/ Now, I just had it completely mess up my Windows Mail as I can't delete a stationery that was sent using a javascript. As soon as I post this, I'm deleting the Sun Java from my computer, rather than just disabling it. It's nice for web sites, but my main work is with stationery emails. I used to use Microsoft's version of Java with Windows XP and all worked fine, but now Microsoft can't offer it anymore -- and Sun Java certainly isn't working for this.

  Posted by: jazup on June 09, 2007 at 01:42 PM

• jazup: Thanks, that's the release info I was looking for. By "some flavor of SE 6," I simply meant any version of Java SE 6 (such as the Update 1 version that you installed). I know that we've done considerable testing with standalone and browser-based Java applications on Vista, but I'm not sure about Windows Mail stationery. I'm not familiar with that mechanism of running applets, so I don't know off-hand how it would work (or what mechanisms it depends on that would cause problems). But hopefully we can reproduce the problem now from the information you've given.

  Thanks, Chet.

  Posted by: chet on June 11, 2007 at 07:11 AM

• Thanks for your reply, Chet. I wish I could send you the "source" file for one of them, but I've had to delete the stationery in order to get back into Windows Mail. I've deleted the Sun Java for now, so perhaps when the next one comes through (I don't get very many), I'll be able to get the source file so you can test it. Better yet, I'll ask the group I'm in if someone who creates them would just send me their source txt file, and then I can post it here for you if you think that would help.

  Posted by: jazup on June 11, 2007 at 08:25 AM

• Chet: With help from some in my stationery group, I've found the following to be happening. Using the same javascript applet, it opens just fine in IE7 when in .html format. If in .eml format, it shuts down Windows Mail. Vista gives the following reason. Data Execution Prevention (DEP) has closed Windows Mail to protect my computer. What I would need is a DEP compatible version of Sun Java. So, am wondering if Sun Microsystems is planning to create a DEP compatible version?

  Posted by: jazup on June 11, 2007 at 12:30 PM

• Really gald to hear that java works on vista. Was reluctant to shift to vista from xp after one of my friends informed me about the problems that java faced on the new vista. It sounds more reassuring now. Cheers.

  Posted by: outsource_to_india on June 13, 2007 at 04:25 AM

• jazup: Thanks for the extra info: apparently the DEP issue had already turned up as a known bug; it's on the radar to get fixed.

  Posted by: chet on June 13, 2007 at 06:37 AM

• Just downloaded the update for Vista (version 6 Java Update 2) I was hoping the DEP issue had been fixed. It has NOT, so Java still is not completely compatible with Vista operating systems.

  Posted by: jazup on July 27, 2007 at 02:42 AM

• So what you are saying is Java 6 works with Vista but not Internet Explorer 7?

  Posted by: devoleno on July 27, 2007 at 01:25 PM

• Chet hi, supporting webct 6.1 (Blackbored) - we have to tell our users not to go higher than java 1.5.7 - are you saying in the section j2se will also work - that that version (& all 1.5x versions) have got basic (?) vista capability backported to them. that would be good news for us if vista works reasonably well on 157 - on our test machines vista seems to be going ok on 1.5.7 but we are reading that it's a problem thanks danny carroll

  Posted by: dcarroll07 on September 16, 2007 at 10:20 PM

• So here's an interesting problem, related to - if not directly caused by - Java on Vista. Brand new machine (Lenovo T61p T7700, 4GB, NVidia Quadro FX 570M driving 1680x1050 LCD, Vista Ultimate 32-bit from Microsoft GM DVD - not the Lenovo pre-install), with Java 1.6.0_03. When docked (but not when not docked), I run it in a dual-monitor configuration (add on a 1600x1200 external display via DVI). Two or three times a day, the machine simply "turns off" when I am switching to or from the Java application (Interactive Brokers trade station started via .jnlp download through Firefox). If I don't have the IB Java app running, the machine works flawlessly. If I run the IB Java app "undocked" (ie, just the 1680x1050 LCD driven), no problem. Seems like an odd interaction between the display driver and Java. I'm running the NVidia 7.15.11.5685 drivers dated 12/10/07. Again, it's not a BSOD. The machine simply and instantaneously powers off. Java itself, I hope, cannot do that, but the display driver might be able to cause such a serious fault. Any thoughts?

  Posted by: rrelph on January 02, 2008 at 12:38 PM

• rrelph: that is rather weird. Especially since 1.6.0_03 doesn't even use DirectX on Vista, so I could not imagine how whatever we do would cause this behavior. Not even sure where to start. Does this happen only with this particular application (trade station), or with any Java app? Could you try installing the latest build of 6uN (available here: http://jdk6.dev.java.net)? (and we might want to move the discussion to the Java2D forum: http://forums.java.net/jive/forum.jspa?forumID=69&start=0) Thanks, Dmitri Java2D Team

  Posted by: trembovetski on January 04, 2008 at 10:52 AM

• Dmitri, I haven't tried it with any other Java apps. I don't have any other apps I would routinely run, so do you have any suggestions for an app you'd like me to use? I'll try the latest build. I've reposted my question on the forum you pointed me to. Thank you very much.

  Posted by: rrelph on January 04, 2008 at 11:17 AM

• Chet -- I've become very impatient about Sun making Java compliant with MSIE7's DEP on Vista. I have to wonder what kind of "radar" Sun has used to scope this problem and schedule a fix. I've been waiting for relief since May 2007. Please advise. -- al

  Posted by: alerter on January 31, 2008 at 04:24 PM

• I remember that we've fixed a DEP related bug 6563344 in 6u4. 6u4 can be downloaded from the following website: http://java.sun.com/javase/downloads/index.jsp

  Posted by: ccheung on January 31, 2008 at 07:47 PM

• I have a new gateway top of the line computer and java wont run on the administrator name which is me if i go to guest somethings will run not everyting. I need java for my business on my computer and this is really getting on my nerves. I have deleted reinstalled java many times and everytime i use something that needs java it says java not installed then i reinstall and it says java not installed dont have no idea what to do now it like something is blocking it from coming on it flashes then nothing i have no firewalls on no pop up blockers on at all my certificates are installed i need for the program i need to run so i dont want to here nothing is wrong with vista and java there is something majorly wrong with this

  Posted by: foxylady6800 on February 25, 2008 at 08:28 AM

• I am running Java SE 6 Update 5 (build 1.6.0_05-b13) and Windows Vista Home Basic on a laptop, and I still get punted out of Aero Glass when launching a Java application. Not sure if it is the application that is punting Aero Glass or Java, but either way you get punted.

  Posted by: wistex on April 07, 2008 at 08:35 PM

• Hi All, I am a software engineer and I am moving over to Vista from XP. I do a lot of P2P development, using Java (I use JXTA) - what is the best version of Vista to use for software development that gives me maximum flexibility. I currently have Vista licences for Home Premium and Business. Kind Regards, Paul

  Posted by: tocaloshi on April 18, 2008 at 03:41 AM

This work is licensed under a Creative Commons License.