RFR (S) 8073550 : java* tools: replace obj.getClass hacks with Assert.checkNonNull or Objects.requireNonNull
Jonathan Gibbons
jonathan.gibbons at oracle.com
Fri Feb 27 01:34:08 UTC 2015
Looks good to me.
-- Jon
On 02/26/2015 03:13 AM, Maurizio Cimadamore wrote:
> New patch and delta diff against previous patch. All test pass.
>
> Thanks
> Maurizio
>
> On 26/02/15 01:14, Maurizio Cimadamore wrote:
>>
>> On 26/02/15 00:43, Jonathan Gibbons wrote:
>>>
>>> On 02/25/2015 04:25 PM, Maurizio Cimadamore wrote:
>>>>>
>>>>> 3. In general, we should not depend on the javac internal Assert
>>>>> mechanism outside of javac.
>>>> Uh - ok. Not sure I fully buy this - i.e. javadoc reuses 99% of
>>>> javac so I'm not sure what buys us not to use Assert mechanism
>>>> there...
>>>
>>> The com.sun.tools.classfile library is currently stand-alone,
>>> totally separate from javac. It has even been backported into JDK
>>> 6. It seems wrong/unnecessary to introduce a new dependency on a
>>> minor javac utility class.
>>>
>>> In separate, somewhat unrelated discussions, we have talked about
>>> doing more with the javac Assert mechanism, and possibly recording
>>> more of the execution environment, in a somewhat more formalized
>>> way. That would likely depend on support code in the javac Main
>>> program, where we catch and handle all the exceptions that might
>>> come out of the javac internals. javadoc does not share/reuse that
>>> part of javac.
>>>
>>> Separately, the ongoing cleanup of the javac doclet API (JEP 221:
>>> http://openjdk.java.net/jeps/221) will significantly reduce
>>> javadoc's need to access javac internal API. So, it's good to keep
>>> the dependencies down.
>> Good - will clean those up
>>
>> Maurizio
>>>
>>> -- Jon
>>
>
More information about the compiler-dev
mailing list