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

[Kelly O'Hair]

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

-kto