Updated: Using the Netbeans IDE to work on JDK library development
Bradford Wetmore
bradford.wetmore at oracle.com
Fri Jun 14 23:06:03 UTC 2019
[This updates an earlier version of this document from a couple years ago.]
Apache's Netbeans 11 has progressed to the point where
developing/debugging JDK 13/14 library builds (exploded and image) is
now quite usable with a couple of add-ons. Debugging my latest project
was actually quite enjoyable.
Please understand: I'm not a Netbeans power user, I'm just sharing what
has worked for me in hopes this might save you some time. There are
always better ways of doing things.
1. Build a JDK to debug.
1a. If you're in Oracle and want to use jib and closed source,
clone/configure the current source from the closed/open repositories:
% hg clone <closed_source> jdk
% cd jdk
% bash ./get_source.sh (clones corresponding open repo)
% bash jib.sh configure -- \
--with-default-make-target=jdk ...other options...
1b. If you're external to Oracle, clone/configure the source from the
open repository:
% hg clone http://hg.openjdk.java.net/jdk/jdk jdk
% cd jdk
% bash configure \
--with-default-make-target=jdk ...other options...
2. Build the JDK:
% cd build/linux-x64
% make
3. Download Apache NetBeans (incubating 11.0 version).
https://netbeans.apache.org/
% unzip incubating-netbeans-11.0-bin.zip
If you are using Windows, you'll need to make the .exe/.dll bits executable:
% cd netbeans*
% find . -type f -name '*.exe' -exec chmod +x {} \;
% find . -type f -name '*.dll' -exec chmod +x {} \;
Be sure to have a recent JDK build for netbeans_jdkhome. If NB can't
find a JDK in your path, you can hardcode it in etc/netbeans.conf:
netbeans_jdkhome="/java/bootdirs/jdk-12.0.1"
It was also recommended to me to have lots of initial memory:
netbeans_default_options="-J-Xms2048m ..."
3. Start NetBeans:
% bin/netbeans # Solaris/Linux/MacOS/etc.
% bin/netbeans64.exe # Windows
4. Install Jan Lahoda's (Oracle JDK/Netbeans) "JDK Project for
NetBeans" plugin, and "JTReg Support" if you are using JTReg.
. In Tools->Plugins menu go to Settings
. Update proxy if needed.
. Click Add button
. In the URL paste:
http://lahoda.info/hudson/job/nb-jdk-project/lastSuccessfulBuild/artifact/build/updates/updates.xml
. In Configuration of Update Centers, enable the 8.2 plugins Center.
. In the Available Plugins tab, install:
. JDK Project for NetBeans
. JTReg Support
. nb-javac
. You can also click “Check for Newest” in "Updates" tab in case
your NetBeans install is out of date.
Restart NetBeans.
5. Add your JDK 13/14 exploded build as a Java Platform:
. Tools->Java Platforms->Add Platform
/export/home/me/build/linux-x64/jdk
. Pick a platform name. Do not add sources, they will be
found by the JDK Project (above and below).
(gensrc/shared/platform/closed)
. Finish
6. Navigate to and open the Java module directories you'll be using. e.g.
/export/home/me
jdk/src/java.base
jdk/src/jdk.crypto.ec
The module sources for debugging the platform will be found in these
open modules.
The very first time you open a module, it may take a couple minutes to
scan through everything (source/binary/etc). Restarts are faster after
things are cached.
7. Next, depending on whether you'll debug a standalone app or a JTREG
test from the test directories:
7a. Standalone: create a test project app as normal, then select the
JDK platform.
. Right click on project, select Properties.
. Choose libraries, select the platform you just created.
7b. JTREG: In the module you opened (above), navigate to the jdk test
directory. e.g.
${jdkRoot}/jdk/test
Then select the exact test you want to run, then "Debug->Debug Test
File". It takes a little while to load, and there is some
System.out/System.err weirdness: System.err is delivered much later than
System.out, or even lost if the app exits quickly.
NOTE WELL: The JTReg plugin understands the JTReg directives, however
(currently) debugging a JTReg test will trigger a remake of the
entire(!) JDK platform. Turn this behavior off by right clicking on the
java.base module, then "properties", then set "Never" to the question of
"Build before running tests."
It will take a while to scan through the test directories
(source/binary/etc). Restarts are faster as things are cached.
8. Set a break point in your app(s) and start debugging. You should be
able to "Step In (F7)" to the JDK library code.
I have been successfully able to debug multi-process client/server code
by setting breakpoints in both the client and server code, then "Debug
Project" each project.
9. If you make any changes (think/edit/compile) to your JDK code, I
suggest stopping the debugger(s), then use a separate window to do the
make. For a simple rebuild of the Java classes in javax/net/ssl +
sun/security/ssl, I do:
# cwd: build/*-normal-server-fastdebug
% make LOG=debug \
JDK_FILTER=javax/net/ssl,sun/security/ssl \
java.base-java-only # or java.base-only
Netbeans will notice any changes and reload as needed. Then restart the
debugger.
10. If you use an external editor to edit your code, any breakpoints
might get confused. e.g. if you have a breakpoint on line 51, and
externally you add a line, Netbeans won't realize that the breakpoint
should be on line 52. If you edit within Netbeans, this doesn't happen.
I would like to make a wiki page with this info at some point, so if you
have any comments, let me know.
Good luck,
Brad
More information about the jdk-dev
mailing list