Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 125655 - Cannot use javax.xml.stream in NetBeans Platform based app
Cannot use javax.xml.stream in NetBeans Platform based app
Status: RESOLVED DUPLICATE of bug 96711
Product: platform
Classification: Unclassified
Component: Module System
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Jesse Glick
issues@platform
:
: 118947 125493 125678 (view as bug list)
Depends on: 96711
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-21 12:16 UTC by Jaroslav Tulach
Modified: 2008-12-23 14:27 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-01-21 12:16:24 UTC
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.
Comment 1 Jesse Glick 2008-01-21 19:13:10 UTC
*** Issue 125678 has been marked as a duplicate of this issue. ***
Comment 2 Jesse Glick 2008-01-21 19:15:15 UTC
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 ***
Comment 3 Marian Mirilovic 2008-01-22 07:56:44 UTC
vc
Comment 4 Jaroslav Tulach 2008-01-22 21:30:27 UTC
Guys, I do not think you can close a high priority bug as a duplicate of an enhancement.
Comment 5 Jesse Glick 2008-01-24 18:24:20 UTC
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 ***
Comment 6 Jaroslav Tulach 2008-01-25 23:33:18 UTC
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.
Comment 7 Jesse Glick 2008-01-25 23:52:13 UTC
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 ***
Comment 8 Jaroslav Tulach 2008-01-27 17:28:56 UTC
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.
Comment 9 mgoe 2008-01-28 09:06:05 UTC
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
Comment 10 Jesse Glick 2008-02-16 00:49:46 UTC
*** Issue 118947 has been marked as a duplicate of this issue. ***
Comment 11 Jesse Glick 2008-02-16 00:52:05 UTC
*** Issue 125493 has been marked as a duplicate of this issue. ***
Comment 12 Jesse Glick 2008-02-23 16:28:35 UTC
Can finally mark as duplicate.

*** This issue has been marked as a duplicate of 96711 ***
Comment 13 Quality Engineering 2008-12-23 14:27:50 UTC
This issue had *3 votes* before move to platform component


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo