IBM SDK, Java Technology Edition, V8: Beta Program, latest news and information

The beta program provides licensed access to the latest IBM SDK for Java 8 beta. The content of the beta and any supporting documentation is subject to this Disclaimer.

Highlights
Known changes, issues, and limitations
Oracle content

This release information covers all platforms that are provided for the beta. Documentation is available only in the English language. For a draft set of user guides and supporting API documentation, see IBM SDK, Java Technology Edition, V8 Library.

A new beta download is available (April 2013).

---

Highlights

The following features are available in this beta:

Multitenancy feature

The multitenancy feature allows multiple applications to share certain aspects of a single JVM instance, which reduces the requirement for system resources such as memory and processing power. You can take advantage of this new capability without any modification to existing applications. For this release of the beta, support is included for multitenancy, only when running on Linux with an AMD64/EMT64 platform architecture.

Packed Object Support

Packed object support is provided, for Linux IA-32 and z/OS® 31-bit operating systems only, as a technology preview. The Packed Object support feature is an experimental enhancement to the IBM J9 Virtual Machine that allows greater control over the layout of objects in memory. This capability enables greater flexibility when dealing with non-Java memory structures, for example, serializing objects or when performing inter-language communication between Java code and other languages or environments. The feature also enables the optimization of some patterns of Java objects to reduce overall size and improve the access efficiency.

Data Access Accelerator

Data Access Accelerator (DAA) is a high performance data marshalling, conversion and arithmetic library that handles a range of non-primitive and primitive Java types. The library operates directly on raw byte arrays, which removes the requirement for intermediate processing. By working in concert with the Just-In-Time compiler, your application can use available hardware acceleration, while remaining platform-independent. Typical use-cases for this feature include:
• accelerating inter-language communication
• data marshalling operations
• non-primitive arithmetic, for example: packed decimal

Enhancements to the JVM dump API

You can specify dump file names when triggering dumps at runtime. You can also set and query JVM dump options using the API.

Improvements to JVM dump information

The ENVINFO section of a javadump includes information about the operating system hypervisor, if present. A new line also shows the ID of the operating system process that produced the javadump.

Checking system dump settings

On AIX and Linux you can now request that the JVM checks operating system dump settings when the JVM starts. Warnings are issued if system dumps might be truncated.

New trace messages

There are improvements to the diagnostics trace component. A set of new messages is now available to support problem diagnosis.

---

Known changes, issues, and limitations

The following apply:

JavaFX application launcher

This feature is added in Oracle JEP 153. However, JavaFX is not currently supported by the IBM SDK for Java V8. An error occurs if you attempt to run a JavaFX application from the command-line.

Data Access Accelerator

The JIT optimizations to exploit hardware acceleration for the Data Access Accelerator ( com.ibm.dataaccess) package are currently applied in the following scenarios:
1. All public methods in the com.ibm.dataaccess.ByteArrayMarshaller class and the com.ibm.dataaccess.ByteArrayUnmarshaller class are JIT optimized on Windows, Linux on IA-32, Linux on System Z, and z/OS.
2. Only public packedDecimal from/to Primitive conversion methods in the com.ibm.dataccess.DecimalData class are JIT optimized on z/OS.
3. Only public packedDecimal arithmetic and comparison methods in the com.ibm.dataaccess.PackedDecimal class are JIT optimized on z/OS.
The remaining public API methods in the Data Access Accelerator package are currently not JIT optimized; use of these methods will not have a hardware-supported performance boost.

Security

For this release of the beta code, the following limitations apply:
• You cannot use Kerberos with SSL, SASL, or SPEGNO.
• You cannot run SSL/TLS and turn on the security manager unless you add the following permission to your java.security configuration file:
  java.util.PropertyPermission com.ibm.jsse2.checkUndecrypta read
• You might also see errors if you are using the hwkeytool utility program on the z/OS operating system.

JRIO (z/OS)

The JRIO function was deprecated in IBM SDK for Java 7 and is removed from Java 8. As an alternative, use the record I/O facilities that are provided in the JZOS component.

Annotation Processing Tool (APT)

The APT tool was deprecated in Java 7 and is removed from the SDK in Java 8. This tool is superseded by the Pluggable Annotation Processing API (JSR269).

Java plug-in, Applet view and Webstart

For this release of the beta code, these functions are not available.

Java Communications API

For this release of the beta code, this function is not available.

Behavior change for method java.nio.ByteBuffer.allocateDirect(int)

Direct byte buffers are no longer allocated on a page boundary. Any applications that rely on the earlier undocumented alignment can revert to the previous behavior with -XX:+PageAlignDirectMemory.

Behavior change for class loading

By default, the JVM forces synchronization on a class loader that is not a parallel capable class loader during class loading. This action occurs even if the loadClass() method for that class loader is not synchronized. To revert to the earlier behavior in Java 7, use the -XX:-VMLockClassLoader option, described in the Command-line options section of the draft Java 8 user guide.

Uninstalling the SDK or JRE on Linux

On some Linux distributions, the uninstall process fails to remove all of the files. You must manually remove the files from the target installation directory.

Documentation launchpad

The documentation launchpad utility, present in the IBM SDK for Java V7 code package, is removed from V8.

Issue with PackedObjects

When using PackedObjects in a RMI Client or Server based application, with custom or user defined PackedObjects classes, you might see a ClassNotFoundException for the custom or user defined classes, similar to the sample exception stack trace. This is due to a known issue in the PackedObjects code.

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.IOException: java.lang.ClassNotFoundException: PackedPrimitives
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:358)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(AccessController.java:314)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:774)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:275)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at RemoteJRMPImpl_Stub.doCustom(Unknown Source)
                at DummyClient.main(DummyClient.java:31)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.IOException: java.lang.ClassNotFoundException: PackedPrimitives
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:315)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(AccessController.java:314)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:774)
Caused by: java.io.IOException: java.lang.ClassNotFoundException: PackedPrimitives
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2036)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1940)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1823)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1397)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:402)
at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:325)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:312)
... 10 more
Caused by: java.lang.ClassNotFoundException: PackedPrimitives
at java.lang.Class.forName(Class.java:190)
at com.ibm.jvm.packed.ReaderFactory$AbstractReader.readClassDesc(ReaderFactory.java:114)
at com.ibm.jvm.packed.ReaderFactory$SimplePackedReader.readPackedObject(ReaderFactory.java:177)
at com.ibm.jvm.packed.PackedObjectSupport.readPackedObject(PackedObjectSupport.java:116)
at com.ibm.jvm.packed.PackedObjectSupport.readPackedObject(PackedObjectSupport.java:98)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2033)
... 16 more

Note: In the example stack trace, PackedPrimitives is a user defined PackedObject class.

To work around the problem, add the path where the custom or user defined classes exist to the bootclasspath using the option:
-Xbootclasspath/a:<path>

For example:
java -Xbootclasspath/a:/home/user/packedclasses -XX:+PackedObject <application-class>

Issue with ORB remote marshalling

When applications use ORB to make remote calls, you might see OutOfMemoryError or fragment time out errors. These issues are observed when testing ORB remote marshalling under stress conditions. The cause is a contention in the Java compiler tool while generating classes at run time.

The following errors might be seen:

01:33:48.236 com.ibm.rmi.io.SerializerCreator createSerializer:183 ClientThread-88 ORBRas[default]  org.omg.CORBA.INTERNAL: Unable to generate serializer class  vmcid: 0x0  minor code: 0  completed: No
at com.ibm.rmi.io.SerializerCreator.createSerializer(SerializerCreator.java:180)
at com.ibm.rmi.io.SerializerFactoryImpl.createSerializer(SerializerFactoryImpl.java:79)
at com.ibm.rmi.io.ObjectStreamClass.getSerializer(ObjectStreamClass.java:1815)
at com.ibm.rmi.io.IIOPOutputStream.simpleWriteObjectInternal(IIOPOutputStream.java:525)
at com.ibm.rmi.io.IIOPOutputStream.simpleWriteObjectLoop(IIOPOutputStream.java:558)
at com.ibm.rmi.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:640)
at com.ibm.rmi.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:171)
at com.ibm.rmi.iiop.CDRWriter.write_value(CDRWriter.java:814)
at com.ibm.rmi.iiop.CDRWriter.write_value(CDRWriter.java:832)
at com.ibm.rmi.iiop.EncoderOutputStream.write_value(EncoderOutputStream.java:532)
at com.ibm.rmi.iiop.ClientRequestImpl.write_value(ClientRequestImpl.java:893)
at com.ibm.rmi.iiop.CDRWriter.writeAnyOpt(CDRWriter.java:505)
at com.ibm.rmi.iiop.EncoderOutputStream.writeAnyOpt(EncoderOutputStream.java:480)
at com.ibm.rmi.iiop.ClientRequestImpl.writeAnyOpt(ClientRequestImpl.java:869)
at com.ibm.CORBA.iiop.UtilDelegateImpl.writeAny(UtilDelegateImpl.java:380)
at javax.rmi.CORBA.Util.writeAny(Util.java:97)
at tests.com.ibm.jtc.services._TestService_Stub.doEcho(_TestService_Stub.java:37)
at tests.com.ibm.jtc.client.ClientT.run(ParallelClient.java:386)
at java.lang.Thread.run(Thread.java:837)
Caused by: java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap space
at com.sun.tools.javac.main.Main.compile(Main.java:553)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:129)
at com.ibm.rmi.io.SerializerCreator$CompileAction.run(SerializerCreator.java:491)
at java.security.AccessController.doPrivileged(AccessController.java:280)
at com.ibm.rmi.io.SerializerCreator.createSerializer(SerializerCreator.java:177)

01:23:03.602 com.ibm.CORBA.iiop.ServerDelegate dispatch:555 WT=1 ORBRas[default] doEcho__java_lang_Object org.omg.CORBA.NO_RESPONSE: Request 108:fragment timed out  vmcid: IBM  minor code: B02 completed: Maybe
at com.ibm.rmi.iiop.Connection.getNextFragment(Connection.java:2639)
at com.ibm.rmi.iiop.IIOPInputStream.getNextBuffer(IIOPInputStream.java:353)
at com.ibm.rmi.iiop.CDRReader.availableData(CDRReader.java:351)
at com.ibm.rmi.iiop.CDRReader.alignAndCheck(CDRReader.java:338)
at com.ibm.rmi.iiop.CDRInputStream.read_octet_array(CDRInputStream.java:425)
at com.ibm.rmi.iiop.CDRInputStream.<init>(CDRInputStream.java:262)
at com.ibm.rmi.iiop.EncoderInputStream.<init>(EncoderInputStream.java:183)
at com.ibm.rmi.corba.TypeCodeInputStream.<init>(TypeCodeImpl.java:2803)
at com.ibm.rmi.corba.TypeCodeImpl.read_value_body(TypeCodeImpl.java:1748)
at com.ibm.rmi.corba.TypeCodeImpl.readTypeCode(TypeCodeImpl.java:1663)
at com.ibm.rmi.corba.TypeCodeImpl.readTypeCode(TypeCodeImpl.java:1675)
at com.ibm.rmi.iiop.CDRReader.readAnyOpt(CDRReader.java:532)
at com.ibm.rmi.iiop.EncoderInputStream.readAnyOpt(EncoderInputStream.java:721)
at com.ibm.CORBA.iiop.UtilDelegateImpl.readAny(UtilDelegateImpl.java:425)
at javax.rmi.CORBA.Util.readAny(Util.java:109)
at tests.com.ibm.jtc.services._SimpleService_Tie.doEcho__java_lang_Object(_SimpleService_Tie.java:92)

To avoid this problem, set the following system property when you start the JVM:
-Dcom.ibm.CORBA.UseSchema=false

Go back to top

Oracle content

The SDK provided is functionally equivalent to the Oracle FCS version of Java 8 b80.
This release of the SDK includes the following Oracle enhancements:

• DocTree API JEP 105
• Add Javadoc to javax.tools JEP 106
• Charset improvements JEP 112
• Improve Locale Data Packaging and Adopt Unicode CLDR Data JEP 127
• BCP 47 Locale Matching JEP 128
• Unicode 6.2 JEP 133
• Base64 Encoding and Decoding JEP 135
• Launch JavaFX Applications JEP 153
• DocLint JEP 172

Note: JavaFX is not supported by the IBM SDK for Java

Go back to top

Disclaimer

Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Go back to top