Building langtools on MacOS fails with ClassReader.java:911: reference to Version is ambiguous
Reinier Zwitserloot
reinier at zwitserloot.com
Sun Dec 12 21:22:12 PST 2010
Dalibor,
could you elaborate on what this patch does? To clarify Maurizio's comments,
*ALL* apple VMs released in the past 4 years (and probably all those before,
but that's when I started checking) do not operate with rt.jar and
tools.jar, instead they bundle them into one as "Classes.jar". As Maurizio
explained, this whole thing (rt+tools) becomes the bootclasspath and thus
you can put javac.jar or any such variants on the classpath as much as you
like, the bootclasspath javac always wins. One solution is to put your own
build of javac in front (java -Xbootclasspath/p:javac.jar), but this isn't
always an option.
One way around this issue is to build your own OpenJDK on a non-apple JDK,
such as soy latte or a binary Mac Os X OpenJDK distro. These work as
expected and split rt.jar and tools.jar, and don't put tools.jar on the
(boot)classpath by default.
I'm interested in what kind of patch Dalibor came up with. Is it a universal
fix for apple's unfortunate choice to put tools.jar on the bootpath?
--Reinier Zwitserloot
On Thu, Dec 9, 2010 at 4:12 PM, Dalibor Topic <dalibor.topic at oracle.com>wrote:
> On 12/8/10 10:49 PM, Jacek Laskowski wrote:
> > build-bootstrap-javac:
> > [javac] Compiling 297 source files to
> > /Users/jacek/oss/lambda-langtools/build/bootstrap/classes
> > [javac]
> /Users/jacek/oss/lambda-langtools/src/share/classes/com/sun/tools/javac/jvm/ClassReader.java:911:
> > reference to Version is ambiguous, both class
> > com.sun.tools.javac.jvm.ClassFile.Version in
> > com.sun.tools.javac.jvm.ClassFile and class
> > com.sun.tools.javac.util.Version in com.sun.tools.javac.util match
> > [javac] AttributeReader(Name name, Version version,
> > Set<AttributeKind> kinds) {
> > [javac] ^
> > [javac]
> /Users/jacek/oss/lambda-langtools/src/share/classes/com/sun/tools/javac/jvm/ClassReader.java:924:
> > reference to Version is ambiguous, both class
> > com.sun.tools.javac.jvm.ClassFile.Version in
> > com.sun.tools.javac.jvm.ClassFile and class
> > com.sun.tools.javac.util.Version in com.sun.tools.javac.util match
> > [javac] final Version version;
> > [javac] ^
> > [javac] 2 errors
>
> Could you try the attached patch?
>
> cheers,
> dalibor topic
>
>
>
> --
> Oracle <http://www.oracle.com>
> Dalibor Topic | Java F/OSS Ambassador
> Phone: +494023646738 <tel:+494023646738> | | | Mobile: +491772664192
> <tel:+491772664192>
> Oracle Java Platform Group
>
> ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Rijnzathe 6, 3454PV De Meern, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
>
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
>
>
>
>
More information about the lambda-dev
mailing list