NoSuchMethodError: Matcher.quoteReplacement

[Jack Bates]

On 21/01/15 02:30 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 13/01/15 08:45 AM, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> On 12/01/15 05:28 PM, Andrew Hughes wrote:
>>>>> ----- Original Message -----
>>>>>> I get the following error when I try to build 2.5.3:
>>>>>>
>>>>>> [...]
>>>>>> /home/nottheoilrig/icedtea-2.5.3/generated.build/com/sun/corba/se/impl/logging/UtilSystemException.java
>>>>>> An exception has occurred in the compiler (1.7.0_71_bootstrap). Please
>>>>>> file a bug at the Java Developer Connection
>>>>>> (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade
>>>>>> for duplicates. Include your program and the following diagnostic in
>>>>>> your report.  Thank you.
>>>>>> java.lang.NoSuchMethodError: method
>>>>>> java.util.regex.Matcher.quoteReplacement with signature
>>>>>> (Ljava.lang.String;)Ljava.lang.String; was not found.
>>>>>> [...]
>>>>>>
>>>>>> Any idea how to resolve it?
>>>>>> Can I provide any additional details?
>>>>>> I downloaded the IcedTea 2.5.3 archive,
>>>>>> ran ./configure and make.
>>>>>>
>>>>>> The following are lines from my config.log,
>>>>>> are they helpful?
>>>>>>
>>>>>> [...]
>>>>>> configure:11304: checking if java.util.regex.Matcher.quoteReplacement is
>>>>>> missing
>>>>>> configure:11354: result: yes
>>>>>> [...]
>>>>>> configure:11820: checking if the VM supports 1.7 bytecode
>>>>>> javac: invalid source release: 7
>>>>>> Usage: javac <options> <source files>
>>>>>> use -help for a list of possible options
>>>>>> configure:11850: result: no
>>>>>> configure:11866: checking whether to disable the use of bootstrap tools
>>>>>> for bootstrapping
>>>>>> configure:11890: result: yes
>>>>>> [...]
>>>>>
>>>>> It's difficult to say much without the full config.log and build log.
>>>>
>>>> Thank you,
>>>>
>>>> here is the config.log:
>>>> http://nottheoilrig.com/java/201501120/config.log
>>>>
>>>> and here is the build log:
>>>> http://nottheoilrig.com/java/201501120/screenlog
>>>>
>>>> Can I provide any additional details?
>>>
>>> This is sufficient, thanks. The main problem is your setup is just too old.
>>> It's about time this machine was upgraded to wheezy, as squeeze is
>>> obsolete.
>>> Moreover, wheezy already includes a build of 2.5.3 which will save you
>>> the trouble: https://packages.debian.org/wheezy/openjdk-7-jdk
>>
>> Yes, I'm only building from source because upgrading
>> this machine isn't an option in the near future
>> (although I'm working on it).
>
> Ok.
>
>>> The actual problem is a bit convoluted. From the logs, I can see that a
>>> very
>>> old version of gcj, 4.4, is being used to bootstrap the build. This is why
>>> many features are found to be missing when your bootstrap JDK is tested
>>> during
>>> configure.
>>>
>>> The quoteReplacement method is missing in gcj 4.4, and there is a test to
>>> work around this in configure; if you look for the rt-class-files part
>>> of the build log, you will see it builds
>>> openjdk-boot/jdk/src/share/classes/java/util/regex/Matcher.java before the
>>> OpenJDK build begins, so a version with quoteReplacement is available.
>>>
>>> All would be fine, thanks to this fix, but your javac (provided by gcj) is
>>> too old to build Java 1.7 source code so the use of it to build is
>>> disabled.
>>> It instead tries to use the javac it just built and fails because it needs
>>> the missing method.
>>
>> Hrm, actually javac is provided by OpenJDK 6, but I guess that doesn't
>> change a thing because it's also too old to build Java 1.7 source code?
>
> It is, but that's not the issue; the issue is a combination of gcj both
> not handling 1.7 source code and missing java.util.regex.Matcher.quoteReplacement.
> OpenJDK 6 doesn't suffer from the latter.
>
>> config.log:
>> JAVAC='/usr/bin/javac'
>>
>> $ ls -l /usr/bin/javac
>> /usr/bin/javac -> /etc/alternatives/javac
>> $ ls -l /etc/alternatives/javac
>> /etc/alternatives/javac -> /usr/lib/jvm/java-6-openjdk/bin/javac
>>
>> So it tries to use the javac it just built (bootstrap javac?) and fails.
>> What I don't understand is,
>> with --with-jdk-home=/usr/lib/jvm/java-6-openjdk it works!
>> It uses the same javac (/usr/lib/jvm/java-6-openjdk/bin/javac)
>> with and without --with-jdk-home but it works with, and fails without.
>
> No, the old logs were using javac from gcj.

Maybe it's irrelevant, but here are the old logs:
http://nottheoilrig.com/java/201501120/config.log
http://nottheoilrig.com/java/201501120/screenlog

What indicates that javac is from GCJ?
/usr/lib/jvm/java-gcj/bin/java is from GCJ
however GCJ javac is not installed on this machine.

 From the old logs:
[...]
JAVA='/usr/lib/jvm/java-gcj/bin/java'
JAVAC='/usr/bin/javac'
[...]

Furthermore both /usr/bin/java and /usr/bin/javac are OpenJDK 6:

/usr/bin/java -> /etc/alternatives/java
/usr/bin/javac -> /etc/alternatives/javac

/etc/alternatives/java -> /usr/lib/jvm/java-6-openjdk/jre/bin/java
/etc/alternatives/javac -> /usr/lib/jvm/java-6-openjdk/bin/javac

>> Another question:
>> It determines that GCJ 4.4/OpenJDK 6 are too old to build Java 1.7
>
> Just GCJ 4. It was completely ignoring OpenJDK 6.
>
>> source code, so it builds the bootstrap javac (right?)
>> and it determines that the environment is missing quoteReplacement
>> so it builds and uses Matcher.java to build the bootstrap javac,
>> but then why does the bootstrap javac later fail?
>> If the bootstrap javac is also missing quoteReplacement,
>> then why build Matcher.java if it's not used?
>> (Or used to build the bootstrap javac but not to build the rest?)
>> Is there a case where the environment is missing quoteReplacement
>> but the bootstrap javac isn't?
>> (Maybe Matcher.java is irrelevant and obsolete, like this machine?)
>
> It could be, and that's what I considered as a potential fix for the
> original failure. The problem is that changing the build could break
> builds with other JDKs, and I'm not sure the risk is worth it for
> such a limited use case. Even if you just had GCJ, you could use that
> to build IcedTea 1.x/OpenJDK 6, then build IcedTea 2.x with that.
>
>>> I think it may be possible to fix this by running javac with the patched
>>> runtime on the bootclasspath. However, it's difficult to know without
>>> testing
>>> and changing that may break builds with other JDKs. We test builds with gcj
>>> the most, but not a version this old.
>>>
>>> If you have https://packages.debian.org/squeeze/openjdk-6-jdk installed,
>>> then you could try building with
>>> --with-jdk-home=/usr/lib/jvm/java-6-openjdk
>>> to use that instead. However, I strongly recommend that you just upgrade
>>> this system as the version of OpenJDK 6 is also outdated (1.13.5 is the
>>> latest)
>>> and there are likely to be further missing system dependencies later in the
>>> build that may cause problems, or lead to an incomplete JDK (for example,
>>> NIO2 is likely to be incomplete without certain system calls being
>>> present).
>>
>> --with-jdk-home=/usr/lib/jvm/java-6-openjdk works so far,
>> thanks a lot for your help!
>
> No problem. Thanks for making us aware of the issue!