Compiling some project fails due to ambiguous Record class name

Brian Goetz brian.goetz at oracle.com
Mon Jan 6 19:30:17 UTC 2020


For the record, this is one of two open issues regarding this superclass:

1.  The name.  As has been noted, there is nontrivial chance for 
clashing.  In Preview/2 we might consider changing this to something 
less likely to clash (though some damage will have been done), such as 
to `RecordClass`.

2.  Interface vs abstract class.  It has been noted that we want to 
preserve the possibility to have inline records in Valhalla, and we've 
gone back and forth a few times about whether inline classes can extend 
(suitably restricted) abstract classes.  We are waiting for guidance 
from the Valhalla effort on this.

On 1/6/2020 1:44 PM, Alex Buckley wrote:
> The release note JDK-8236439 doesn't say how to make the existing 
> source file compile, so I went looking for a CSR that surely! must 
> have recorded the source incompatibility of "reserving" the simple 
> type name Record. However, the CSR for JDK-8225054 "Compiler 
> implementation for records" is silent on the impact of auto-importing 
> java.lang.Record, and there is no CSR at all for JDK-8227113 
> "Specification for java.lang.Record". (Vicente may recall we discussed 
> this in November on an internal thread "Auto-import of preview APIs in 
> java.lang when --enable-preview is off?")
>
> I edited the release note for clarity and to mention the use of a 
> single-type import to reference a pre-existing type called Record.
>
> Alex
>
> On 1/2/2020 8:47 AM, Vicente Romero wrote:
>> yes this will be mentioned in 14's release notes,
>>
>> Thanks,
>> Vicente
>>
>> On 1/1/20 6:29 AM, Tagir Valeev wrote:
>>> Hello!
>>>
>>> Probably it's quite expected, but I'm reporting this just for the
>>> case. We are trying to build some opensource projects just using the
>>> Java 14. One of our test projects is univocity-parsers [1]. When I try
>>> to compile it with Java 14 (without even preview option) I see 57
>>> compilation errors like this:
>>>
>>> .../univocity-parsers/src/main/java/com/univocity/parsers/common/AbstractWriter.java:[711,22] 
>>>
>>> reference to Record is ambiguous
>>> both interface com.univocity.parsers.common.record.Record in
>>> com.univocity.parsers.common.record and class java.lang.Record in
>>> java.lang match
>>>
>>> This project defines a class
>>> com.univocity.parsers.common.record.Record and often imports it using
>>> import com.univocity.parsers.common.record.*;
>>>
>>> Thus, the import becomes ambiguous. This could be fixed by rewriting
>>> the imports manually (our IDE doesn't provide an easy way to automate
>>> this). I wonder how many projects could be affected by this problem.
>>> The 'Record' type name is quite common. In any case, this problem
>>> should be mentioned in Java 14 migration notes.
>>>
>>> With best regards,
>>> Tagir Valeev.
>>>
>>> [1] https://github.com/uniVocity/univocity-parsers
>>



More information about the amber-dev mailing list