Java 1.6 to gain multitasking features

Home

News: Java 1.6 to gain multitasking features

  1. Java 1.6 to gain multitasking features (44 messages)

    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?

    Threaded Messages (44)

  2. Java 1.6 to gain multitasking features[ Go to top ]

    This sounds like AppDomains in DotNET.
  3. 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.
  4. Java Operational System?[ Go to top ]

    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
  5. 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.
  6. 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. :-)
  7. I can avoid having to write native code...
    Such fear IMO clearly indicates that Java must be more lightweight and play nicely with rest of the world (C, C++, Py, etc. ) it looks like CLR has advantages here ( at least in theory ).

    Another think to consider: why native code is a BOO for Java people? There is something wrong with that: It was a nightmare to write native code before when we had to put OS specific code here and there so portability of source was a nightmare. Is it so today? Not quite: Linux applications are good example: kernel + POSIX provides consistent API to code against it and gcc shields them from hardware so they are compliable almost everywhere.
    How about binary compatibility? Do we really need it? I do not think so: we tend to use XML/CORBA for intercommunications anyway.
  8. 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.
  9. Java Operational System?[ Go to top ]

    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
  10. More than that....[ Go to top ]

    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.
  11. 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
  12. Java Operational System?[ Go to top ]

    "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?
  13. Java Operational System?[ Go to top ]

    "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".
  14. bytecode sharing[ Go to top ]

    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.
  15. bytecode sharing[ Go to top ]

    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.
  16. bytecode sharing[ Go to top ]

    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
  17. bytecode sharing[ Go to top ]

    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
  18. bytecode sharing[ Go to top ]

    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?
  19. bytecode sharing[ Go to top ]

    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
  20. bytecode sharing[ Go to top ]

    For the curious ones, here's an attempt of an actual JavaOS:
    http://jnode.sourceforge.net/portal/
  21. Linux vs JavaOS[ Go to top ]

    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
  22. 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
  23. Anyone know what "Sockets Direct" is?
  24. 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.
  25. re: Sockets Direct[ Go to top ]

    Thanks for the explanation. Maybe they'll also clean up the horrid nio library.
  26. re: Sockets Direct[ Go to top ]

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

    http://infiniband.sourceforge.net/NW/SDP/overview.htm
  27. What about aspects?[ Go to top ]

    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.
  28. What about aspects?[ Go to top ]

    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.
  29. What about aspects?[ Go to top ]

    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.
  30. What about aspects?[ Go to top ]

    Before adding the latest fad into the language, let's see those features prove themselves in the real world first.
  31. What about aspects?[ Go to top ]

    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
  32. What about aspects?[ Go to top ]

    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
  33. What about aspects?[ Go to top ]

    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!
  34. What about aspects?[ Go to top ]

    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
  35. What about aspects?[ Go to top ]

    <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.
  36. What about aspects?[ Go to top ]

    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
  37. What about aspects?[ Go to top ]

    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
  38. What about aspects?[ Go to top ]

    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
  39. What about aspects?[ Go to top ]

    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
  40. j2sdk 1.6 beta this fall?[ Go to top ]

    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
  41. interesting[ Go to top ]

    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.
  42. j2sdk 1.6 beta this fall?[ Go to top ]

    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.
  43. j2sdk 1.6 beta this fall?[ Go to top ]

    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!
  44. j2sdk 1.6 beta this fall?[ Go to top ]

    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
  45. design by contract[ Go to top ]

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