JDK-4819896 : rmic dependency on oldjavac must be removed
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 5.0,7
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: generic,solaris_8
  • CPU: generic
  • Submitted: 2003-02-18
  • Updated: 2024-04-12
  • Resolved: 2017-07-20
Related Reports
Duplicate :  
JDK-7014793 - sun.tools.javac message files localization not included in tools.jar
Relates :  
JDK-6473331 - rmic does not use manifest classpath
Relates :  
JDK-4633413 - Remove old javac source code and binaries
Description
The packages sun.tools.asm, sun.tools.tree, sun.tools.javac, and sun.tools.java
will be removed in Tiger.  rmic uses some of these classes, and so the needed
classes must be copied into the rmic area and the packages renamed.  rmic will
likely have to be refactored and/or partially rewritten to remove the
dependence on the old compiler.

Due to incompatibilities between the generics compiler and the 1.2-era
oldjavac internals, the following JCK tests will fail until this is
completed:

in compiler-15
api/java_rmi/rmic/stub11/TestRemote6/index_Primitive.jtr 
api/java_rmi/rmic/stub12/TestRemote6/index_SeveralArgs.jtr 
api/java_rmi/rmic/stub11/TestRemote6/index_Combined.jtr 
api/java_rmi/rmic/skel/TestRemote6/index_SeveralArgs.jtr 

Note that there may be a real problem generating stubs for methods
that have been defined using covariant returns.  It would be impossible
in Java source to define both methods (the method and its bridge method)
because they have the same name and argument types.  I don't know what
the solution should be for rmic, but this issue definitely requires
some thought.  It would be unfortunate if rmic never works with classes
(such as java.util.Collection) that uses covariant returns.

###@###.### 2003-07-14
Comments
Closing as Won't Fix, as this is not a priority now. If that changes, this can be re-opened, or a new issue filed.
20-07-2017
EVALUATION Committing to Tiger and lowering priority so that it falls off mantis radar... ###@###.### 2003-03-03 We have been considering this bug to specifically represent the task of having rmic use its own versions of the oldjavac classes, given that they can no longer exist in their current sun.tools locations (practically, they will be moved to a package within the rmic implementation package hierarchy). Just doing that, however, does not address the shortcomings of the oldjavac code given evolution of the language and class file format in Tiger-- such as the issue recently added to the Description of this bug report. That particular issue has been filed as a separate bug, 4892308. See also 4892314. ###@###.### 2003-07-17 As described above, with the view that this bug simply represents the need for the rmic implementation to use its own versions of the oldjavac classes, this bug is fixed along with 4633413 (removing the oldjavac implementation from its current package location). ###@###.### 2003-08-05 The fix integrated for this CR was backed out from Tiger because of 4926127; recommitting for Mustang. The Mustang fix will probably be to make the new implementation of rmic (see 4911536) the default (and only) implementation, as long as the IIOP/IDL back end for the new implementation is ready. ###@###.### 2004-11-24 01:28:22 GMT Retargetting for Dolphin because the IIOP/IDL back end for the new rmic implementation will not be ready for Mustang. This CR is associated with jplan features 363 and, by reference, 288: http://jplan.sfbay/feature/363 http://jplan.sfbay/feature/288 See 4633413 for the separate CR of simply repackaging the oldjavac classes (to in effect "remove" them), now still committed for Mustang. ###@###.### 2005-06-21 21:05:35 GMT
21-06-2005
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b15 VERIFIED IN: tiger
14-06-2004
PUBLIC COMMENTS ...
10-06-2004