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.
Because of Index: core/startup/src/org/netbeans/core/startup/NbInstaller.java --- core/startup/src/org/netbeans/core/startup/NbInstaller.java Base (1.46) +++ core/startup/src/org/netbeans/core/startup/NbInstaller.java Locally Modified (Based On 1.46) @@ -765,11 +765,11 @@ "javax/lang/model/", "javax/tools/", // do not want JAX-WS 2.0 classes from JDK 6; - "javax/xml/bind/", // NOI18N - "javax/xml/ws/", // NOI18N - "javax/xml/stream/", // NOI18N - "javax/jws/", // NOI18N - "javax/xml/soap/" // NOI18N +// "javax/xml/bind/", // NOI18N +// "javax/xml/ws/", // NOI18N +// "javax/xml/stream/", // NOI18N +// "javax/jws/", // NOI18N +// "javax/xml/soap/" // NOI18N }; people cannot use javax.xml.stream API, which is regular part of 1.6 in their NetBeans applications.
*** Issue 125678 has been marked as a duplicate of this issue. ***
Right, cannot currently use the JRE version because it is intentionally blocked. Can include it in a lib wrapper module if you need it. *** This issue has been marked as a duplicate of 96711 ***
vc
Guys, I do not think you can close a high priority bug as a duplicate of an enhancement.
It's not a bug; modules wishing to use these classes currently must declare a dependency on a module providing these classes. That is as designed for current NB releases. In the future a different model will be possible. *** This issue has been marked as a duplicate of 96711 ***
Your advice may work in the IDE, but this is a bug in the platform. Applications build for the platform, using public 1.6 API are magically broken. It may be as designed, but it is a high priority bug.
Nonetheless it is identical to issue #96711. If you want to consider that a bug for purposes of prioritization, I don't much care. I do not agree that this is a high priority bug. All you need do is create (or borrow) a library wrapper module containing the desired classes and depend on it. (No different for a Platform app than for an IDE module.) When such a straightforward workaround is available, this would be a P3 according to normal categorization. *** This issue has been marked as a duplicate of 96711 ***
No, this is not duplicate. If issue 96711 is fixed, then this issue would be very likely fixed as well, however there are other ways to fix this problem. That is why I am not going to let this problem fall under the table by making duplicate of something that nobody plans integrate anytime soon. I know there is a workaround, as that is why this is just P2. Otherwise it would be P1. However if we want people use the platform, we cannot surprise them by throwing ClassNotFoundErrors when they do something completely natural. And usage of official JDK's APIs is natural. Originally the list of forbidden packages in NbInstaller was meant for implementation classes. In last release we used that also for API classes. That was big mistake that needs to be fixed. At least for the platform. If you do not want to spend time on issue 96711, then I suggest to make the list of forbidden packages pluggable. Almost empty for the platform, fed by some IDE cluster or nb6.1 cluster. As you can see, there exists other fix than issue 96711, and that is the reason why I cannot agree with this bug being duplicate of issue 96771.
I entered bug 125493 and I fully support the arguments of jtulach. If you use an official JDK API the platform cannot throw a ClassNotFoundError. And I don't want to use any workaround just to use classes which are officially supported by the JDK for the reasons given in my bug report. So please don't block any official APIs. Best regards, Martin Goettlicher
*** Issue 118947 has been marked as a duplicate of this issue. ***
*** Issue 125493 has been marked as a duplicate of this issue. ***
Can finally mark as duplicate. *** This issue has been marked as a duplicate of 96711 ***
This issue had *3 votes* before move to platform component