New issue
Advanced search Search tips

Issue 7843 link

Starred by 8 users

Issue metadata

Status: AwaitingInformation
Merged: issue 7347
Owner: ----
Components:



Sign in to add a comment

Gerrit 2.14.5.1 fails to start with Java version above 8

Project Member Reported by geminica...@gmail.com, Nov 27 2017

Issue description

Affected Version:
Gerrit 2.14.5.1

What steps will reproduce the problem?
1. install JRE 9 
2. perform gerrit init
3. upon successful init try starting Gerrit

What is the expected output?
Gerrit starts

What do you see instead?
Garrit fails to start with the following error in error_log:
[2017-11-27 08:27:08,321] [main] ERROR com.google.gerrit.pgm.Daemon : Unable to start daemon
java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getProcessCpuTime() accessible: module jdk.management does not "opens com.sun.management.internal" to unnamed module @7098b907
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(Unknown Source)
	at java.base/java.lang.reflect.Method.checkCanSetAccessible(Unknown Source)
	at java.base/java.lang.reflect.Method.setAccessible(Unknown Source)
	at com.google.gerrit.metrics.proc.OperatingSystemMXBeanProvider.<init>(OperatingSystemMXBeanProvider.java:56)
	at com.google.gerrit.metrics.proc.OperatingSystemMXBeanProvider.<init>(OperatingSystemMXBeanProvider.java:24)
	at com.google.gerrit.metrics.proc.OperatingSystemMXBeanProvider$Factory.create(OperatingSystemMXBeanProvider.java:41)
	at com.google.gerrit.metrics.proc.ProcMetricModule.procCpuUsage(ProcMetricModule.java:72)
	at com.google.gerrit.metrics.proc.ProcMetricModule.configure(ProcMetricModule.java:40)
	at com.google.gerrit.metrics.proc.MetricModule$1.start(MetricModule.java:36)
	at com.google.gerrit.lifecycle.LifecycleManager.start(LifecycleManager.java:92)
	at com.google.gerrit.pgm.Daemon.start(Daemon.java:323)
	at com.google.gerrit.pgm.Daemon.run(Daemon.java:232)
	at com.google.gerrit.pgm.util.AbstractProgram.main(AbstractProgram.java:61)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at com.google.gerrit.launcher.GerritLauncher.invokeProgram(GerritLauncher.java:204)
	at com.google.gerrit.launcher.GerritLauncher.mainImpl(GerritLauncher.java:108)
	at com.google.gerrit.launcher.GerritLauncher.main(GerritLauncher.java:63)
	at Main.main(Main.java:24)

Please provide any additional information below.
java -version
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
 
Note that gerrit does not yet officially support java 9.

InaccessibleObjectException is new in java 9, so until we are able to compile against java 9 we can't handle this exception explicitly.

As a workaround we might be able to catch a generic Exception at the place where InaccessibleObjectException gets thrown.
Cc: dborowitz@google.com
CC dborowitz

I saw in a recent review that you're running Gerrit on Java 9.  I guess you didn't run into this issue because you're using a different metrics implementation?

Project Member

Comment 3 by dborowitz@google.com, Nov 27 2017

We aren't running Java 9 in production yet but we've done some tests with it. But yeah, either way, we don't use this metrics implementation.

I don't know anything about this code but ISTM it's due to internal changes in the com.sun.* classes, and it'll have to be rewritten for Java 9.
Project Member

Comment 4 by logan@google.com, Nov 27 2017

Components: Backend
Project Member

Comment 5 by geminica...@gmail.com, Dec 4 2017

Further notes:
1. running init/index returns 'just' warnings and overall works

2. however one needs to tune up container.javaOptions in order to start Gerrit under java9 - the following option needs to be added:

--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
Project Member

Comment 6 by thomasmu...@yahoo.com, Dec 4 2017

log4j does not support java 9, whereas log4j2 (2.10.0) does.

Im updating log4j here https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
I think for 2.14.x we should simply state that Java 9 is not supported.  Offering workarounds with java options is probably not good enough, particularly if we have dependency libs that also don't work well with java 9.

> log4j does not support java 9

A link to back up this statement would be useful:

https://blogs.apache.org/logging/entry/moving_on_to_log4j_2

From that link:

> Essentially the MDC depends on the Java version string, which does not play well with Java 9's new version-string format.

The question now is whether we want to block 2.15 until it's java 9 ready?

Project Member

Comment 8 by geminica...@gmail.com, Dec 5 2017

So far I haven't noticed any glitches with running gerrit with java9 in regards to logging... I am not saying that we should state that java9 is supported though :)
Tested installing gerrit-2.14.8 on Ubuntu-18.04

gerrit@Gondolin:~/www/gerrit/logs$ java -version
openjdk version "10.0.1" 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

Problem with this remains. Guess an upgrade to java-10 is what we need.

Also see: "WARN  com.google.gerrit.sshd.SshDaemon : Cannot format SSHD host key [EdDSA]: invalid key type"

> Also see: "WARN  com.google.gerrit.sshd.SshDaemon : Cannot format SSHD host key [EdDSA]: invalid key type"


This is a known issue, tracked as issue 6505
Cc: -dborowitz@google.com
Mergedinto: 7347
Status: Duplicate (was: New)
Status: New (was: Duplicate)
 Issue 7347  has been merged into this issue.
Project Member

Comment 14 by david.os...@gmail.com, May 2

> Problem with this remains. Guess an upgrade to java-10 is what we need.

What do you mean by this?
Project Member

Comment 15 by gertvdijk@gmail.com, May 2

I guess what's meant in comment #9:

Ubuntu 18.04, the latest LTS release, comes with OpenJDK 10 as default JRE (via package default-jre) and does not have 9 available. It still has OpenJDK 8 available, though (package: openjdk-8-jre).
Summary: Gerrit 2.14.5.1 fails to start with Java version above 8 (was: Gerrit 2.14.5.1 fails to start with Java9)
Per the mailing list [1] the issue also occurs with Java 10.

[1] https://groups.google.com/forum/#!topic/repo-discuss/l9SHN6WZMGM
Project Member

Comment 17 by david.os...@gmail.com, May 15

Status: AwaitingInformation (was: New)
I think that all problems are solved here.

All you need is to pass the same JVM parameters like in this CL: [1]. Note that all tests are passing with Java 9 there.

See:

https://gerrit-review.googlesource.com/#/c/gerrit/+/147234/13/tools/bzl/junit.bzl@75

"-Djava.locale.providers=COMPAT,CLDR,SPI",
"--add-modules java.activation",
"--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"

[1] https://gerrit-review.googlesource.com/#/c/gerrit/+/147234/
Project Member

Comment 18 by gertvdijk@gmail.com, Aug 16

I noticed the documentation about installation and release notes all mention "Java 8 or newer" still. To avoid confusion for new users on Ubuntu 18.04 like in  Issue 9561 , I've some changes to adjust the Documentation accordingly.

https://gerrit-review.googlesource.com/q/topic:%2522issue7843%2522+owner:%2522Gert+van+Dijk%2522

(I did not consider the workaround by David Ostrovsky feasible for end users at this time.)

HTH
Project Member

Comment 19 by gertvdijk@gmail.com, Aug 19

 Issue 9561  has been merged into this issue.
Project Member

Comment 20 by gertvdijk@gmail.com, Sep 16

Are these JVM options a long-term solution/requirement or are changes planned that we don't need them any longer?

(We could always add stuff to gerrit.sh, but I mean the raw parameters passed.)
Project Member

Comment 21 by david.os...@gmail.com, Sep 16

These parameters are a long term solution. One idea is to add them during init site process to gerrit.config file.
Project Member

Comment 22 by david.os...@gmail.com, Sep 20

Sign in to add a comment