Using local OpenJDK build as SDK

Answered

Hi,
I have cloned and built (with "make images") a local OpenJDK ("amber" repository). When I try to add the resulting build//images/jdk directory as an SDK, IntelliJIdea does not complain about the directory structure (so it correctly identifies it as a modular JDK), but the Classpath tab is blank, so the resulting configuration is unusable. If I manually add the JDK modules at build//images/jdk/jmods, they show up as ordinary files and are not scanned as module files.
I assume this works for other people, so what am I doing wrong? Wrong build target? Wrong JDK directory? (Note that I am not trying to start IntelliJIdea with an OpenJDK build, just use my local build as a project JDK.)
Thanks,
Robert

6 comments
Comment actions Permalink

Please try with 2017.3 from https://www.jetbrains.com/idea/nextversion/ If does not help, please post content of idea.log file starting from IDE restart and reproducing the problem.

0
Comment actions Permalink

Hi Andrey,

I should have said, I'm already using the latest EAP build.  There is nothing written in the idea.log file when I add an SDK (and no errors on the screen).

The SDK is correctly identified as a JDK 10 build, the Sourcepath is found as build/<platform>/images/jdk/lib/src.zip!/java.se (etc.), but I'm 'just' missing the Classpath

0
Comment actions Permalink

Same problem on both my Windows 7 and OS X (with a clone of the same repository, http://hg.openjdk.java.net/amber). I'll have a look with the utility linked in the bug.

0
Comment actions Permalink

Hi Robert,

I tried to create a JDK from a fresh build of Amber repository, and got the following in the log:

java.io.IOException: Error mounting JRT filesystem at /home/sher/Tools/jdk-amber
    at com.intellij.openapi.vfs.impl.jrt.JrtHandler.getFileSystem(JrtHandler.java:85)
    at com.intellij.openapi.vfs.impl.jrt.JrtHandler.createEntriesMap(JrtHandler.java:97)
    ...
Caused by: java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
    at jdk.internal.jimage.BasicImageReader.slice(BasicImageReader.java:211)
    at jdk.internal.jimage.BasicImageReader.intBuffer(BasicImageReader.java:218)
    at jdk.internal.jimage.BasicImageReader.<init>(BasicImageReader.java:152)
    at jdk.internal.jimage.ImageReader$SharedImageReader.<init>(ImageReader.java:224)
    at jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:238)
    at jdk.internal.jimage.ImageReader.open(ImageReader.java:67)
    at jdk.internal.jimage.ImageReader.open(ImageReader.java:71)
    at jdk.internal.jrtfs.SystemImage.open(SystemImage.java:59)
    at jdk.internal.jrtfs.JrtFileSystem.<init>(JrtFileSystem.java:90)
    at jdk.internal.jrtfs.JrtFileSystemProvider.newFileSystem(JrtFileSystemProvider.java:108)
    at java.nio.file.FileSystems.newFileSystem(FileSystems.java:336)
    at com.intellij.openapi.vfs.impl.jrt.JrtHandler.getFileSystem(JrtHandler.java:80)
    ... 73 more

The problem is the same as in IDEA-179481 - since the IDE is unable to load lib/jrt-fs.jar, it can't enumerate the modules.

Substituting lib/jrt-fs.jar with the one copied from JDK 9 fixes the exception. Unfortunately, a negative result is already cached, so one has to delete the incomplete JDK definition, perform File | Invalidate Caches, and restart the IDE. Adding a JDK should work after that.

0
Comment actions Permalink

Yes, that was it, thanks.  I didn't see the error messages in my log because the bad results were already cached from earlier attempts.

0

Please sign in to leave a comment.