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

[Andrew John Hughes]

2009/8/7 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
>
> Andrew John Hughes wrote:
>>
>> 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.
>
> 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