2009/8/7 Kelly O'Hair <kelly.oh...@sun.com>: > > > Andrew John Hughes wrote: >> >> 2009/8/7 Kelly O'Hair <kelly.oh...@sun.com>: >>> >>> Joseph D. Darcy wrote: >>>> >>>> Andrew John Hughes wrote: >>>>> >>>>> When java.lang.ReflectiveOperationException was added in: >>>>> >>>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/aaf0cb20646e >>>>> >>>>> it wasn't added to make/java/java/FILES_java.gmk. Although it still >>>>> seems to end up in rt.jar when building with IcedTea as the bootstrap >>>>> JDK, it fails when using gcj+ecj (which we use in a full bootstrap). >>>>> >>>>> Is there any reason not to explicitly add the file like the others, >>>>> rather than relying on the compiler to do so (or not as the case may >>>>> be)? >>>>> >>>>> There's a webrev here: >>>>> http://cr.openjdk.java.net/~andrew/roe/webrev.01/ with the 1 line fix. >>>>> >>>> Hmm, curious. Yes, it does seem the file belongs be on the list in >>>> FILES_java.gmk; the new class is a superclass of some of the exception >>>> classes on the list so it gets pulled in, at least by javac. >>>> >>>> However, I'm a bit surprised at the use of such a list in the current >>>> build. >>>> >>>> Kelly, I thought specifying files was generally done at a >>>> package/directory level now? What kind of files need to go into >>>> FILES_java.gmk? >>> >>> I added in an AUTO setting option to the Makefiles where you could just >>> list packages and the Makefile logic would just get the full list of >>> files automatically (using find on all the source areas). >>> But not all the Makefiles were converted to this mechanism. >>> When I did convert a Makefile, I'd usually delete the retired >>> FILES_java.gmk file. The make/java/java builds were not so simple. >>> >>> The one line fix is fine, but I'd prefer to get rid of the explicit >>> list someday. >>> >>> -kto >>> >>>> -Joe >> >> Ok, if someone can allocate me a Sun bug ID for it, I'll push the fix :) >> >> I think generally it would be nice to combine some of these javac >> calls and that might be the solution for java/java which crosses >> multiple packages. One of the reasons OpenJDK builds take so long >> seem to be because it invokes javac a lot, in some cases for only a >> couple of files. Thus, each new invocation is not taking advantage of >> any code that was JITed in the last run. It's also why a native build >> of ecj outperforms javac+HotSpot significantly. > > Yup. I agree. One of the primary reasons ant build scripts are so much > faster, as long as they avoid fork=true and exec tasks. ;^) > > I'll file a bug for you: > > 6869697: Missing entry in makefiles for > java/lang/ReflectiveOperationException.java >
Great, thanks. Pushed: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/88229bdd8aae > -kto > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
