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.
Summary: | Do not assume VM is running on JDK | ||
---|---|---|---|
Product: | platform | Reporter: | Petr Jiricka <pjiricka> |
Component: | -- Other -- | Assignee: | Jiri Rechtacek <jrechtacek> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, av-nb, dlipin, jglick, jrojcek, olangr, sedlacek, thurka, tpavek |
Priority: | P2 | Keywords: | PLAN, UMBRELLA |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://wiki.netbeans.org/OpenIssuesIdeOnJreOnly | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 96711, 136269, 136354, 136361, 136914, 136916 | ||
Bug Blocks: | 127678 |
Description
Petr Jiricka
2008-05-21 15:38:37 UTC
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 in 6.5. 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'
comment
> 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! |