RFR: JDK-8244093 Move all IDE support into coherent structure in make directory
bradford.wetmore at oracle.com
Wed May 6 23:40:59 UTC 2020
On 4/30/2020 12:28 AM, Jan Lahoda wrote:
> Hi Brad,
> 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
>> 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
> as well.
Hmmm...I'll have to try that next time.
>> 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.
This works for me, because I know about it. But for newbies, it's not
always obvious. There was talk about removing JDK_FILTER a while ago,
but it's incredibly useful to avoid excess builds. Glad it's still here.
When I get a few minutes, I'll try to update/resend my semi-annual email
with the latest info.
>> 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 well.
>>> 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