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