bazel: Java API mismatch when building Gerrit and JGit from source on 0.16.1

To simplify developing process with Gerrit’s main dependency JGit, we support building gerrit with building JGit from source instead of consuming the binary artifacts from Central or from Gerrit’s Google storage bucket.

When building Gerrit in that way on Bazel 0.16.1 generated byte code for JGit is screwed up and the final artifact cannot be run on Java 8 any more. Note, that this error doesn’t show up any more in 0.17rc1, but I would like to make sure, we understand the problem (and the fix). Besides that, 0.16.1 is the latest Bazel stable release so that I think it worth reporting.

Also note, that if we consume JGit from Central and not build it from source, from an external repository on Bazel 0.16.1, then all is fine, and final artifact can be run on Java 8. This is the stack trace we are seeing:

$ bazel build :gerrit
Target //:gerrit up-to-date:
  bazel-bin/gerrit.war
INFO: Elapsed time: 0.694s, Critical Path: 0.22s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action

$ java -jar bazel-bin/gerrit.war init -d ../test_xxx_yyy
Using secure store: com.google.gerrit.server.securestore.DefaultSecureStore
[2018-08-30 07:48:18,819] [main] INFO  com.google.gerrit.server.config.GerritServerConfigProvider : No /home/davido/projects/gerrit2/../test_xxx_yyy/etc/gerrit.config; assuming defaults

*** Gerrit Code Review 2.15.3-4973-g89aa7c7814-dirty
*** 

Create '/home/davido/projects/gerrit2/../test_xxx_yyy' [Y/n]? Y

*** Git Repositories
*** 

Location of Git repositories   [git]: 

*** SQL Database
*** 

Database server type           [h2]: 

*** NoteDb Database
*** 

Use NoteDb for change metadata?
  See documentation:
  https://gerrit-review.googlesource.com/Documentation/note-db.html
Enable                         [Y/n]? Y

*** Index
*** 

Type                           [lucene/?]: 
Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.mark()Ljava/nio/ByteBuffer;
	at org.eclipse.jgit.util.RawParseUtils.decodeNoFallback(RawParseUtils.java:1121)
	at org.eclipse.jgit.util.RawParseUtils.decode(RawParseUtils.java:1087)
	at org.eclipse.jgit.util.RawParseUtils.decode(RawParseUtils.java:1046)
	at org.eclipse.jgit.util.RawParseUtils.decode(RawParseUtils.java:1025)
	at org.eclipse.jgit.storage.file.FileBasedConfig.load(FileBasedConfig.java:173)
	at org.eclipse.jgit.util.FS_POSIX.getAtomicFileCreationSupportOption(FS_POSIX.java:124)
	at org.eclipse.jgit.util.FS_POSIX.determineAtomicFileCreationSupport(FS_POSIX.java:110)
	at org.eclipse.jgit.util.FS_POSIX.supportsAtomicCreateNewFile(FS_POSIX.java:354)
	at org.eclipse.jgit.util.FS_POSIX.createNewFile(FS_POSIX.java:382)
	at org.eclipse.jgit.internal.storage.file.LockFile.lock(LockFile.java:158)
	at org.eclipse.jgit.storage.file.FileBasedConfig.save(FileBasedConfig.java:234)
	at com.google.gerrit.server.index.GerritIndexStatus.save(GerritIndexStatus.java:48)
	at com.google.gerrit.server.index.IndexUtils.setReady(IndexUtils.java:60)
	at com.google.gerrit.pgm.init.InitIndex.run(InitIndex.java:71)
	at com.google.gerrit.pgm.init.SitePathInitializer.run(SitePathInitializer.java:93)
	at com.google.gerrit.pgm.init.BaseInit.run(BaseInit.java:136)
	at com.google.gerrit.pgm.util.AbstractProgram.main(AbstractProgram.java:61)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.google.gerrit.launcher.GerritLauncher.invokeProgram(GerritLauncher.java:224)
	at com.google.gerrit.launcher.GerritLauncher.mainImpl(GerritLauncher.java:120)
	at com.google.gerrit.launcher.GerritLauncher.main(GerritLauncher.java:64)
	at Main.main(Main.java:28)

To reproduce:

diff --git a/lib/jgit/jgit.bzl b/lib/jgit/jgit.bzl
index 6ada5bda7b..ba189f5960 100644
--- a/lib/jgit/jgit.bzl
+++ b/lib/jgit/jgit.bzl
@@ -10,7 +10,7 @@ _JGIT_REPO = MAVEN_CENTRAL  # Leave here even if set to MAVEN_CENTRAL.
 
 # set this to use a local version.
 # "/home/<user>/projects/jgit"
-LOCAL_JGIT_REPO = ""
+LOCAL_JGIT_REPO = "/home/davido/projects/jgit"
 
 def jgit_repos():
     if LOCAL_JGIT_REPO:

And run:

  • bazel build :gerrit

Now try to set-up a gerrit site by running:

  $ java -jar bazel-bin/gerrit.war init -d ../test_xxx_yyy

and accept all suggested defaults would fail with the stack trace mentioned above.

FWIW: OP was reported on repo-discuss mailing list: [1].

My environment:

  $ java -fullversion
  openjdk full version "1.8.0_171-b11"

  $ javac -version
  javac 1.8.0_171

  $ bazel version
  Build label: 0.16.1

  $ echo $JAVA_HOME
  <unset>

[1] https://groups.google.com/d/topic/repo-discuss/d_qGIW0PnpU/discussion

//CC @cushon

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 23 (19 by maintainers)

Commits related to this issue

Most upvoted comments

@cushon : indeed, this is a special case of #5888 .

@gertvdijk: the issue is in fact severe in terms of how broken we are, but it does not meet the bar of “widespread breakage” for a patch release, especially if @laurentlb’s estimate is correct about 0.17 being out next week.

@laurentlb: WDYT? I’m somewhat worried about #6035 throwing a wrench in the works, but it we release 0.17 on September 6 and it works for JGit/Gerrit, let’s not do a patch release.

@davido @gertvdijk : how feasible is it to not update to 0.16.1 for the time being?

@lberki @buchgr @ulfjack

Can you explain Gerrit Code Review and JGit communities, why we are not seeing Patch Release for 0.16.1 for such severe breakage in Bazel latest release, leaving us without a fix for weeks/months?

(Of course, we can build Bazel from source or use 0.17.rc1, but I think the appropriate reaction here is to patch latest release, or alternatively, as adequate reaction immediately promote 0.17rc1 as stable release).