RFR (S) 8073550 : java* tools: replace obj.getClass hacks with Assert.checkNonNull or Objects.requireNonNull

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Feb 27 11:53:44 UTC 2015


Pushed - thanks to Aleksey for contributing the patch and to Jon for 
reviewing it ;-)

Maurizio

On 27/02/15 01:34, Jonathan Gibbons wrote:
> 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