NoSuchMethodError: Matcher.quoteReplacement

Jack Bates 3b5hkp at
Thu Jan 22 17:37:18 UTC 2015

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/
>>>>>> An exception has occurred in the compiler (1.7.0_71_bootstrap). Please
>>>>>> file a bug at the Java Developer Connection
>>>>>> (  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:
>>>> and here is the build log:
>>>> 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:
>> 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/ 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:

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:

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 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 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 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 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!

More information about the distro-pkg-dev mailing list