IBM SDK for Java Version 6 beta version available

Discussions

News: IBM SDK for Java Version 6 beta version available

  1. IBM is releasing an SDK for Java 6 and is sponsoring an Early Release Program to gather feedback from the Java community. Product binaries and documentation are available for Linux on x86 and 64-bit AMD, and AIX for PPC for 32- and 64-bits. In addition to supporting the Java SE 6 Platform specification, IBM's SDK also focuses on platform stability, performance, and diagnostics. Download requires membership in developerWorks. Some new features include: Data sharing between Java Virtual Machines (JVMs): Building on the new class-sharing technology in Java V5.0 SDK, Java 6 allows more than just class data to be shared between JVMs. The code for methods compiled during JVM startup can be cached to improve the startup time for another JVM. Also, a Java API is provided so that any byte data (images, XML etc) can be shared between JVM processes. Both of these features are designed to allow multiple JVMs running similar code to share as much common data as possible, significantly reducing overall memory footprint. Enhanced diagnostics information: For the Java 6 SDK, the Java Diagnostics and User Guides are being updated to provide accuracy and ease of use. A new documentation Launchpad will direct you to diagnostics and API documentation. Guides are also being made available on the web where they can be searched by your favorite search engines. Operating system stack backtraces: Javadumps and console dumps now contain a stack trace down to the operating system level. This helps diagnose problems in JNI applications. Updated jdmpview tool: The jdmpview tool has been updated to use DTFJ. Using DTFJ removes some limitations from the tool (such as having to run initialization commands) and provides more diagnostics information in many areas. You can post comments, feedback, and questions on IBM's SDK on the Early Release Program forum.
  2. Data sharing[ Go to top ]

    Hello, the data sharing is also working in time of running of JVM? That means that 2 JVM can communicate and share data to each other? With help of this new features I can create parallel application? Thanks, Peter
  3. Re: Data sharing[ Go to top ]

    ...the data sharing is also working in time of running of JVM? That means that 2 JVM can communicate and share data to each other? With help of this new features I can create parallel application?
    Well, I can't say for sure, because the docs aren't clear and I haven't done any thorough examination. (Perhaps some enterprising IBMer will chime in.) I think, however, that it's talking about sharing code segments, not data segments. For data segments, well... look at Terracotta DSO, GigaSpaces, Coherence, or something similar. Again, I could be utterly, completely wrong.
  4. Re: Data sharing[ Go to top ]

    Speaking not as an enterprising IBMer but just someone else who read the initial posting, I got the impression it's intended to reduce disk I/O and overall system memory footprint for programs running in more than one JVM that read the same static data from disk. For example a group of image files, audio files, and so on. Rather than each process keeping its own instance of this data in memory, the first process to read it in pays the I/O penalty and the subsequent processes point to the in-memory location without reading it from disk. Allowing the JVMs to modify data in the shared area would bring in the same synchronization/locking and remote data streaming issues that the aforementioned caching solutions have to address. Randy
  5. Data sharing among JVMs[ Go to top ]

    Interesting...if that is the case, I wonder how IBM's own product ObjectGrid would fit into this? Would they use aforementioned APIs instead of their existing connectivity with remote JVM? Also, interesting to see how it will change roadmaps & strategy of distributed cache frameworks like Coherence, JCS...
  6. who cares?
  7. who cares?
    Lots of people who are on IBM systems or PowerPC systems do care. Ok many issues people had in the past now are addressed by opensourcing the JDK (finally you can make a decent jdk port on BSD) but lots of people here are on AS400 or AIX systems, and they definitely do care. I just wished that JDK 1.4 finally would become history. It is still widely used and will be used for a long time, and it drags everything down progresswise.
  8. I just wished that JDK 1.4 finally would become history. It is still widely used and will be used for a long time, and it drags everything down progresswise.
    While I don't really mind JDK 1.4 (it's a decent platform in many respects), I'll cheer about the day when *JDK 1.3* finally becomes history! Some things stick around for much longer than you'd expect... After all, JDK 1.4 was released in 2002 already, and Sun has officially end-of-lifed JDK 1.3. Still, there a quite a few JDK 1.3 deployment platforms out there: essentially all WebSphere platforms pre 5.1, plus some WebLogic pre 7.0 users... Those are all about to upgrade in the meantime, based on what I hear from our users, so I expect 2007 to be the year that allows our mindset to shift to JDK 1.4+! On the occasion, a little anecdote: The most extreme case that we experienced in that respect was a guy deploying Spring 2.0 M4 on WebSphere *3.5*!! The funny part is that, in general, things worked fine for him! All he requested was the use of an old JavaMail 1.1 signature in Spring's JavaMailSenderImpl code, to be able to work with the age-old JavaMail that was included in WebSphere 3.5... Read the full (short) story, having happened as recently as March 2006 :-) http://opensource.atlassian.com/projects/spring/browse/SPR-1822 As for JDK 1.4 staying around (in deployment) for an even longer time, probably at least for 2 further years: That is certainly a safe assumption. The most recent numbers that I heard indicated about 50/50 for JDK 1.4/1.5 in deployment. That's already a significant improvement over the 10/60/30 for JDK 1.3/1.4/1.5 that we had less than a year before! Juergen (Spring Team)
  9. I feel your pain Jurgen. ObjectGrid supports 1.3 or higher right now but we're moving up to 1.4.2 lowest level with the next release. The next release uses Java 5 annotations etc but we have to hold back on generic use to keep the same jar compatible with both 1.4 and 1.5. Bit of a pain but we didn't want to jars with different interfaces for 1.4 and Java 5. Its a shame there is no way to have a generic Java 5 interface that when used on 1.4 becomes a non generic interface of same shape.
  10. I guess on thinking about this more, the data sharing, every JVM has this already, no? You can use memory mapped files with direct mapped buffers and essentially get the same behavior, right? I'll try pinging someone on the JVM team and blog it later.
  11. I feel your pain Jurgen. ObjectGrid supports 1.3 or higher right now but we're moving up to 1.4.2 lowest level with the next release. The next release uses Java 5 annotations etc but we have to hold back on generic use to keep the same jar compatible with both 1.4 and 1.5. Bit of a pain but we didn't want to jars with different interfaces for 1.4 and Java 5.
    Hey Billy, partner in pain ;-) Actually, we've been happily supporting JDK 1.3+ for a long time (up until the Spring 2.0.x branch), and been supporting old API versions (in particular Servlet 2.2) for an equally long time. It worked quite well for us: We were able to support a lot of JDK 1.5 specific features in Spring 1.2 and 2.0 already, including annotations and generics introspection. The only limitation is the lack of generics in the Spring API itself, similar to what you outlined for ObjectGrid. That said, at some point, we need to move on - but not too far, since we still have a large user base on JDK 1.4 (and will be having it for some time to come)! So for Spring 2.1, we plan to introduce dedicated JDK 1.6 support, as well as to raise the required JDK level to 1.4. The latter became necessary since a lot of third-party libraries move to JDK 1.4+ these days, including API jars such as JCA 1.5 and JavaMail 1.4. The required J2EE level will remain at 1.3, just without J2EE 1.2 (Servlet 2.2) fallbacks then. Juergen
  12. who cares?


    Lots of people who are on IBM systems or PowerPC systems do care.
    Ok many issues people had in the past now are addressed by opensourcing the JDK (finally you can make a decent jdk port on BSD) but lots of people here are on AS400 or AIX systems, and they definitely do care.

    I just wished that JDK 1.4 finally would become history. It is still widely used and will be used for a long time, and it drags everything down progresswise.
    And I just wished IBM would start making more admin- and developer-friendly software. Just try and let Websphere 5 run under their JDK 5 or 6... In my opinion their only reason to still be such a big number in the J2EE business are their really deep pockets and a big name. But gladly there are enough alternatives out there... thanks to open source!
  13. How is the debugging?[ Go to top ]

    Is the debugging even more improved? (its already MUCH better then suns java5/6 compared to ibm's java5 so if ibm even made advancements in that again that would be great, like complete class redefinition?) Also if i download this version. Are the SDK (yes Source Development Kit, not Runtime Environment) classes compiled with full debug info or not? Because that is the thing i find so strange with all the JDK/SDK downloads (Sun or IBM) why not have full debug info in the classes when i download a JDK/SDK? With java6 i just download the rt.jar from dev.java.net (which is still a bit older (1 buuld) i guess then the real final..) But it is so cumbersome..
  14. Re: How is the debugging?[ Go to top ]

    I still can't understand why IBM marketing doesn't allow their Windows JDKs to be made available. Grmblfxncs...