JDK 9 RFR of JDK-8071959: java.lang.Object uses implicit default constructor

Joel Borggrén-Franck joel.franck at oracle.com
Fri Jan 30 19:58:27 UTC 2015


Hi

Good question, but javac should be fine. I had to look it up, but there is logic to omit super() when generating the default ctor for Object (TypeEnter::DefaultConstructor), and also logic for omitting super() if we are compiling an explicit ctor for Object (Attr::visitMethodDef).

Looks good Joe, perhaps you could do a boot-cycle build just to be on the safe side?

cheers
/Joel
. 
> On 30 jan 2015, at 15:52, Peter Levart <peter.levart at gmail.com> wrote:
> 
> On 01/30/2015 01:02 AM, joe darcy wrote:
>> Hello,
>> 
>> Please review the patch below to fix
>> 
>>    JDK-8071959: java.lang.Object uses implicit default constructor
>> 
>> diff -r 458adf31ad5b src/java.base/share/classes/java/lang/Object.java
>> --- a/src/java.base/share/classes/java/lang/Object.java    Thu Jan 29 15:14:44 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/Object.java    Thu Jan 29 16:00:03 2015 -0800
>> @@ -42,6 +42,11 @@
>>     }
>> 
>>     /**
>> +     * Constructs a new object.
>> +     */
>> +    public Object() {}
>> +
>> +    /**
>>      * Returns the runtime class of this {@code Object}. The returned
>>      * {@code Class} object is the object that is locked by {@code
>>      * static synchronized} methods of the represented class.
>> 
>> At present, java.lang.Object relies on the default constructor generated by javac; how embarrassing!
>> 
>> Thanks,
>> 
>> -Joe
> 
> Is javac able to compile it correctly? It never had to do that before (it inserted an implicit one instead). I guess the constructor in Object is special, since it does not call a super constructor.
> 
> Peter
> 




More information about the core-libs-dev mailing list