The bug fix for 6714797 that was integrated into B01 of jdk6u12 has introduced some new abstract interface methods to some corba interfaces. Although the corba changes seem to be in the latest glassfish versions.
When the jdk7 corba repository is built against these newer interface class files, the corba build is failing, not sure why it's not using the classes from it's own build.
src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java:95: com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl is not abstract and does not override abstract method closeConnectionResources() in com.sun.corba.se.spi.transport.CorbaConnection
src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java:41: com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl is not abstract and does not override abstract method close() in java.io.Closeable
src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolManagerImpl.java:36: com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolManagerImpl is not abstract and does not override abstract method close() in java.io.Closeable
src/share/classes/com/sun/corba/se/impl/transport/CorbaInboundConnectionCacheImpl.java:49: com.sun.corba.se.impl.transport.CorbaInboundConnectionCacheImpl is not abstract and does not override abstract method close() in com.sun.corba.se.pept.transport.ConnectionCache
src/share/classes/com/sun/corba/se/impl/transport/CorbaOutboundConnectionCacheImpl.java:50: com.sun.corba.se.impl.transport.CorbaOutboundConnectionCacheImpl is not abstract and does not override abstract method close() in com.sun.corba.se.pept.transport.ConnectionCache
Using jdk6u11 or older works fine.
Posted Date : 2009-01-06 01:36:20.0
With some help from Jonathan Gibbons... The issue is that when jdk7 corba is built with a newly installed jdk6u12 which has a newer CorbaConnection interface (that requires a new method), the javac compiler is finding the CorbaConnection in the bootclasspath and is prefering that over the source file in the sourcepath due to it's newer timestamp.
Adding the jdk6 javac option -Xprefer:source fixes this, which tells javac to always prefer the source file found over any class file.
When corba is built (or jaxp or jaxws, or the jdk for that matter) the assumption (goal?) was that it was building the source in it's repository to the destination classes directory of that build. Any binding to the classes in the bootclasspath or classpath was assumed to be acceptable and acceptable. But when the sourcepath contains and alternative version, we need it to bind to the source version, not what is in the classpath or bootclasspath.
The jaxp and jaxws repositories use an ant script, and effectively there is one javac compilation, so all the source of the repository is built at one time, so the binding between sources happens naturally.
The jdk repository overrides the bootclasspath to be just the classes directory being created, so it never binds to the classes in the bootclasspath.
So this is a corba specific issue, due to it's use of makefiles where it builds parts of the corba repository in separate phases, and it's sources not being the prefered classes to bind with. The jdk6 option -Xprefer:source can fix this, and will probably be implemented unless a better solution comes up. Ultimately, the whole way the corba source or classes get into the jdk needs to change.
Posted Date : 2009-01-06 22:03:25.0
Posted Date : 2009-03-12 04:52:56.0
Submitted On 02-DEC-2009
ehm hm.. just for anyones interest;
i get the same error when trying to build openjdk6 bootstrapped with apple's jre/vm1.5
for more info, and/or reply see:
vike2000 at gmail
peace n gnite
PLEASE NOTE: JDK6 is formerly known as Project Mustang