Chet Haase's Blog

Mmmmmm VM.....

Before we start, please check out Grzegorz Czajkowski's blog. Greg talks a bit about the technology and has links to related sites (including, of course, the project page for MVM. Note, however that you will need the JDK Researcher role in order to view the project). I'll wait here; you go ahead and check it out now.

All done? You read the blog, saw the project, formed some opinions? All right, then; let's go!

It seems like MVM is one of the hair-triggers for Java developers. Whenever I hear it mentioned, the comments are along the lines of "We need MVM!", or "Why isn't it in the platform yet?", or "It'll be in the next release for sure." Whenever we query developers about what they'd like to see, the answer is usually "MVM!" How do we improve startup performance? "MVM!" How do we improve application footprint? "MVM!" What do you think of the new graphics acceleration features? "MVM!" There are forums devoted the subject, rants on popular developer sites, and generally entertaining and highly-charged discussions with lots of exclamation points and death threats.

So given all of the excitement around MVM, why isn't it in the platform yet? Why aren't we planning on putting it there, at least in Mustang? What are we thinking? I mean, obviously everyone wants it, so why don't we listen to our community and just put it there?

First of all, let's take a little step back and think about what MVM is. In particular, I'll focus on the aspects about MVM that caught everyone's attention (including mine) initially; startup and footprint benefits. As Greg says in his blog, there's a lot more exciting stuff in there, especially the Application Isolation API. But I wanted to specifically address the performance aspects of MVM and what they mean (and don't mean) to typical desktop applications.

Basically, MVM provides a way to launch separate Java applications in the same virtual machine. Currently, separate Java applications all run in their own process, completely independent of one another. There is some very simple sharing happening under the hood in terms of shared libraries (specifically, the DLL's on Windows, the .so's on Unix, and some of the Java classfile data on all platforms). But other that this basic OS-level sharing, all of the processes are completely independent.

This process independence means that every new Java instance fires up its own copy of the executable, loads in its own classes, creates its own heap, and suffers its own startup performance hit (whatever it is). There is significant startup benefit from being the second Java application in general, but this is due to the disk caching happening at the operating system level, not due to any sharing between our Java processes.

Two things that bug some desktop Java users (and, by the transitive property of software usage, the developers of Java applications) have complained about over the years are the time that applications take to startup, and the RAM footprint that these applications consume on the machine. Startup time has actually gotten much better over time, through a combination of Class Data Sharing (implemented in Tiger, a nifty way of preloading all of the core classes that desktop apps usually need), various performance tweaks, and the inevitable speedup of processors, disks, and operating systems. Footprint continues to be an issue, although with standard PC memory configurations, this is less of an issue now just because the footprint occupies a lesser proportion of a machine's RAM when that machine comes with so much to begin with. But both are important issues that we should (and do) continue to work on.

Along comes MVM, which has this nifty property of sharing process overhead. In particular:

• Startup: Each new Java application has a nearly free startup of the core VM and classes that are already loaded. Obviously, an application would still take time to load in their own classes, but the stuff that was already loaded by other MVM apps would come for free.
• Footprint: Each new Java application takes up only the additional footprint for extra heap it requires and extra classes it loads; the footprint required for core classes shared with other Java applications is once again free.

Free? Did you say Free? Where can I get some? We need this! Why isn't it in the platform yet? It'll be in the next release for sure. Right?

Okay, let me don my loud plaid suit and play the part of a used car salesman: "Well, it's really almost completely free ... but not quite." Here are the gotchas about this approach that are important to keep in mind before getting too swayed by the "Free" argument above:

• Someone's gotta take the hit: Obviously, MVM cannot magically make the startup and footprint issues go away completely; that stuff still has to be loaded from disk and stored in memory. So somewhere there will be a startup hit loading the data and a RAM footprint to hold the heap and class data. In particular, this hit will be taken by the first application to load into MVM (or perhaps some parent process that simply loads up MVM to begin with). It is the following Java applications (from the second one on) that get the benefit of the sharing.
• All for One and One for All: If all of these Java applications are running within the same process, this means that any one of them can kill all of them. I believe that MVM protects around simple things like calls to System.exit() and other Bad Things happening at the Java level. But what if some native code does something awful and crashes? Or worse, what if some native code calls into some driver or other operating system dependency and _that_ crashes? Then that crash will also take down the whole lot of them.

So these are what my reservations for Desktop apps using MVM really boil down to: the benefit is only there for situations where multiple Java applications are running simultaneously, and there is significant risk that one application can take down the lot of them.

The risk of crashing all apps running within MVM is so important that I would feel queasy about sticking in this kind of capability by default in the platform. I cannot be sure that all applications that your users will run will be robust enough (from the application down through the platform level down through the drivers and into the hardware) that I'm will to bet all of your users' other applications upon that.

And given that the MVM benefits of startup and footprint are visible only for situations in which multiple Java applications are running, it seems like the only interesting environment in which to run MVM is one in which multiple Java applications are running.

Let's put these things together: we don't want to run MVM by default due to the kill-them-all risk, and we only want to run MVM in situations in which there are multiple Java applications at work. It sounds to me like we've just entered a new category of Java applications which does not yet exist: "application suites".

Application Suites

The ideal situation I envision for MVM is one in which applications run in suites, or in some other way where they could elect to have themselves added to a particular MVM process. For example, someone might ship a desktop utilities suite, and other developers could add in other applications that want to run in that process. Or someone could supply a suite of related applications (CAD, office, linked enterprise apps) that are happy to live (and maybe die) together. Or there could be a "Game" suite that you could elect to run your game in (crashing all games running is less serious than crashing all air traffic control applications, for example). Or there could be something I'm not yet seeing, because it doesn't yet exist.

So? Why isn't it there yet?

So now, finally, I get down to the question of "Why isn't it in the platform yet?", or more specifically, why isn't MVM going to be included in Mustang? Well, frankly, it's always a question of tradeoffs, just like any software project.

Would we include it if we could? Sure! Given the caveats above (that it's not enabled by default, that there are mechanisms for running related applications in separate MVM processes, etc.), then I don't see a good technical reason why we couldn't ship it. But, given the niche category that I've backed this technology into with the reasoning above, is it a critical feature that we should focus on in preference to some other Mustang feature? Given that we have a finite number of developers, that there are lots of interesting features and fixes we are working on (that people are also screaming for), and that not everything can make it onto the Mustang plate, I believe we made the correct call here that MVM, seen in the light of my logic above, was simply not as important as other features that we elected to work on instead. Would you rather we spent our efforts on technologies that benefit all, or even most, of Java developers? Or on a feature like MVM which might be completely awesome for the folks that need it, but which (given the constraints I laid out above) are probably few in number today?

What do you think?

What would you do? Am I missing something here? Is there a vibrant community of "application suite" developers that's just waiting to happen? Or are there a preponderance of applications that would be willing to work within these constraints today? Join in a discussion above, or go to Greg's blog and hop onto discussions there. We're looking for feedback on this; we'd like to take the MVM discussion of the "We need it!" stage and into the "We understand the constraints, here's how we would like to use MVM."

Comments

• IMHO, I don't think your view that MVM is best suited for so called "Application Suite" is a valid one. I have 4 Java applications running on my computer right now and they sure aren't in a "suite", and all of them can benefit if we have MVM. I think the people (me included) who have been asking for MVM for the long time are the ones who are true practitioner of Desktop Java. We try to run Java-based applications if we have a choice. Desktop Java can not be realized if there aren't any real substance behind Sun's claim, and substance is a lot more than just tweaking Swing or providing little impovements in Java WebStart. Sure, we know the risk involved putting everything in a single process and MVM should protect us as long as it's not an error originating from JNI, right? Give us a choice, do not choose for us.

  Posted by: walterc on June 14, 2005 at 08:27 PM

• Regarding crashes from native code:
  Is that so hard to prevent? My C-days are long gone, but Isn't there some kind of exception/signal handling on every platform?

  Have a look at JNIWrapper, they manage to isolate Java against crashes: "Crashes in native functions are converted to Java exceptions"
  http://www.jniwrapper.com/features.jsp

  Posted by: skelvin on June 15, 2005 at 12:13 AM

• For client application, MVM must be on the top priority!
  About the crash problem, if only one process crashes, that is also problem.
  I hope to change all my applications into Java, but other fellows in my company always talk about the start up time and memory footprint problem.
  I can implement other stuffs lack in the current JDK(Actually users don't care about the details), but I can't implement MVM like thing.
  

  Posted by: tsjung75 on June 15, 2005 at 12:42 AM

• I can think of two use cases for Java applications (as a developer): large footprint developer tools (I've run simultaneously Tomcat, HSQLDB, DbVisualizer, IntelliJ IDEA, and a large Swing application, but you can easily swap in other IDEs or appservers), and small "gadget" programs (like instant messaging and multimedia stuff).

  Maybe the reason there's not more of these types of application is that it's difficult to convince users to run many of them due to the memory footprint. Java's great for creating desktop applications (cross-platform, excellent effects using Java2D, ...), so a low memory footprint and fast perceived startup time could really kickstart the market. Then, Java software can aim for bigger applications.

  Concerning the "stability" aspect, maybe developers could use a command-line switch when starting up their Java program (or, even better, a Jar MANIFEST.MF attribute) to nominate a program category, say "multimedia", "office", "developer") to identify WHICH MVM instance they wish to connect to, as a means of spreading risk in the event of a crash (although the comments about JNIWrapper being able to work around the problem are even more encouraging).

  In the event of a real crash, maybe some sort of GUI or text prompt could be offered, indicating to the user "this application crashed" (identifying the MVM process) and "would you like to run this application separately in the future?", as a way of automatically offering to isolate unstable applications, whilst optimistically assuming that (unless otherwise specified) they can co-exist in the first place?

  Posted by: chris_e_brown on June 15, 2005 at 01:06 AM

• I've wanted to make some small utilities for years now. One reason were the SWING features, but the most discouraging thing was the thought of 5 utilities with 200 lines of code each, eating up a bunch of RAM, and slowing startup drasticaly.

  Posted by: hrgdavor on June 15, 2005 at 03:33 AM

• >I've wanted to make some small utilities for years now.
  If you want to run small, well behaved utilities with no startup in the mean time, NailGun can do that.

  Posted by: pete_kirkham on June 15, 2005 at 05:50 AM

• I think that w'out having MVM, v can do same thing in any JVM.
  I had implemented this.Y should i give it to any1?I think many may developed this thing but thy think like me

  Posted by: hithacker on June 15, 2005 at 07:03 AM

• Chet, you understate the value of a shared JVM. Two current Java areas that you overlooked are applets and Ant. Startup time and total resources used are still very important issues there. See NailGun for more examples.

  It would also be possible to do more than MVM does now. A snapshot of the JVM for each specific program could be taken just prior to the first external interaction. Profiling and optimization could happen across multiple runs of a program. I can see why you guys shy away from this stuff, because it seems to imply embedding a database within Java. Making a database small, fast, and reliable is tough. The last thing the average Java user wants to do is deal with some internal database error. Still, if done well enough, the performance wins would be enough to outweigh the added complexity. Sun has managed to use complicated techniques to increase performance without sacrificing reliability in the past.

  With all that said, MVM is an implementation detail. The platform APIs such as JSR-121 are more important.
  

  Posted by: coxcu on June 15, 2005 at 07:47 AM

• Chet,
  maybe I misunderstood your post, but the problems about multiple applications in the same MVM seem to have been solved, at least if the
  MVM is the same that was the basis of this paper:
  http://research.sun.com/projects/barcelona/papers/usenix03.pdf

  JNI calls are made in seperate address spaces, so if they create trouble, they dont mess up the app.
  Calling System.exit() is what Isolates (and the implementation that shoudl work inside the MVM to seperate the apps) deal with.

  The only factor that remains is an error in the MVM, ie. if the MVM trips up (because of an internal error), then all the apps running in it are affected.
  This is of course a problem, but the argument (in the paper, if memory serves right) is: this is the same situation as with an OS: if an OS fails, then all running apps fail; if the MVM fails all apps fail. Not a solution, but an incentive to make the MVM very stable or at least very failure resistant.

  You are right that MVM like solutions arent panaceas for slow startup,... but I suppose webhosters that offer Java Servlet engines dont have to run 10s of seperate JVMs with the engine to get proper seperation, instead the MVM can share all of them.

  
  The whole sharing between JVMs is a difficult matter... it gets more interesting if you want to share dynamically optimized code between apps... but what if the two apps state allow different optimizations (if one instance of an app uses a different set of classes than the other one; imagine Tomcat instance with the Foo.jar loaded, the other one that doesnt need it) ? Then the Dynamic Optimizer needs to fall back to a more conservative optimization for both programs...

  Posted by: murphee on June 15, 2005 at 09:09 AM

• Chet - thanks for getting this discussion started and to all the
  participants (including the future ones) please keep posting!
  To keep my comment relatively short now I'll elaborate a bit only on
  the issue of MVM's robustness.

  Sure, nobody likes their app to crash because some other code
  malfunctions. Yet we trust operating systems to run multiple applications.
  How come? It is so because OSes got a lot of designing/testing/debugging attention.
  The same is happening to the commercial implementations of the Java
  virtual machines. When compared to the implementations from say
  '97, JVMs from '05 are much more stable and we trust them to run
  just about any imaginable application. If they are stable enough
  to run a single app why not more than one?

  Class loaders are often suggested as a good mechanism to realize
  multitasking in a single virtual machine, and in fact many
  a sophisticated framework based on them exists. But class loaders
  do not isolate applications (and nasty surprises do happen, depending
  who's your app's neighbor class-loadee), and do not allow for clean
  application termination. Yet, despite these shortcomings, they
  are used to multitask in a single JVM. So here we have at least
  one case where modern implementations of the JVM are perceived
  stable enough to run many apps simultaneously.

  Another related topic is native code. The problem can be refined
  further into (a) core native code that implements the runtime
  and native methods of core libraries, and (b) user-supplied native
  libraries. (a) boils down to platform stability, and hopefully
  we'll see more and more internal JVM code written in Java, which
  should further mitigate the issue. For user-supplied native code
  there exist technologies (e.g.,
  )
  that can contain its bad behavior. If the overhead of such solutions
  is too high, one can still run the app in question in a dedicated JVM/MVM.

  Posted by: gczaj on June 15, 2005 at 10:43 AM

• Chet, I think you've completely missed the reason why a multi-tasking vm is crucial for java. The startup time and footprint for desktop apps is completely irrelevant, an optimization that makes only a slight real difference.

  The *real* problem a multitasking vm could solve is in hosted web applications. Have you noticed that getting a shared hosting jsp account is much more expensive than getting the equivalent account? Have you heard people say, and I've heard this more times than I can count, that "java/jsp just isn't designed to host multiple users"?

  It's because if you run Tomcat with multiple user accounts, you cannot control the amount of memory that each account uses. If you have 100 accounts on one machine, and just one of them ends up in an infinite for loop endlessly adding data to a list, it eats up all the memory and crashes every account. Because PHP runs each request in a seperate process, I believe it is possible to limit how much memory each request can take up.

  We need to be able to run several web accounts in the same jvm without one being able to crash the other. Java can prevent calling certain methods from crashing the jvm by using a security manager. It can prevent code from eating all the cpu cycles by running it in seperate threads. But it can't prevent code from eating up all the memory, without creating seperate jvm's - and *that* really is a memory hog when you're running the jvm + tomcat + tomcat's libraries.

  In conclusion, it's not the startup time or the memory sharing for desktop apps that's important, it's the ability to control memory use in different web apps on the same jsp server that is important. If there's something other than a full blown "MVM" that would do that, please add it to the jdk as soon as possible. Thanks.

  Posted by: paulrivers on June 15, 2005 at 10:48 AM

• Chet, I think you've completely missed the reason why a multi-tasking vm is crucial for java. The startup time and footprint for desktop apps is completely irrelevant, an optimization that makes only a slight real difference.

  The *real* problem a multitasking vm could solve is in hosted web applications. Have you noticed that getting a shared hosting jsp account is much more expensive than getting the equivalent account? Have you heard people say, and I've heard this more times than I can count, that "java/jsp just isn't designed to host multiple users"?

  It's because if you run Tomcat with multiple user accounts, you cannot control the amount of memory that each account uses. If you have 100 accounts on one machine, and just one of them ends up in an infinite for loop endlessly adding data to a list, it eats up all the memory and crashes every account. Because PHP runs each request in a seperate process, I believe it is possible to limit how much memory each request can take up.

  We need to be able to run several web accounts in the same jvm without one being able to crash the other. Java can prevent calling certain methods from crashing the jvm by using a security manager. It can prevent code from eating all the cpu cycles by running it in seperate threads. But it can't prevent code from eating up all the memory, without creating seperate jvm's - and *that* really is a memory hog when you're running the jvm + tomcat + tomcat's libraries.

  In conclusion, it's not the startup time or the memory sharing for desktop apps that's important, it's the ability to control memory use in different web apps on the same jsp server that is important. If there's something other than a full blown "MVM" that would do that, please add it to the jdk as soon as possible. Thanks.

  Posted by: paulrivers on June 15, 2005 at 10:49 AM

• Tiger (1.5) with its sharing of core classes is a great step forward. It is performing amazingly well on my 2,5-year old Athlon :) I suppose that it also means some memory sharing (mmap). But if we already have client and server vms in SDK, why not add another one (mvm) to choose from and leave client as the default? Then for sure lots of java geeks would help in stabilising it ;)

  Posted by: jezuch on June 15, 2005 at 12:18 PM

• There's another issue also regarding the MVM.

  It's something I ran into long ago, and it has to do with Multi-User Unix systems.

  There are pressures, from Sun for example, to move to the Thin Client model, particularly for back office applications, call centers, etc.

  Let's take a call center as an example.

  With regards to the Footprint problem with Java, it's not the initial foot print of an application that is so much the issue, it's the secondary foorprint of other applications.

  Back to the call center, imagine you have 20 people in the call center, and you'd like to run them on thin clients against a shared server. Lets further add that they each run a Java based application, and the footprint for the entire app is 64MB.

  All told, you need 1.2G of RAM for 20 users on the main server.

  On UNIX, processes basically have two kind of memory -- executable, read only memory and data, read-write memory. When a program loads, the system maps the executable part of the program into memory, and initializes the data memory, and from this you get the overall footprint.

  However, when a program runs the second and further times, notably simultaneously, the UNIX system sees that these programs are the same and thus they can share the executable, read only memory pages. So, the combined footprint of 2 copies of a typical UNIX program is the code segment + 2*data segment. For every new copy, you get a new data segment, while leveraging the already existing code segments.

  When you add in 20, 50, 100 users, all running the same thing, this is a substantial memory savings.

  But with Java, all of those classes and jars are essentially "data" for the "executable" JVM. So, your overall memory impact is much greater. Now conceptually, the JVM can map those class files read-only and share them, and it may well do that (I don't know). But once the JIT gets a hold of the code, that sharing vanishes, as the JITed code, even though executable, is "unique" for each instance, and not shared among them.

  So, outside of simple start up times, when you start getting several users on the same computer, the overall overhead for shared applications can add up and something like the MVM may well be able to reduce that load.
  

  Posted by: whartung on June 15, 2005 at 03:37 PM

• I beleive you have to split the MVM benefits into 3 categories: benefits to apps in a desktop environment, benefits to apps in a 'hosted' environment, and benifits to apps that would specifically make use of the Isolate API (ie: future servlet containers, etc).

  I think it is safe to say the the 2nd category of apps is the largest in terms of usage in today's environment, and the MVM's potential benefit there is incredible. I work for a 'servlet shop' and believe me, I'd love to have every developer's instance of Tomcat running in one VM. And as far as the future goes... the design, structure, and administration of 'container based apps' would be practically become Nirvana as they move into the 3rd category of app with the Isolate API.

  As far as the first category... While the benefits RIGHT NOW aren't nearly as great as for containers / hosted apps, the MVM adds a great deal of potential to the Java on the desktop. As Swing gets faster and faster and the 'frameworks' around it get better, developing Java apps for the desktop becomes increasigly appealing. As NetBeans, etc. have shown, Java CAN be fast and usable. With the footprint benefits of the MVM allow a TRUE Java Desktop, with most, if not all, apps written in Java. (The java memory system could even increase performance relative to native apps in this realm, especially with the the ability to have an 'active' app's young generation borrow from the JVM heap)

  At any rate, the MVM is by no means a panacea, but it brings strong benefits to the current patterns of Java usage, and great potential to Java's future.

  Posted by: pdo400 on June 15, 2005 at 07:26 PM

• Ugg, I should have previewed... sorry for the repost, but paragraphing is essential. :)

  I beleive you have to split the MVM benefits into 3 categories: benefits to apps in a desktop environment, benefits to apps in a 'hosted' environment, and benifits to apps that would specifically make use of the Isolate API (ie: future servlet containers, etc).

  I think it is safe to say the the 2nd category of apps is the largest in terms of usage in today's environment, and the MVM's potential benefit there is incredible. I work for a 'servlet shop' and believe me, I'd love to have every developer's instance of Tomcat running in one VM. And as far as the future goes... the design, structure, and administration of 'container based apps' would be practically become Nirvana as they move into the 3rd category of app with the Isolate API.

  As far as the first category... While the benefits RIGHT NOW aren't nearly as great as for containers / hosted apps, the MVM adds a great deal of potential to the Java on the desktop. As Swing gets faster and faster and the 'frameworks' around it get better, developing Java apps for the desktop becomes increasigly appealing. As NetBeans, etc. have shown, Java CAN be fast and usable. With the footprint benefits of the MVM allow a TRUE Java Desktop, with most, if not all, apps written in Java. (The java memory system could even increase performance relative to native apps in this realm, especially with the the ability to have an 'active' app's young generation borrow from the JVM heap)

  At any rate, the MVM is by no means a panacea, but it brings strong benefits to the current patterns of Java usage, and great potential to Java's future.

  Posted by: pdo400 on June 15, 2005 at 07:30 PM

• As someone working on a Java application suite, I am very interested in the MVM.

  I might add another concern, though, to Chet's: Force quitting. There will need to be a way for a user to force quit a Java application without killing all of them. At the very least, a task tray icon with a popup menu and a "Force quit Java application..." option. Even then, we're going to have issues with users going "This program is hanging. ctrl+alt+del; okay I think it's a Java program, so let's try killing Java... Oops."

  On the bright side, the MVM opens another encouraging possibility: Starting the VM at boot time. This would almost eliminate the Java start-up penalty, leaving applications with more or less normal start up times.

  William

  Posted by: afishionado on June 15, 2005 at 08:34 PM

• Question: With MVM will every swing app get its own AWTEventThread?

  If so, MVM should be top priority because this can not be achieved
  by solutions like Nailgun or Jsh.

  
  

  Posted by: maassg on June 15, 2005 at 11:27 PM

• The other thing this is obviously usefule for is building a jvm shell. This has always been a real pain. There are various attempts littered round webspace many of which foundered due to problems with the System.exit, the property user.dir and File semantics

  Posted by: garythompson on June 16, 2005 at 02:38 AM

• Hi!

  I love programming in Java. I recently realized that even though I'm a Java programmer, when I download a desktop tool, I instinctly choose a non-java solution. That's because of the speed difference. (Yes, I have a fast computer.)

  I've always thought of MVM as a "JVM in a service", starting at boot time, and as natural part of Mustang. I secretly hoped it would also provide caching of previous JIT compilations to further speed up processing. THEN would Java (desktop or otherwise) apps feel like native ones.

  I'm sure one can raise a bunch of objections why it's not feasible, like security and stuff, but honestly, customers don't care. They say: solve it! This is something Sun might need to understand.

  The bottom line is when there's a way to increase Java desktop usage by let's say 200%, it's a chance that shouldn't be missed. It should be _force-done_ :-) If you don't do it first, the competitors will.

  I'd love to program Java for those many people who have stayed away so far.

  Posted by: atus on June 16, 2005 at 06:16 AM

• yes, I think that the jvm should be a service too!

  this way it is eliminated the startup delay for even the first java program that is run.
  under windows you can create an "automatic" service if you want this functionality. If you don't want it you can select "manual" startup (ie it is started only when the user run java.exe for the first time).

  Posted by: furbotto on June 16, 2005 at 06:34 AM

• About the crash thing, when I switch to Mac OS X I heard a lot about PROTECTED MEMORY. Isn't something like that this is needed?

  I agree with you that the crash-one-die-all scenario is not a good one. But I disagree with the conclusion (MVM is for Application suite). I beleive that MVM is not for application suite. I beleive that MVM should have the crash-one-die-all case solved BEFORE it is rady for prime time.

  Posted by: urddd on June 16, 2005 at 06:37 AM

• Chet, your blog makes me a little sad.

  When I first read about your MVM, the MVM development team seemed very enthusiastic. I was thrilled too.

  But here, you're basically arguing that (1) it's not robust, and (2) it would only apply to something that doesn't exist anyway (app suites). Pardon me, but it sounds like objections one would say if he didn't want to do the work.

  Security. There are several Java server-side programs running for MONTHS. I agree that desktop apps might not always be as robust, but it's too weak a reason not to implement MVM ASAP! Honestly, how many times does your desktop apps crash because of native call errors? To me, less than once per year, and even then, it's always easy to isolate the problematic app. I don't like it when it happens, but I dislike the Java application startup misery too. That'd completely go away if I could start _one_ JVM service at boot time, for all later Java apps.

  App suites? The way things are, I don't see many app suites coming. Maybe if the JVM could be started once, at boot time, we would see wider adoption of Java _APPS_, and then would follow Java App _SUITES_.

  Please reconsider this great opportunity! MVM should go into Mustang. It could greatly contribute to the adoption of Java. Think about it:

  - apps would feel more native and responsive

  - command-line utils would finally be feasible

  - running many Java apps would be cheaper in terms of computer resources

  - therefore, OEM inclusion of Java into new computers would be much more widespread

  - Java development (which usually means restarting small Java apps 100 times / hour, sometimes also server programs) could be so much faster

  - plus, MVM is just the coolest feature since the Java5 extensions.

  Posted by: atus on June 16, 2005 at 06:49 AM

• If is possible to securely run multiple tasks in any OS, even in Windows, why is not possible to do the same thing in a VM?

  I am sure that somewhere there is some code to look at... :)

  Posted by: ildella on June 16, 2005 at 11:51 AM

• 
  Disclaimer, I'm a member of the group that has developed MVM, so it's fair to say that I'm biased in its favor.

  Several of the previous comments have touched on a point that I want to push on.

  
  Think of the JVM as an operating system kernel! (When you come right down to it, it really is, just running on a considerably richer set of hardware than most OSes do.) We collectively need to embrace this view and run with it.

  
  For example, what about startup time? Well, you want your OS to boot reasonably quickly, but what you really want it to do is to get each app rolling really quickly. That's what MVM's designed to do.

  
  And what about crashes? Well, some notorious counterexamples aside, these days you don't expect your OS to crash, and Sun provides an excellent example of an OS that doesn't crash in the form of Solaris. My take is that if we can make Solaris bulletproof, we ought to be able to make our other OSes (in particular, JVMs) bulletproof, too. As much as anything else, it's a matter of will. Anyhow, I just don't buy the "it might not be robust" argument as a reson to avoid running multiple applications in a single VM. Shame on us if it isn't!

  
  (This argument ignores the problem of native code that we don't own. There's a twofold solution to that. First, use the underlying OS to isolate it so that it can't harm anything but itself; we prototyped this approach in a previous version of MVM and plan to include it in a future MVM release. I'll get to the second line of attack below.)

  
  Another question: If the JVM is an OS kernel, shouldn't the entire JDK be a complete operating environment? When you add the suite of utilities, applications, and middleware that augment the kernel in modern traditional OSes, you get a complete computing environment. Why shouldn't the Java platform be complete in the same sense?

  
  Much of what our research group's focus is in attacking this problem. The platform doesn't have anything that plays the role of an address space? Help get the Isolate API into the platform (that's the fundamental addition the API provides). There's no way to manage resource usage on the platform? Design and implement a resource management API (coming in a future MVM release).

  
  And so on. Which leads to the second line of attack against bad native code. Eliminate it by providing pure Java solutions to problems that formerly required recourse to native code.

  
  These points all add up to my disappointment in Chet's viewpoint. I think the entire Java community should be driving hard toward a world where you can figuratively live your whole life without having to step outside of the Java platform. Technologies like MVM, both in its role as a provider of the expanded set of APIs we'll need, and in its role as an implementation that addresses performance and scalability bottlenecks that impede living in the Java world are an integral part of that vision.
  

  Posted by: glenn_skinner on June 16, 2005 at 05:27 PM

• I think the crash issue is solved.

  I don't know if things have changed over the time, but long time ago I read a Barcelona research paper.

  From what I remember, you had a MVM running and every client has a unique native process responsible of doing the JNI calls, if something crashes, only that java will crash.

  Cheers
  JD

  Posted by: jdavi on June 17, 2005 at 02:36 AM

• Well, it seems courious to me that no one knows for sure what is the current development state of MVM... if it can isolate tasks or not. Who can we ask for this?

  Posted by: ildella on June 17, 2005 at 04:50 AM

• I'd like to briefly answer two questions raised in the comments above.

  The crash issue is not solved - what is addressed (but not implemented yet
  in the current release of MVM; we implemented in in previous prototypes) is containing the effects of a crash of user-suppied
  native code. We haven't found a magic bullet to make the code implementing
  JVMs 100% robust. I guess in addition to debugging and testing, robustness
  can be increased by implementing more of the Java platform in Java itself.

  Some has asked about the current development state of MVM. Yes, it can isolate
  tasks - please download the first
  release to get the details.
  

  Posted by: gczaj on June 17, 2005 at 11:20 AM

• I suggest that the poster above who said "...no one knows for sure what is the current development state of MVM... if it can isolate tasks or not. Who can we ask for this?" ask his question in the MVM discussion forum (which has been distressingly quiet so far).

  Posted by: glenn_skinner on June 17, 2005 at 11:20 AM

• I can't agree more with Glenn Skinner on
  how the MVM is like an OS kernel. I think
  this is a very important concept that Java
  developers should try to spread around and
  discuss it more.

  Coming from a C/assembly
  background and now full-time on Java,
  I often feel the high-levelness of Java has
  the side effect of blinding us from this
  VM-is-like-an-OS-kernel concept. I also
  remember the (unfortunate) picoJava CPU
  that Sun tried to build that can execute
  bytecode in hardware.
  Extrapolating, it is
  not hard to see how threads are becoming
  processes and processes becoming
  virtual machines. VirtualPC and VMWare
  anyone?
  MVM *is* important. It is the last missing
  piece of technology that will propel Desktop
  Java into mainstream. Just look at what the
  dashboard widgets are doing for Mac OSX.
  Steve Jobs gave it the biggest share of time
  demo'ing these *widgets* than other demos
  recently at the WWDC 2005. For those who
  watched the keynote, I'm sure you all remember
  this very important quote: 'Java, it just works',
  when talking about transitioning to Intel.
  .rex
  

  Posted by: rexguo on June 18, 2005 at 10:51 PM

• Glenn, the MVM discussion forum can't even be viewed when I clicked on the link. It says I need a permission. Maybe that's why it's been too quiet?

  Posted by: rexguo on June 18, 2005 at 11:03 PM

• Interesting stuff. It seems to me that most of this MVM stuff, at least from a functionality view, could be accomplished using threads from a single, traditional, JVM. It seems like just about all of it could be accomplished with some seemingly minor API changes (adding the Isolation api and perhaps stuff like giving each swing "app" its own AWTEventThread)
  I also think that most of the pain sharing aspects of MVM could be achieved from multiple, traditional, JVMs by some seemingly minor implementation changes. I say seemingly, because, not knowning much about the internals of the JVM impl, it can't be easy, but, from the outside, the differences would seem earthshatteringly different. Stuff like sharing heaps. Sharing resource pools, etc. All this can be done on most, if not all modern/full function target platforms via shared memory, etc.
  I know this is asking a lot from the Sun developers, I know that there are limited resources, but I have to agree with some of the posters, in that this represents a major posibility in the World Domination of Java. (tm)

  Posted by: jeffwalker on June 19, 2005 at 08:14 PM

• rexguo said above that he can't view the MVM discussion forum. The problem is alost certainly that to see anything of the MVM project pages, you need to have the Researcher role. So please request that role; if you still can't get in, let me know and I'll try to track down the problem.

  Posted by: glenn_skinner on June 20, 2005 at 09:19 AM

• Memory footprint is, IMHO, the single largest technical problem Java has today. Yes, it is better than it was (and the class sharing in JDK 1.5 is a nice improvement), but it still is a large, serious problem limiting Java whenever more than one Java program runs. In fact, it is such a serious problem that people tend not to run many Java programs at once, in my experience.

  
  Startup time is annoying, but a lesser problem (although it does leave a bad impression, and is the sole remaining piece of evidence that can be cited for the 'Java is slow" myth repeated by people who haven't done their homework).

  
  This really isn't much of a surprise when one considers what the JVM consists of today - a run-time compiler that is loaded every time Java runs a program or applet.

  
  Yet, even though the JVM run-time is huge compared to a native executable, Java can run with the best of them, CPU performance wise. This is truly an amazing technical achievement, and one that Sun should be very proud of.

  
  I have been following JSR 121 with considerable interest, and was looking forward to a Sun beta at some time in the very near future. I am very disappointed to hear that a production release has been put on hold and the project sent back to SunLabs.

  
  As others have said, until we get this type of functionality, we will always hesitate to run more than a few Java programs at once. Sure, on larger memory machines we can run a few more, but we'll always be watching, since we know we're consuming huge chunks of memory each time compared to native. Yes, as Chet says, the situation is somewhat improved with larger memory machines but it is still a significant concern.

  
  I am pleased that Chet was interested enough to bring this up and raise some hard questions. Let's deal with them:

  
  1. Someone has to take the hit (the easy one): absolutely, one needs to start the MVM as early as possible - during boot on a single user machine or during login on a multi-user machine. I would leave fancy, cross user JVM sharing to V2.0 (I see work is underway on this very thing at SunLabs).

  
  2. A single problem takes down all running Java programs: The MVM needs to be robust. This means that, baring a bug/crash in the O/S or the MVM, the MVM must be resilient, and faults in a single Isolate need to be limited to that Isolate.

  
  There are two points here: #1. The JNI isolation described by Greg's group needs to be implemented so that a crash in JNI code is localized to a single Isolate. I am somewhat concerned about the performance ramifications of this, but I see no option. I would put this up to the classic tradeoff that is often made between footprint and performance - here, to save footprint, we need to sacrifice a bit of performance. It might be worthwhile to have a "live dangerously" option whereby this can be turned off, but it needs to be on by default.

  
  #2. Internally in the MVM, the Isolates need to be insulated from one another. A major point here is that a single Java program running out of memory must not affect other Java programs - cause them to run out of memory. A related point is that different Java programs may have different memory needs - they need to be able to, at a minimum, specify this (pass some of their command line options through to the Isolate create). In the interest of keeping it simple and not doing more than necessary, I would limit, for example, gc options to the MVM and not the Isolate.

  
  I agree that the initial release should have MVM logic off by default, just like concurrent gc was initially off by default in its initial release.

  
  Once the technology has proven itself robust (specifically, Isolates don't take other Isolates down), I see no reason why it can't be on by default, particularily for desktop Java. Lets keep the option for standalone, and lets have a way of having multiple MVMs but lets remove the memory tax Java has, once and for all.

  Posted by: ga24 on June 22, 2005 at 11:33 AM

• You are pretty much out of arguments.
  What you say is ridiculous. Applications running together have no reason to crash more than all separetely, plus there is some opensource projects doing it.
  You are volontarely slowing the progress of Java.
  Yes, go loose time on ridiculous annotation, and do not give MVM.

  If I was your boss, I would fire you to show so much arrogance and ignorance about the user's, it is sickening.

  Posted by: sergebureau on July 22, 2005 at 10:34 AM

• 
  sergebureau: Wow - I think you missed the point of the blog by a pretty wide margin. If I felt so strongly against doing anything in this area, I wouldn't have even bothered to write the blog because it wouldn't be worth discussing.

  The point of this blog was to bring up some of the items that come up in the context of "should we or shouldn't we", and to gather feedback and conversation on the pros and cons involved. I think a lot of the points raised in the comments above are great, and I'm mulling over them (along with other people at Sun). Flaming me for bringing up the topic and encouraging discussion seems a bit silly...
  

  Posted by: chet on July 22, 2005 at 11:12 AM

• Good blog. I agree that an MVM is a niche, but it is a niche that will lead to an explosion of new pervasive uses for Java. Here are some examples:

  Java Service Manager: Ability to create a true service manager in Java that can fire off Java services and kill them safely.
  Java Desktop: Ability to create a desktop manager in Java that can launch any Java application and kill it safely.
  Java Shell: Ability to create a robust Java shell.
  Java OS: Ability to create a Linux Live CD that boots the hardware and launches a single MVM with a Java Shell. Everything else runs from there. You could effectively box in Linux.
  Others?

  There are many projects out there that have tinkered with trying to do all of the above, but they all fail because of the need for an MVM. I think that is why Serge is so upset because his projects touch on some of the above. There are many projects out there that are just waiting for Isolate to be implemented. Personally, I have some server side service managers that only limp along because of the inability to isolate Java threads (basically fix Thread.stop() and provide a dedicated System.environment).

  
  Please reconsider enabling MVM. You are missing out on a brand new eco-system for Java. In order for Java to be pervasive, you need to go this last mile. Box in Linux to hardware configuration and drivers. Let Java do everything else.

  
  Thanks... Sean

  Posted by: sdrucker on July 22, 2005 at 12:40 PM

• MVM might not improve performance as much as caching JIT, with setup time compilation. If the devs are not willing to focus on MVM, then they should spend more time to push caching JIT to Mustang.

  Even though the overall time spend on compilation would be longer with this scheme, people don't tend to care about the amount of time spent on setup. Doing this would mean the application would startup at almost native speed from the very first time it is launched and the JIT can spend more time further optimizing parts of the program when the CPU is not very busy.

  More critically, this is already present in .Net and if Java wants to survive, it has to get over the perceived performance problem.

  Posted by: homersimpson on July 25, 2005 at 06:51 AM

• This MVM thing sounds kewl, but I am already using my own "shared JVM". In our application, upon installation (via Install4J), we install a service that runs all the time in the background, it's primary function hitting our server and checking for various types of notifications for the installed user. Our Swing client, when started, starts up immediately by "attaching" to the shared JVM. I am doing this fairly easily, with an article from Java Pro a while back that showed a way to do this. However, where as that article assumed different apps get their own classloader instance, my application is using my plugin engine (www.platonos.org) so I start a "service" plugin that runs all the time, and when the client launch request is passed to the already running JVM which has the plugin engine already executing and the service plugin going, my engine simply loads the client side plugins. Upon closing, the service stays running, the GUI plugins are unloaded.

  Now, I realize other Java apps wont "share" the JVM. I do this primarily because the background service uses code that is shared with the client. Essentially its one big application with client side GUI plugins running when needed, then going away.

  It work's pretty well, although on Mac OSX we are seeing issues in restarting the GUI, not sure why yet.
  

  Posted by: buckman1 on July 26, 2005 at 12:29 AM

• Chet,

  I completely understand your viewpoint as it was mine until recently. When I first heard about the Isolation API, my first though was of a ton of Java apps collapsing from VM death. But I've changed my mind. When it comes to software, caution seems to be a recipe for certain failure. It irks me to say this, but I think we need to take a page out of Microsoft's book. Look what happened during the browser wars between Netscape and IE. Microsoft, in a shameless effort to edge out Netscape, started to preload core sections of IE at boot time. For years Netscape sat on its high horse claiming the Netscape wasn't going to slow down your boot process or reserve a chunk of virtual memory just to make startup faster. But in the end (and far too late) after way too many reviews comparing Netscape's poor startup performance to IE, Netscape partly capitulated and installed an agent running in the system tray. It is my understanding that Open Office has done this for the same reason.

  I really think you might want to spice up your opinions with a touch more aggression. For goodness sake, please don't assume that people running more than one Java process simultaneously is going to be a rare occurance! With all respect, that is a loser mindset. Assume, there will many people running many Java apps. Assume that you guys are make a solid VM. Assume that people will not need to write dangerous JNI to make a popular app. And assume that when this does happen, most people will take it in their stride and forgive you as long as it doesn't happen too often.

  Its more risky, but I think its time for Java to take off the gloves. Time matters more than anything in this market and a 90% solution now is better than a 100% much later. I would even go so far as preloading the VM, java.* and javax.* at boot time by default with a user option to disable this (and no-one will).

  On more practical matters, I think this MVM is their to encourage the development of lightweight apps. It is precisely things like Instant Messenging clients, Todo lists, FTP clients, etc which cannot be seriously written in Java now because of footprint and startup time. Sure, I agree that I wouldn't want IntelliJ IDEA dropping dead because of my IM client. Perhaps specific applications should be able to request their own VM? That way the existing heavyweights, industrial and financial apps could trade their startup time for stability, while all the rest throw caution to the wind.

  Please think about it. There's an oppurtinity for both success and failure here, but its oppurtunity nevertheless. From my point of view, the risk of Java not being taken seriously for the Desktop is even greater.

  Regards,
  Brendon

  Posted by: brendonm on July 26, 2005 at 06:00 AM

• Chet,

  I completely understand your viewpoint as it was mine until recently. When I first heard about the Isolation API, my first though was of a ton of Java apps collapsing from VM death. But I've changed my mind. When it comes to software, caution seems to be a recipe for certain failure. It irks me to say this, but I think we need to take a page out of Microsoft's book. Look what happened during the browser wars between Netscape and IE. Microsoft, in a shameless effort to edge out Netscape, started to preload core sections of IE at boot time. For years Netscape sat on its high horse claiming the Netscape wasn't going to slow down your boot process or reserve a chunk of virtual memory just to make startup faster. But in the end (and far too late) after way too many reviews comparing Netscape's poor startup performance to IE, Netscape partly capitulated and installed an agent running in the system tray. It is my understanding that Open Office has done this for the same reason.

  I really think you might want to spice up your opinions with a touch more aggression. For goodness sake, please don't assume that people running more than one Java process simultaneously is going to be a rare occurance! With all respect, that is a loser mindset. Assume, there will many people running many Java apps. Assume that you guys are make a solid VM. Assume that people will not need to write dangerous JNI to make a popular app. And assume that when this does happen, most people will take it in their stride and forgive you as long as it doesn't happen too often.

  Its more risky, but I think its time for Java to take off the gloves. Time matters more than anything in this market and a 90% solution now is better than a 100% much later. I would even go so far as preloading the VM, java.* and javax.* at boot time by default with a user option to disable this (and no-one will).

  On more practical matters, I think this MVM is their to encourage the development of lightweight apps. It is precisely things like Instant Messenging clients, Todo lists, FTP clients, etc which cannot be seriously written in Java now because of footprint and startup time. Sure, I agree that I wouldn't want IntelliJ IDEA dropping dead because of my IM client. Perhaps specific applications should be able to request their own VM? That way the existing heavyweights, industrial and financial apps could trade their startup time for stability, while all the rest throw caution to the wind.

  Please think about it. There's an oppurtinity for both success and failure here, but its oppurtunity nevertheless. From my point of view, the risk of Java not being taken seriously for the Desktop is even greater.

  Regards,
  Brendon

  Posted by: brendonm on July 26, 2005 at 06:00 AM

• Your chief objection to MVM appears to be the uncertainty of system stability from JNI code. This is a security policy decision.

  The JVM already offers mechanisms to control security policy. In particlular, System.loadLibrary() already throws SecurityException.

  Some users might be willing to relax a default 'no risks' security policy. They ought to be given an opportunity to do so.

  The opportunity should probably be more accessible than setting systemwide policy via PolicyManager. (It could be a userwide security policy, set via a really slick GUI).

  Posted by: dtbullock on July 31, 2005 at 09:15 PM

• Hasn't Apple been doing something like this with their implementation of Java for years now?

  Posted by: mcrocker on August 03, 2005 at 08:16 AM

• Well MVM solution can be implemented out of Sun-controlled JVM by anybody else, just replace java.exe with client that use RMI to pass command-line parameters to some Java server that loaded JVM dll. Just for public to taste.

  Couple more of real challenges:

  older JRE versions will not benefit;
  modern JRE versions might be needed (like, JBoss 3.2.3 cannot work under Java 5 because of JMX versions);
  different isolates JNI dlls may inspect memory of other isolates -- so JSP hosters might steal passwords / certs from each others;

  
  For me, better JVM data sharing seems better.

  Posted by: wwk_killer on August 06, 2005 at 01:22 PM

• mcrocker:

  Not quite; what Apple has been doing is sharing compiled class files,
  and that code has been incorporated into JDK 1.4 Tiger. What we're
  talking about with MVM is sharing the actual JVM process among
  multiple Java applications.

  Look at it this way: servlets are wonderfully scaleable, since a
  single JVM runs them all (they each get their own thread), and
  they all play nice together - don't execute nasty JNI code and
  bring down the JVM (even though they COULD, ignoring permissions).

  MVM, conceptually, is bringing this capability to the desktop.

  Now do you want it? :)

  Seriously, its a significant piece of work deep in the guts of the
  JVM, so its not to be trivialized and will take time; it is, IMHO,
  extremely important and will bring DRAMATIC benefits.

  Think its time to make another bug report and get voting...

  Posted by: ga24 on August 12, 2005 at 01:32 PM

• Why can't the JNI/crashing issue be solved as such - run the MVM and all pure-Java apps in one process, and run any Java code which uses JNI as another process? If the stability of the JVM is so important, isolating the process that runs the MVM from the process that runs code that uses JNI should provide stability to the MVM, even at the cost of JNI applications crashing. I'm not a JVM expert - but does the JVM at the point where it executes JNI code almost completely relinquish control of the flow to the externalk JNI code? If so - then you could run the JNI apps in a separate process, outside of the process holding the MVM. The interprocess communication between the MVM-holding process and the JNI-holding process can be done through IPC such as shared memory (which will avoid double-buffering between the MVM and JNI process). I gather from the above discussions that code that does not use JNI and crashes, can be handled gracefully by the JVM/MVM - and that the only problem is code which uses JNI.. so by outsourcing the JNI execution flow to a separate process (or a pool of processes), does one not alleviate the "crashing JNI application takes down the whole lot of other apps" problem? Can someone elaborate more on this?

  Posted by: martinn on September 28, 2005 at 12:13 PM

• Dear Fellows,

  It is really a strange. The Developers of JDK don't expect multiple Java Desktop apps to run simultaniously? Then why did they develop Swing?

  So does one have to go AJAX route to have multiple apps on desktop?

  The excuses are all intellectual mastrubation. I have been running multiple JFrames using my own little framework. If app. isolation can not be achieved completely than why not give it in incriments and let the developers choose how much and how they can use the feature.

  The delay is causing me to look at alternatives because I sense that there is lack of maturity in the people who are doing this.

  Posted by: vsoni on July 28, 2006 at 10:12 AM

• "and I'm mulling over them (along with other people at Sun)"

  Not much new I see here. Almost every one who programs desktop professionally knows all this and you say you are "mulling over them"

  Sorry Chet. But the time for taking votes is long gone. We are getting older you know. Some of us may not see the day... you know what I mean ha!

  just do it!

  
  

  Posted by: vsoni on July 28, 2006 at 10:22 AM

• Start the MVM as system boot up time. This is not something that should be loaded at first demand, thus none of the applications take a major hit, and the system startup looks slightly but not noticeably slower.

  You have to be kidding me with the native crashing issue. A user is not some child that will refuse to use Java because a single program has crashed several. We're already used to this thanks to Internet Explorer. "Oh it looks like one is frozen, and the rest of my apps are now slow or broken too." Worst case scenario, the user realizes that one of his programs is broken, and will stop using it.

  Posted by: ilazarte on July 31, 2006 at 01:19 PM

• If it isn't already obvious, I too cast a hearty vote MVM java. It doesn't make sense that there is a walled off universe where every instance is causing mvms and dragging the user through the initialization process. In terms of Java's next generation functionality and service, I think MVM is a core requirement.

  Posted by: ilazarte on July 31, 2006 at 01:22 PM

• Great discussion but whatever tricks Sun comes up with at the end to make Java apps load faster and use less resources, lets not have that "lets have Mustang install a service in Windows so that it can be running in the background all the time" mentality please. That is not solving the problem at hand. While the MVM does sound like a nifty trick, I can see why Sun is hesitant about releasing it any time soon. I use Eclipse/IntelliJ/Netbeans/JDeveloper depending on what I need along with Tomcat/JBoss and Derby. So at any one moment, I have 3 apps running. I used to use Azureus for torrents but I switched to uTorrent because it is incredibly small and light. I for one would welcome an MVM to run the server, and IDE and the Java database. But please let's not go the way of installing startup services or anything like that start up automatically when one boots into the OS. I would much rather have a hit at the launch of an application (something we all experience right now anyway) and have the subsequent apps start up faster.

  One thing is becoming quite annoying and that is Sun's tendency to put eveyrthing into the JDK. Honestly, there is a Derby database with Netbeans, a Derby database with the Sun App server and and now a Derby database with Mustang! So at any one moment I have 3 of the same databases on my machine!

  Posted by: suryad on July 31, 2006 at 06:05 PM

• I know this is a 2-year old blog entry, just posting in case anyone happens to be digging through old information on MVM. I just wanted to add one (hopefully constructive) comment:

  The SunRay thin-client desktop. This looks like a great product, but one problem: I don't think Swing apps will run on this architecture without MVM. At 80MB per user (which I think is pretty reasonable for a Swing application from what I've seen), the SunRay architecture just isn't feasible - it no longer gets the kind of scaling to make Sun Ray's effective. Without MVM (and not just Class Data Sharing of 8MB rt.jar), the Java Desktop environment is no longer cost-effective with these thin client products.

  So why should it be high priority? One very simple reason: It will hit Sun's bottom line on selling thin-client hardware for the kind of apps they should most want to work in this environment - Swing apps. $$$Ch-ching$$$! Like it or not, MVM is now high priority. Thank you very much.

  Chet -if you happen to read this keep up the excellent blog and ignore the 14-year old flamers...
  

  Posted by: joehitt on June 22, 2007 at 10:33 AM

• Chet, thanks for this I am really interested in this project, how is it now? Will it be brougt into JDK7?

  Posted by: probing on December 09, 2007 at 07:29 PM

This work is licensed under a Creative Commons License.