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