This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 86308 - Configure alternate bootclasspath
Summary: Configure alternate bootclasspath
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker with 5 votes (vote)
Assignee: Tomas Zezula
Depends on:
Reported: 2006-10-02 14:34 UTC by cristiandeives
Modified: 2013-12-11 08:27 UTC (History)
1 user (show)

See Also:
Exception Reporter:

Proposed patch for j2seproject (4.57 KB, text/plain)
2008-01-14 04:29 UTC, Rich Unger

Note You need to log in before you can comment on or make changes to this bug.
Description cristiandeives 2006-10-02 14:34:53 UTC
There should be a way to change the bootclasspath of a project (or even for each
Java platform...), instead of using the default one. I want to compile some Java
Card code and I wanted to set the bootclasspath to its corresponding JARs, so
javac doesn't compile my code if I use JSE specific classes.

I think I can do it altering the compiling parameters, on the project's
properties (-bootclasspath ...), but I think there should be a better way of
doing it.
Comment 1 Rich Unger 2008-01-13 20:49:31 UTC
I agree, and I think this is important for supporting things like Android.  I think this would be pretty easy to
implement in j2seproject and the other project types.  We'd need to:

1. Change each project type's build-impl.xsl target "-init-macrodef-javac" to include a bootclasspath option, read from
some optional project property.

2. Read that property also from the  For example, the current code for reads thusly:

        JavaPlatform jp = findActivePlatform ();
        final List<PathResourceImplementation> result = new ArrayList<PathResourceImplementation>();
        if (jp != null) {
            //TODO: May also listen on CP, but from Platform it should be fixed.            
            final ClassPath cp = jp.getBootstrapLibraries();
            assert cp != null : jp;
            for (ClassPath.Entry entry : cp.entries()) {

This entire block should be run only if bootclasspath project property is undefined.  Otherwise, just load from the
Comment 2 Rich Unger 2008-01-14 04:29:22 UTC
Created attachment 55015 [details]
Proposed patch for j2seproject
Comment 3 Rich Unger 2008-01-14 04:32:15 UTC
Turned out to be a really small change :)

With the attached patch, I can add "bootclasspath=/path/to/android.jar" to a project's nbproject/ and
the editor and and scripts will both do the right thing.  Removing the bootclasspath definition causes the project to
act the same way it did without the patch.
Comment 4 Tomas Zezula 2008-01-14 05:53:46 UTC
There is already a property called platform.<name_of_platform>.bootpath which is used for it, unfortunately there is no
UI customization, maybe it will be needed. By the way there is a full featured NetBeans project type for the Android
platform, I will find the site with this module and let you know.
Comment 5 Rich Unger 2008-01-14 06:56:35 UTC
I don't particularly care if there's a GUI for platform.<name_of_platform>.bootpath.  However, even when I change the
property and restart NB, the Java Platform Manager still shows the original rt.jar, etc.

It looks like doesn't take this
property into account.  It always gets its COMPILE classpath using
GlobalPathRegistry.getDefault().getPaths(ClassPath.COMPILE).  Thus, j2seproject's BootClassPathImplementation doesn't
pick up on it.

I may be reading this wrong, though, as I haven't done a deep dive through all the code yet.
Comment 6 thorsten_s 2012-02-15 09:30:20 UTC
I would like to bring some attention to this old issue. Currently no project type seems to support the customization of the bootclasspath. Everyone that attempts to provide a custom bootclasspath would have to reimplement the j2se project type it seems. Or come up with a custom java platform and a plugin that makes NetBeans recognize it. Projects like leJOS and the NBAndroid project had to build a new project type while a bootclasspath configuration would have provided the option to extend the j2se project type instead. From what I understand reading up NetBeans developer information developers should extend project types if possible. But having no control over the bootclasspath is a roadblock for customized Java platforms.
Comment 7 markiewb 2013-12-06 07:12:51 UTC
Related to ?
Comment 8 thorsten_s 2013-12-11 08:27:52 UTC
(In reply to markiewb from comment #7)
> Related to ?

I would say yes. But for JavaSE project type.