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

-kto

Reply via email to