We launch rmic with the -Xnew flag to use the alternative doclet-based stub generator. This works fine from the command line under JDK 5.0 and JDK 6.0-b72; and with the ant rmic task under JDK 5.0. However the ant rmic task crashes when the -Xnew flag is used with JDK 6.0-b72. The error given is "rmic: error - Doclet class sun.rmi.rmic.newrmic.Main does not contain a start method"
I don't think there is any problem with Ant here, Ant invokes the compile method in sun.rmi.rmic.Main, nothing else. Does it work if you run without -Xnew? Could you run rmic from the command line without Ant?
Like I said in the description, it works: - from the command line without -Xnew with JDK5 and JDK6 - from the command line with -Xnew with JDK5 and JDK6 - from ant without -Xnew with JDK5 and JDK6 - from any without -Xnew with JDK5 The only combination that doesn't seem to work is running it from ant with the -Xnew flag under JDK6. I re-verified with JDK6 build 79 and the problem still exists. I know it seems strange, but the problem is 100% reproducible in my environment.
Can you do a full -d stack trace. We need to see if this is something with Ant or java 1.6
Created attachment 18118 [details] ant -d -v output What's "a full -d stack trace"? I've attached the output from ant -d -v rmic. Do you want a stack trace? At which point should I generate one?
Hmmm... ordinarily you wouldn't use -d and -v together. Does -d without -v produce more output? P.S. when your report is marked NEEDINFO, once you provide that info you should pick Reassign to dev@ant.apache.org or it could get lost in the madness.
Created attachment 18125 [details] ant -d output OK thanks. Here is the plain ant -d output. Reassigning to dev.
I do find it interesting that this report is marked with Ant version 1.6.5 despite the fact that the debug output shows Ant 1.6.0. :|
Created attachment 18127 [details] ant -d output OK, here is the ant -d output using ant 1.6.5
Thanks for helping us be sure the problem does indeed affect 1.6.5.
Thanks for the diagnostics. Could you stick in the <rmic> tag used. We should make a unit test for this, regardless of the underlying cause. I note that ant1.7 has a forking adapter that forks rmic into a new process. I suspect (indeed, hope) that this problem will make the error go away. Maybe we should make the default rmic compiler for Java1.6 the forking one if -xnew is set? We could even add a newstub attribute to say 'new stub generator' that could be used as a trigger for this behaviour..
Created attachment 18133 [details] Extract from build.xml Attached my rmic task - nothing complicated at all
This is rather strange. I've added to tests to Ant's tests in SVN, both setting -Xnew, one forking, one not. If I run the corresponding targets directly, I get the behavior Robert describes - but only in the not-forking case. If I run the tests via <junit>, either both fail (when I don't fork JUnit) or both pass (when I fork JUnit). Looks like a classloader issue with Sun's rmic at first glance. It doesn't seem to like it when Ant pulls in tools.jar via the launcher logic.
What are we doing with this? Can we take it up with Sun? Or should we switch to forking rmic on java6.0+
Hello Steve, I think we should do both take it with Sun and fork rmic in JDK 6.0. Sun may or may not fix the problem soon. If we fork rmic in JDK 6.0, then we will have a good workaround in Ant 1.7.0. Afterwards it can change again. This is one of the nice things of ant that it hides or wipes away so of the dissonance between "write once, run everywhere" and the reality. Antoine
If we look at the rmic source http://www.cs.duke.edu/csed/java/source1.5/src/share/classes/sun/rmi/rmic/Main.java we can see that -xnew triggers a load+invoke of sun.rmi.rmic.newrmic.Main, completely bypassing the other bits. What we could do is have a new compiler adapter "xnew" that -uses this as the entry point (or runs classic rmic with -Xnew) -forks on all java versions This would eliminate the need to look for -XNew as an argument to rmic itself, and make management of the problem much less contrived (the alternate is to check for sun && java1.6+ && -XNew in the argument list and switch to the forking compiler)
Ok. committed a new xnew compiler that works on java1.5; not tested on java1.6 Robert, when ant1.7 appears in beta form next week, can you download it and see if the xnew adapter meets your needs?
closing as fixed; if it isnt, feel free to reopen it.
(In reply to comment #16) > Robert, when ant1.7 appears in beta form next week, can you download it and see > if the xnew adapter meets your needs? Sure thing, do you mean I should replace <rmic base="${javaclasses}"> <compilerarg value="-Xnew"/> ... </rmic> with <xnew base="${javaclasses}"> ... </xnew> ?
no, you'd go <rmic base="${javaclasses}" compiler="xnew" > </rmic>
Seems fixed.
reopening this just to add some more comments for searches to turn up. When we run the testXNew test in a recent Java6 update 3 JVM, the XML parser configuration get stamped on : org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.apache.xerces.parsers.SAXParser.(Unknown Source) at org.apache.xerces.parsers.SAXParser.(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:215) at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:172) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:182) at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:138) at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93) at org.apache.tools.ant.BuildFileTest.configureProject(BuildFileTest.java:289) at org.apache.tools.ant.BuildFileTest.configureProject(BuildFileTest.java:272) at org.apache.tools.ant.taskdefs.RmicAdvancedTest.setUp(RmicAdvancedTest.java:44) at junit.framework.TestCase.runBare(TestCase.java:128) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:1327) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:824) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1751) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:774) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:62) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:394) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:354) at org.apache.tools.ant.Target.performTasks(Target.java:379) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1324) at org.apache.tools.ant.Project.executeTarget(Project.java:1293) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1176) at org.apache.tools.ant.Main.runBuild(Main.java:758) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) This is yet another reason not to run the -Xnew compiler unforked under java6.
fixing non forking rmic -Xnew test so that it doesnt run. Since this rmic option doesnt work on java6 anyway, the <rmic> -Xnew option is still broken. marking as wontfix, as users are required to switch to the xnew adapter to get things to work.