RFC: Only enable NIO2 by default when building with IcedTea
Andrew Haley
aph at redhat.com
Wed Feb 11 05:01:47 PST 2009
Matthias Klose wrote:
> Andrew Haley schrieb:
>> Andrew John Hughes wrote:
>>> It appears that some older versions of ecj fail when building the
>>> NIO2 code:
>>>
>>> 1. ERROR in ../../../src/share/classes/org/classpath/icedtea/java/nio/file/spi/AbstractPath.java (at line 276)
>>> public final WatchKey register(WatchService watcher, WatchEvent.Kind<?>... events)
>>> throws IOException
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Name clash: The method register(WatchService, WatchEvent.Kind<?>...) of type AbstractPath has the same erasure as register(WatchService, WatchEvent.Kind<?>...) of type Watchable but does not override it
>>> ----------
>>>
>>> It looks like this bug:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=243820
>>>
>>> The attached patch sets the NIO2 default based on whether with_icedtea is enabled. So this works,
>>> and to be consistent with the rest of the autotools macro, it switches the values used from true/false
>>> to yes/no.
>>>
>>> Okay to commit?
>> Would it not make more sense to:
>>
>> 1. require a newer version of ecj in our build documentation
>>
>> and
>>
>> 2. tell people that if they have an old ecj they'll have to diable NIO2
>
> documenting the requirement sounds fine.
>
> For distributing ecj I am interested in one version which can be used to build
> ecj1 and a vanilla ecj which is used as standalone compiler, or javac for
> java-gcj-compat. Last time I checked an update to the next ecj-3.3.x release
> didn't work well for libgcj. I'll try to check the ecj-3.4.2 release and see
> how/if this works when used as ecj1. Are there any patches available for
> ecj-3.4.2 to build it as ecj1?
I have seen none, but I can't imagine it'd be hard.
Andrew.
More information about the distro-pkg-dev
mailing list