Compiling some project fails due to ambiguous Record class name

Alex Buckley alex.buckley at
Mon Jan 6 18:44:35 UTC 2020

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.


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/[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]

More information about the amber-dev mailing list