Sun Senior Architect Murali Kaundinya discussed new features expected to be added to J2SDK 1.6, which included support for multitasking.

The new feature will allow multiple tasks to be isolated and run concurrently within the same VM.

J2SDK 1.6 is expected to be released in beta this fall.

Read more in Java to gain multitasking improvements

What would you like to see in 1.6?

This sounds like AppDomains in DotNET.

so, can I have a cluster of servers running the same VM ? Do we need now a new kind of EJB? EJB to local but not so much. +1 xml file +2 interfaces. +An expensive IDE to manage it all

What about improve Swing ? new look and feels, performance, new and easy components ready to use.

I have noticed a kind of move towards Operational System style APIs for Java as of lately. For example: Unified Printing API (Java Print Service API), Preferences API Specification, Application Installation API Specification, JTAPI 1.4 Specification, Debugging Support for Other Languages, JavaTM USB API, JavaTM APIs for Bluetooth, JavaTM Daemons, Application Isolation API Specification, JavaDesk, Monitoring and Management Specification for the JavaTM Virtual Machine, The Groovy Programming Language... taken separately they don't seem to be related, but each one contribute to what could be a complete API for an OS, just like .Net is aiming to be in the future too, enabling Java to substitute the underlying OS instead of being just another layer on it. We have seen JavaOS (http://ei.cs.vt.edu/~wwwbtb/book/chap21/javaos.html) in the past, now Sun has released the Java Desktop (which is _not_ an Java OS...), and together with all these JCPs going on, does all this indicate that maybe Java will grow to be a full OS in the future? I wonder.
Regards,
Henrique Steckelberg

Yes, Java is OS and I am glad that more and more people recognize/admit this fact.
From this perspective alliance with MS against IBM/Linux makes much more sense.

IMO it is battle for new OS: JVM – CLR – Linux. My bet will be on Linux.

I agree that Java is becoming more and more OS like. In my mind, this is a good thing. I know there are arguments for making Java more light weight, but really, the more OS-like Java becomes, the more it can take advantage of the hardware (and even the underlying OS) it is running on, and the more integrated (with its environment) it will seem. I remember being forced to write native code for a Java app simply because there was no way to do what we needed to do in Java. Yes, it may add an unwieldy number of APIs to Java, but at least I can avoid having to write native code... chances are greater that Java will be capable of the functionality on its own. Really, any major OS is going to have an unwieldy number of APIs to learn. It's just par for the course. It doesn't bother me too much that the JSR keeps adding new APIs to the mix. The only problem I have is when there is more than one API for similar functionality. :-)

Native code is a "boo" because of portability. Some people downplay Java's write-once-run-anywhere saying that it doesn't work or that people don't use or need it. Well, I've used it and needed it in almost every project I have used Java for, and it is much easier to test and port Java code than native code. For our little native code, we had to compile it for the various platforms we used it on and run tests for each platform, which happened to reveal significant platform differences, requiring a great deal of effort to overcome. In the end, the maintenance of the native side of the application was far more costly than the Java side of the application, even though the Java side had at least an order of magnitude more code and complexity. Naturally, that left a bad taste in our mouth. Sure, portability may be easier now than it was a few years ago at the native code level, but it is still far more difficult than at the Java level. When you have to support Windows, Linux, AIX, Solaris, and some other more obscure operating systems... well, Java is less painful.

Native code is a "boo" because of portability

Portability is one of the minor issues in my mind.

Native code is a pain to write, its error prone, difficult to debug, difficult to stabilise, tedious, the tool support is nonexistant (compared to managed environments) and ultimately its very, very unproductive.

So, even if you dont need portability, its still very painful.

-Nick

Native code causes downtime. At work we have tons of servers, lost of sun/linux/windows boxes, and each vendor wants their own box, with their own libraries, etc.... This is horrible to set up, but it's even worse if those boxes are actually important. If a server fries, where do you get a replacement? Can you find 5 year old hardware with exactly the native libraries they require on short notice? It's almost impossible to get a replacement system running in any reasonable length of time.

At least if it's in Java, you have a good shot (and with well written code, virtual certainty) that it will run correctly on any machine that is sufficiently powerful to run it. This is a huge advantage when you actually care about having things run all the time, as opposed to just occasionally.

In the real world, even the semblance of WORA is hugely powerful. The lengths people go to to attempt to discredit it is absolutely insane. I've had projects delayed by months because a box died while running a particularly finicky native library, it's not funny. Nothing even remotely close to that has ever happened with a java system.

See this link and associated articles:

http://research.sun.com/projects/barcelona/

This project is seeking to make JVM into a MVM, and is speicifically looking at isolation and so forth

david tuke

"IMO it is battle for new OS: JVM – CLR – Linux. My bet will be on Linux. "

Excuse moi... but isn't Linux already a new OS?

"IMO it is battle for new OS: JVM – CLR – Linux. My bet will be on Linux. "Excuse moi... but isn't Linux already a new OS?

Linux is not that 'new' :). But actually I meant 'new OS to replace Windows".

IMHO isolates could bring many benefits
such as bytecode sharing between isolates.

There could be just one virtual machine
running on a computer as a service.

The java command may just start a new isolate
in this singleton virtual machine.

Runtime libraries could be loaded only once
by the vm and then shared between isolates,
thereby reducing bytecode footprint.

Carlo.

Unless ClassLoaders architecture will be changed we will have the same or worse environment as we see in web and EJB containers.
IMO: ClassLoaders must not break language as they do now: functionality of instanceOf depends on ClassLoaders implementation and it is possible to have two instances of the same class from the same jar be in the memory and instanceOf will say that myObject is not an instance of MyObject even debugger tells that myObject belongs to class MyObject.

Carlo, I think you hit the nail on the head. Most of this seems to be about a single JVM running multiple applications, each in its own sandbox and isolated from other applications. There's not much information to go on, but it sounds less like an OS (though you could sorta look at it that way), and more about offering Java as a service on the OS (just like you say). This could indeed enable alot more sharing of more read-only portions of the JVM, and maybe even intelligent sharing of JIT'd code e.g. you could start out with a vanilla default JIT'd version and maybe re-jit for your local app if that seems warranted.

The monkey in the wrench is this protocol they're talking about. This was announced at a cluster conference, so it may go beyond merely having apps sharing a JVM - hmmm, maybe with more complete JVM sharing as a first step towards a Java clustering technology.

Sharing would be very interesting and generally applicable to alot of people without rustling anyone's feathers. Clustering stuff though - I wander how the app server vendors and other clustering products would feel about that?

    -Mike

IMHO, the actual replacement of the OS with an Java VM would be particularly beneficial to performance, since the VM would access resources directly instead of going though the OS layer in between them. From applications POV, This would work almost as POSIX has done for Linux, where an uniform API covering any and all apps needs is delivered to all applications, rendering the existing OSs redundant for JVMs. Computers would just have to bootstrap a single VM, not as an OS service, but as the OS itself, managing the computer resources and delivering the API for applications to access them. All these JCP I listed above take Java on and on towards such a solution. Again, this would be beneficial to performance, discarding a layer between applications and computer resources (memory, storage, screen, network, cpu, etc.). We already have APIs for accessing most of these resources today, the moment the rest that defines what an complete OS should have is mapped into the JVM and API, the OS will become redundant. I just don't know if what is still missing in Java for a complete OS is a lot or not. If it is not, then this Java OS shouldn't be far from being achievable. Such a beast would be a marvel: the same OS for almost any platform in existence... wow.

Anyway, having JVM as a OS service would be very nice solution indeed, and much simpler to achieve than creating a full Java OS.

Regards,
Henrique Steckelberg

Such a beast would be a marvel: the same OS for almost any platform in existence... wow.

Well, such beast already exists: Linux. Are you sure there is a need to create another one?

Such a beast would be a marvel: the same OS for almost any platform in existence... wow.

Well, such beast already exists: Linux. Are you sure there is a need to create another one?

Well, maybe not, but then, Linux itself already has some minor problems, like the multitude of distributions and packaging schemas, and lots of people complain about it being a 30 year old concept. I would see that as a good thing instead, since it has been used for so long, it means it is stable and based on good concepts: it works.

Starting fresh now would be a chance to fix these minor glitches, with the advantage of boosting Java somewhat and leveraging on the Java applications already in existence.

Regards,
Henrique Steckelberg

For the curious ones, here's an attempt of an actual JavaOS:
http://jnode.sourceforge.net/portal/

and lots of people complain about it being a 30 year old concept. I would see that as a good thing instead, since it has been used for so long, it means it is stable and based on good concepts: it works.

Agree. It is proven that Linux/Unix is able to work very well and because of exactly this I doubt new OSes make sense. There is a company that tried to simplify OS and continues to do so, but results are far from being perfect even with enormous resources in company’s possession.

As for leveraging many Java applications and libraries:
With some efforts we can compile Java with gcc into “true platform native code” on Linux and run it everywhere.
Also: IT industry has bad habit of NOT leveraging good concepts and much less libraries and tend to reinvent wheels.
Wheel reinventions: RMI, XML-RPC/SOAP
Good example: Apple adopted *nix/XWindow

Anyone remember the Lisp machines? (Java is Lisp.) The lisp "VM" was the OS, same benefits. Did not work that time, who knows this time?

Linux is fundamentally C based technology, with all that that implies.

Anthony

Anyone know what "Sockets Direct" is?

Anyone know what "Sockets Direct" is?

Sockets Direct Protocol is a session layer protocol with less than half the overhead of TCP/IP. It cuts overhead by making fewer copies of data and bypasses the kernel saving context switches. It's designed for the Infiniband architecture, I believe it will work with PCI Express and maybe other PCI * interfaces.

This means Java won't remain a slow poke in the data center. With SDP it can cut I/O latency to databases, file storage, and clustered servers.

Thanks for the explanation. Maybe they'll also clean up the horrid nio library.

Thanks for the explanation. Maybe they'll also clean up the horrid nio library.

Link:

http://infiniband.sourceforge.net/NW/SDP/overview.htm

I hope eventually Sun will come around and incorporate AOP into the Java language, my preference would be to incorporate something like what AspectJ does now.

I hope eventually Sun will come around and incorporate AOP into the Java language, my preference would be to incorporate something like what AspectJ does now.

I support this.

Yes, why isn't the primary focus on building a *language* instead of an operating system? It's ridiculous that so much work has been done on AOP, yet all via the "back door" by writing preprocessors and byte-code manipulators because the developers have no ability to influence the direction of the language.

Before adding the latest fad into the language, let's see those features prove themselves in the real world first.

Before adding the latest fad into the language, let's see those features prove themselves in the real world first.

I agree to wait on AOP, but at least enable the JVM so that we don't have to jump through hoops. Specifically

- Full HotSwap at runtime with schema changes
- Real hooks for load-time instrumentation. Got my hopes up with java.lang.instrument package, but it is not the real deal :(
- A full embedded Java compiler that can be called at runtime and that can accept strings to compile. (a.k.a what Javassist currently has).
- Full in-memory database of class references so we can do stuff like. SELECT joinpoints where Foo's constructor is called. (required for dynamic AOP)
- Dynamic Annotations that you can allocate and attach to a class, method, constructor, etc. at runtime.
- Dynamic Annotations that you can attach per instance.

All the above would improve the language and be enabling for AOP without requiring the addition of AOP to the language.

Bill

Before adding the latest fad into the language, let's see those features prove themselves in the real world first.

I agree to wait on AOP, but at least enable the JVM so that we don't have to jump through hoops. Specifically- Full HotSwap at runtime with schema changes- Real hooks for load-time instrumentation. Got my hopes up with java.lang.instrument package, but it is not the real deal :(- A full embedded Java compiler that can be called at runtime and that can accept strings to compile. (a.k.a what Javassist currently has).- Full in-memory database of class references so we can do stuff like. SELECT joinpoints where Foo's constructor is called. (required for dynamic AOP)- Dynamic Annotations that you can allocate and attach to a class, method, constructor, etc. at runtime.- Dynamic Annotations that you can attach per instance.All the above would improve the language and be enabling for AOP without requiring the addition of AOP to the language.Bill

One more thing: Add a bytecode manipulation library with the power of Javassist (www.javassist.org) to the SDK with the compiler support I talk about above. C# has this, don't they?

Bill

Bill: One more thing: Add a bytecode manipulation library with the power of Javassist (www.javassist.org) to the SDK with the compiler support I talk about above.

I looked at it this morning, and while it (Javassist) is about a zillion times cleaner than BCEL, it still didn't impress me (architecturally or in terms of its full scope.) I do happen to agree with you on the goal to include such functionality into the JVM itself though, but I don't think Javassist as it is would qualify.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Bill: One more thing: Add a bytecode manipulation library with the power of Javassist (www.javassist.org) to the SDK with the compiler support I talk about above.I looked at it this morning, and while it (Javassist) is about a zillion times cleaner than BCEL, it still didn't impress me (architecturally or in terms of its full scope.) I do happen to agree with you on the goal to include such functionality into the JVM itself though, but I don't think Javassist as it is would qualify.Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!

Although Javassist does need some work, it is clearly better than anything else out there, it's clear distinguishing factor being its embedded java compiler. My favorite feature is ExprEditor and MethodCall.replace(String putYourCodeHere). Can't get any simpler than that.

Bill

<blockquoteMy favorite feature is ExprEditor and MethodCall.replace(String putYourCodeHere). Can't get any simpler than that.Awesome. This belongs in the JRE or at least the JDK. I agree with Cameron that it's still lacking. Javac's AST classes should be publicized and synergistic with Javassist.

Javassist is among the best Javadocs I've read.

Your examples kind of begs the question Bill: at what cost would these be added? What features would we lose while this stuff was being added in? How much would it increase JVM memory consumption? Might it cause locking slow-downs or subtle and bizarre bugs?

In other words - is it really important enough to go into the JVM, and is it worth the costs?

     -Mike

Your examples kind of begs the question Bill: at what cost would these be added? What features would we lose while this stuff was being added in? How much would it increase JVM memory consumption? Might it cause locking slow-downs or subtle and bizarre bugs? In other words - is it really important enough to go into the JVM, and is it worth the costs? -Mike

Such a disappointing reply from you, but I will respond because I have additional points to make.

JRockit VM already has pluggable load-time transformers. JBoss microkernel classloaders have support for pluggable transformers. JMangler has support for transformers. It is trivial to add with no cost to anyone.

Jonas Boner tells me that HotSwap is or is going to be available within the JRockit VM in regular mode as well. AspectWerkz uses some HotSwap for dynamic AOP. So others besides myself, actually think HotSwap is a good idea. HotSwap is also needed for true hot deployment. Hot deployment aids in true 24x7 availability. Currently, hot deployment mechanisms lose all old instances of their objects. You make a valid point, what effect will it have on HotSpot optimizations? Well, make hotswap available at large and let the community figure out if it is usable outside the scope of a debugger. JRockit already deems this a good idea.

JBoss AOP has dynamic metadata per instance and per class. Very useful, at least for what we're writing. There is no overhead for it unless you use it. Even if you wanted to write a framework on top of JSR-175 (and we do) you can't because there is no way of allocation an annotation at runtime. Yet another problem I found with the spec is that AFAIK, there is no way of declaring an annotation value to be optional. Did these guys even look at how XDoclet was being used???

C# has a bytecode manipulation library. I remember at AOSD, Jonas and Alex complaining about bytecode hell with BCEL. I had to laugh as Javassist's embedded Java compiler made doing bytecode manipulation so easy. JSP compilers could also make good use of an embedded Java compiler that doesn't require the file system.



Bill

Thanks Bill, you did a great job of not addressing any of the questions! I'll reiterate: will it slow things down, will it increase memory consumption, will it bump other possibly more worthy features to implement it? These questions aren't a pot shot at you or JBoss or AOP - they're serious concerns. If they can do it without a big impact, great. If it's going to slow down the JVM, or increase memory consumption, or bump off more worthwhile things, then why bother?

After all - you and other AOP teams seem to live just fine without these things today :-)

    -Mike

Thanks Bill, you did a great job of not addressing any of the questions! I'll reiterate: will it slow things down, will it increase memory consumption, will it bump other possibly more worthy features to implement it? These questions aren't a pot shot at you or JBoss or AOP - they're serious concerns. If they can do it without a big impact, great. If it's going to slow down the JVM, or increase memory consumption, or bump off more worthwhile things, then why bother?After all - you and other AOP teams seem to live just fine without these things today :-) -Mike

And I'll answer again. Many of us have already researched and/or implemented these features and have an idea of the effect on performance.

1) Pluggable load-time transformers will not affect performance or memory footprint. JMangler and AspectWerkz have to hot-swap java.lang.ClassLoader to get the functionality. JBoss microkernel extends URLClassLoader to apply transformers. It should be built into the VM and you should not have to jump through hoops to allow for it. JRocket VM supports transformers (AFAIK). Also, there is no reason what-so-ever that JSR-175 should be limited to a code generation enabler. Bytecode manipulation at load time can be fast and efficient. We've been dynamically generating CMP 2.0 Entity Bean implementations at runtime for years.

2) Dynamic annotations would not effect performance or memory footprint if you do not use the feature(and it doesn't in JBoss AOP). It would be nice if this was part of the VM, mainly for Serialization/Remoting issues. With JBoss-AOP I cannot serialize per-instance metadata if the remote VM is not running JBoss-AOP or has not done the necessary classfile transformations to enable it. We have found per-instance metadata very useful in our aspect implementations. Go read AOP research or get on the aosd.net mail list to find out why per-instance metadata is so important.

3) Full HotSwap may effect performance as HotSpot may have already done inlining and such. Should be solvable for VM developers. Ask Jonas Boner, but it looks like the JRockit team is investigating it. A large percentage of JBoss users need hot-deployment. A percentage of those have stateful services they would like to hot-deploy.

4) Full dynamic AOP would probably require an in-memory database of class relationships. This in-memory database would probably also be useful for debuggers. Take a guess, how large would this database in memory be? A couple of megabytes for large applications? that is cheap. If you do not need the feature, don't use it. Have a switch to turn it off. The thing is, the VM knows about these relationships, the VM is the natural place to get information about these relationships. The VM is the best place to track and obtain information about these relationships. We are sponsoring some research on this and the AspectWerkz team is investigating it as well. So we'll see... I also was down on full dynamic AOP (see my blog) until I found that JRockit was enabling Hot Swap in their VM. We can at least now test the viability of it.

Bill

yeah right.
Beta 2 is coming out late may, and now they are telling me that the beta for 1.6 is coming out a couple of months later.

This article is a *hoax*, and even people within Sun is trying to figure out what the heck happened.

- Kasper

I assume you have contacts inside Sun. If this is true, it is shocking that Sun would let this kind of thing slide without a formal response.

Hi,

I must say that I had the same impression when I saw this post. The timing between releases is not so short usually.

Regards,
Sebastien.

Hi,I must say that I had the same impression when I saw this post. The timing between releases is not so short usually.Regards,Sebastien.

Yes, the timeframe is too steep. They might be under competitive pressure from m$ & c# though.

Anybody who knows more please let us know!

Just saw this in JavaLobby:
http://www.javalobby.com/thread.jspa?messageID=91794900&threadID=12184&forumID=61

Quote:
"I hate to tell you this, but I think there is a lot of confused information in that article. When J2SE 1.6 beta dates and features are announced you'll see a much larger announcement. Don't expect to see 1.6 beta this fall."

Cheers,
Mark

Java 1. 6 will include support of design by contract to the Eiffel style?