United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6790292 BOOTDIR of jdk6 u12 will not work with jdk7 builds
JDK-6790292 : BOOTDIR of jdk6 u12 will not work with jdk7 builds

Details
Type:
Bug
Submit Date:
2009-01-06
Status:
Resolved
Updated Date:
2010-04-03
Project Name:
JDK
Resolved Date:
2009-03-24
Component:
infrastructure
OS:
generic
Sub-Component:
build
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:

Related Reports
Backport:
Duplicate:
Relates:

Sub Tasks

Description
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.

The errors:

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.

                                    

Comments
SUGGESTED FIX

diff --git a/make/common/Rules.gmk b/make/common/Rules.gmk
--- a/make/common/Rules.gmk
+++ b/make/common/Rules.gmk
@@ -197,8 +197,8 @@ classes : $(CLASSES_INIT) .delete.classl
          $(ECHO) "# Java sources to be compiled: (listed in file $(JAVA_SOURCE_LIST))"; \
          $(CAT) $(JAVA_SOURCE_LIST); \
          $(ECHO) "# Running javac:"; \
-         $(ECHO) $(JAVAC_CMD) -sourcepath "$(SOURCEPATH)" -d $(CLASSDESTDIR) @$(JAVA_SOURCE_LIST); \
-         $(JAVAC_CMD) -sourcepath "$(SOURCEPATH)" -d $(CLASSDESTDIR) @$(JAVA_SOURCE_LIST); \
+         $(ECHO) $(JAVAC_CMD) -Xprefer:source -sourcepath "$(SOURCEPATH)" -d $(CLASSDESTDIR) @$(JAVA_SOURCE_LIST); \
+         $(JAVAC_CMD) -Xprefer:source -sourcepath "$(SOURCEPATH)" -d $(CLASSDESTDIR) @$(JAVA_SOURCE_LIST); \
        fi
        @$(java-vm-cleanup)
                                     
2009-01-06
WORK AROUND

gmake OTHER_JAVACFLAGS=-Xprefer:source ...
                                     
2009-01-06
EVALUATION

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.
                                     
2009-01-06
EVALUATION

http://hg.openjdk.java.net/jdk7/build/corba/rev/53d5b45f73ab
                                     
2009-03-12



Hardware and Software, Engineered to Work Together