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