RFR: JDK-8244093 Move all IDE support into coherent structure in make directory
jan.lahoda at oracle.com
Thu Apr 30 07:28:00 UTC 2020
This is very similar to what I do. Some small comments inline.
On 29. 04. 20 21:02, Bradford Wetmore wrote:
> What is your current recommended technique to use NetBeans to
> build/edit/test OpenJDK for normal OpenJDK library developers?
> After many versions of Netbeans, my current setup is to:
> 1. Do an external "exploded" build
> 2. Run Netbeans, open the src/java.base module project and any other
> modules needed.
> 3a. For OpenJDK test files under test/jdk: Open the java.base test dirs
> for the JTREG tests I need. Then run "Debug Test File" to invoke JTREG
> 3b. For tests not in test/jdk (external to repo):
> 1. Add a Java platform for the exploded-build
I believe a platform for the exploded build should be added
automatically when the project is opened. Its name is
"<the-checkout-directory>-<configuration>", e.g. "jdk -
linux-x86_64-server-release". If deleted, this platform should be
re-created on next start/project open. But creating one manually works
> 2. Create a project, assign the platform
> 3. Create standard Debug project.
> 4. For incremental builds, edit source file, build from the command
> line something like:
> % make JDK_FILTER=java/security java.base-java-only
If there is something that could help here, please let me know. I am
peeking a little at possibilities to speed up incremental build (so that
plain "make" would be faster), but not much success so far.
> Is there another way of working I'm missing?
> Things have been really solid for me lately (OpenJDK/JTREG plugins not
> needed), thanks for all your hard work on this.
Thank you for your support!
> On 4/29/2020 4:06 AM, Jan Lahoda wrote:
>> I am not sure if anyone is still using make/jdk/netbeans. Apache
>> NetBeans does not (should not) need these config files, it supports
>> OpenJDK modules out of the box (with some tweaks/dependencies on
>> make/langtools/** to speed up langtools build).
>> As Maurizio, there may be some need to move the "fast" langtools build
>> more carefully. I'll try to take a look later, unless some else wants
>> to. Although, a little independently, I wonder somewhat if there's an
>> opportunity to further speed up the ordinary make build in incremental
>> environment to reduce the need for a "fast" langtools build. E.g. by
>> enhancing the current Depend javac plugin, and possibly optionally
>> disabling the interim langtools build. This could improve incremental
>> build behavior for other modules (like java.base or java.desktop) as
>> On 29. 04. 20 12:36, Magnus Ihse Bursie wrote:
>>> The IDE support in OpenJDK unfortunately leaves a lot to be desired.
>>> There have been a garden variety of attempt to support a specific IDE
>>> for a specific part of the code base, cluttered all over the code base.
>>> This patch is a first attempt go get one ring, eh..., structure, to
>>> rule them all.
>>> I have moved all IDE project creators into the following structure:
>>> make/ide/<ide>/<part of the code>
>>> where <part of the code> is one of currently "hotspot", "langtools"
>>> or "jdk", and <ide> is one of "vscode", "idea", "netbeans" or
>>> This will not magically improve IDE support, but will at least make
>>> it clearer what we have and what we are missing.
>>> Ownership of the IDE support is notoriously vague. I've cc:ed a bunch
>>> of people who has shown interest and/or submitted fixes to some of
>>> the IDE projects according to the hg history. I'd appreciate it if
>>> anyone who is interested in a particular case for IDE support can
>>> verify that it still works. I've tried my best to make sure all
>>> targets can run without errors, but I cannot verify that the IDE
>>> environment themselves are correct.
>>> If you know about an IDE project that is no longer relevant, and
>>> should be removed instead of shuffled around, please let me know!
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8244093
More information about the ide-support-dev