[PATCH FOR APPROVAL]: ReflectiveOperationException missing from FILES_java.gmk

[Andrew John Hughes]

2009/8/7 Kelly O'Hair <Kelly.Ohair at 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