Currently, the IDE requires JDK to run. In NB 6.5, we would like to allow some distributions of the IDE to run on JRE
only - see also related enhancement #127678. To enable this, it is probably necessary to allow modules to specify
whether they require the JDK, or whether JRE is sufficient. This information should also be handled by AutoUpdate - when
the user runs some distribution on JRE and wants to download a module that requires a JDK, this case must be handled. A
similar check may need to be done during IDE startup.
I would rather rephrase the problem. Neither the module system nor AU needs to do anything special. Rather, modules
which have a specific need for some library currently stuffed in tools.jar should bundle that library (or, rather,
depend on a library wrapper module which does). Since the JDK is now open source, this should pose no legal issue.
Fixing this architecture would also greatly simplify JNLP execution of NetBeans. Particular issues which will need to be
filed as children of this issue:
1. The NB launcher must be changed to not expect to be running on a JDK.
2. The installer must be changed to look for JREs, not JDKs.
3. The Ant integration module should have a runtime dep on the existing javacapi & javacimpl modules, and insert those
into Ant's classpath so <javac fork="false"> continues to work. (Or these modules can register themselves as
AntExtraClasspathProvider's.) <javac fork="true"> also needs to be investigated to make sure it still works, but this is
a lower priority as IDE-generated scripts do not use this mode; may suffice for this to just fail unless the user in
fact picked a JDK to run on, or maybe 'javac' needs to be in $PATH, etc.
4. The JPDA debugger module (and some other debugger-related modules TBD) should dep on a new wrapper for JDI.
5. Modules which add tools.jar to test.unit.run.cp.extra, usually so they can run javac during unit tests, should be
fixed to use a test dep on javacapi + javacimpl.
6. jconsole & jmx modules may need to extract & bundle something from tools.jar (TBD).
7. Some web-related modules may need to extract & bundle JAX-WS-related classes (TBD).
8. All other occurrences of 'fgrep tools.jar */nbproject/project.properties' should be categorized and fixed.
I agree this sounds like the right way, but isn't is a bit ambitious for NB 6.5? The ability to run flawlessly NetBeans
via webstart would be great. Though there may be more issues in addition to what you describe:
> tools.jar: Since the JDK is now open source, this should pose no legal issue.
But there has not been a FCS release of the JDK; I think we prefer bundling just FCS jar files. Could this be a problem?
Secondly, GlassFish v2 (which is bundled with the IDE) requires JDK to run (and install). How do we handle this?
3a. Need to check <javadoc>.
JDK 6 is also available as open source now, not just JDK 7 dev. Anyway we are already bundling a (modified) copy of JDK
7's javac and it seems fine.
Glassfish is not a NB module and is not handled by the NB module class loader system. If Glassfish needs a JDK to run or
be installed, then whatever GUI launches this from NetBeans needs to be prepared for the fact that it might need to
search for a suitable JDK, just like any installer would do.
Of course there might be some quicker change that could be done e.g. in the installer alone - assuming that people
installing Ruby or PHP IDEs do not later add the Java feature, or perhaps with some special handling in AU for the Java
feature. What I laid out was a recommendation for the desired architecture that should keep things simplest and most
consistent in the long term and give us the most flexibility.
The module system is not really involved in this. Currently modules such as debuggerjpda do request a "package
dependency" on tools.jar packages such as com.sun.jdi. (Package dependencies are otherwise unused and probably ought to
be deprecated.) This however does nothing to help correct the problem if the app is in fact running on the JRE; it just
means that the user gets a dialog during startup notifying them that the JDK is required, and they can choose to disable
that module, or shut down and fix their launch script by hand. Bundling required libraries directly would obviate the
need for such tricks; everyone running the NB debugger would be using the same pretested copy of the JDI library,
regardless of the JRE/JDK used to launch NB. (The fix for issue #96711 will be useful here.)
Jesse, we discussed the possibility of running only on JRE with debugger, profiler and GUI editor teams. From the
perspective of these functionalities it is not a viable solution to wrap the parts of JDK they depend on. First, it is
hard to isolate smaller parts of tools.jar and dt.jar, second, we cannot safely bundle a snapshot of the needed parts
because we could not guarantee it would work with all supported versions of Java 5 and 6.
I think we need to allow the user to run on JRE where possible (e.g. Ruby IDE) and allow the user to install additional
plugins via Plugin Manager. We should warn the user that the additional functionality requires additional packages (via
the package dependency) which most probably means the user is running on JRE and should install JDK. Jirka's writeup at
http://wiki.netbeans.org/OpenIssuesIdeOnJreOnly should address this scenario and I believe it is possible to implement
Why is it difficult to isolate smaller parts of tools.jar? At worst we could bundle tools.jar as a monolithic library.
I don't follow the argument that tools code needs to "work with" various JDK versions. javac from OpenJDK is known to
work fine on JDK 5+ (and in fact we already use it in this way). JDI is just a network connector; we already use the
version from the IDE's own JDK (5-7) to connect to whatever program you are running on any other JDK (1.4 - whatever).
dt.jar from JDK 6 should be a superset of that from JDK 5 since the Swing team cannot remove classes or properties. The
NB Profiler cluster ships its own JDK-version-specific native adapters already.
> Why is it difficult to isolate smaller parts of tools.jar?
No guarantee any smaller parts of that will work alone. No testing of this on Java side. No guarantee the internal
dependecies within the jar will not change in future and we'd need to bundle more and more...
> At worst we could bundle tools.jar as a monolithic library.
12MB of additional stuff just for the sake of running on JRE is way too much.
> I don't follow the argument that tools code needs to "work with" various JDK versions. javac from OpenJDK is known
> to work fine on JDK 5+ (and in fact we already use it in this way). JDI is just a network connector; we already use
> the version from the IDE's own JDK (5-7) to connect to whatever program you are running on any other JDK
> (1.4 - whatever). dt.jar from JDK 6 should be a superset of that from JDK 5 since the Swing team cannot remove
> classes or properties. The NB Profiler cluster ships its own JDK-version-specific native adapters already.
I'd let the owners of that functionality comment to this.
Anyway, for 6.5 bundling any part of JDK with NB is not the possible solution.
As for java debugger, we think it would work with JDI classes separated from tools.jar. However, the JDK version could
be a problem. If we bundle JDI from JDK 1.5 then we miss some new features and bugfixes from 1.6, if we bundle JDI from
JDK 1.6 then it might have problems running with JRE 1.5. Anyway, somebody would have to try to make sure it really
works in either case.
With dt.jar and GUI builder it is similar - beaninfos from JDK 1.5 would certainly work with JDK 1.6, but there could
be some new things missing, OTOH bundled 1.6 version might have problems with 1.5 classes (I think there were some
changes in JTable that could cause problems). Again, we'd have to check, probably we would be able to resolve it
somehow if it is really important.
Maybe the variant of using 1.5 version with some features/bugfixes missing would be acceptable for the case there is no
JDK (still better than nothing - from the user's point of view).
I can't speak for profiler, but it may be a bit more complicated - than debugger or GUI builder.
One other comment on running the full IDE on the JRE - if we supported this, why would anyone need the JDK at all? Would
there be any reason for anyone to ever download the JDK? And actually, the answer to this question may well be that
noone should need the JDK. But in that case, it should not be NetBeans that bundles and provides the extra pieces that
are not in the JRE; I think it should be the JRE itself: when JRE is modularized, maybe tools.jar and other JDK
components can be packaged as Java modules, so anyone with the JRE can install the JDK by adding some more modules to
the JRE. So, I think the cleanest solution is to allow the full IDE to run on the JRE, but it's the JRE's job to provide
the necessary extensions such as tools.jar, not NetBeans' job.
Profiler needs JDK for dynamic attach only. It needs Jvmstat and Attach API for it. All other functionality uses only JRE. I am not sure I understand Jesse'
> The NB Profiler cluster ships its own JDK-version-specific native adapters already.
Profiler has native agent library, which uses JNI and JVMTI (both are part of JRE) and the native agent is running inside profiled JVM.
Anyway I fully agree with Tomas Pavek and Tonda that taking out parts of tools.jar and running those against different versions of JRE is not a good idea for
the reason they mentioned, until this is supported by Java SE itself.
The JDK contains various components which do not make much sense as download-on-demand Java modules: executables, man
pages, JNI header files, demos, etc.
Keep in mind to change http://wiki.netbeans.org/FaqRunningOnJre when be completed.
IMHO it's fixed.
Thanks everyone for all the fixes!