Forbidden "internal" packages

[Qu0ll]

I would like to use the Rhino classes built in to Java 6 but whenever I try
to include a class from the sun.org.mozilla.javascript.internal package I
get errors. Firstly NetBeans complains that the import is from a forbidden
package (even though Eclipse has no problem with it) and then the compiler
reports that the package(s) doesn't exist. I realise that the package name
includes the word "internal" but I have been able to use other internal
packages from the JRE without any dramas so why is it so prickly about these
classes and packages? And what's the point of including these classes
within the JRE if you cannot use them in a program?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Joshua Cranmer]

I would like to use the Rhino classes built in to Java 6 but whenever I
try to include a class from the sun.org.mozilla.javascript.internal
package I get errors. Firstly NetBeans complains that the import is
from a forbidden package (even though Eclipse has no problem with it)
and then the compiler reports that the package(s) doesn't exist. I
realise that the package name includes the word "internal" but I have
been able to use other internal packages from the JRE without any dramas
so why is it so prickly about these classes and packages? And what's
the point of including these classes within the JRE if you cannot use
them in a program?

Are you sure that the package exists?

 

[Qu0ll]

Are you sure that the package exists?

The package definitely exists as I can view a list of the classes contained
within it by expanding the rt.jar in Eclipse. Also, I can include classes
from it in the Eclipse editor without any problems until the code is
compiled at which point the "package doesn't exist" error pops up. And as I
said, the NetBeans editor marks the imports as "forbidden" with a yellow
squiggly underline but doesn't generate a syntax error until the code is
compiled.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Qu0ll]

[...]

The package definitely exists as I can view a list of the classes
contained within it by expanding the rt.jar in Eclipse. Also, I can
include classes from it in the Eclipse editor without any problems until
the code is compiled at which point the "package doesn't exist" error pops
up. And as I said, the NetBeans editor marks the imports as "forbidden"
with a yellow squiggly underline but doesn't generate a syntax error until
the code is compiled.

Further, the following code runs fine in Eclipse:

import sun.org.mozilla.javascript.internal.WrappedException;

public class ForbiddenTest {

WrappedException we;

public static void main(final String[] args) {

System.out.println("Hello world!");
}
}

but if I try to compile it at the command line I get:

D:\>javac ForbiddenTest.java
ForbiddenTest.java:1: package sun.org.mozilla.javascript.internal does not
exist
import sun.org.mozilla.javascript.internal.WrappedException;
^
ForbiddenTest.java:5: cannot find symbol
symbol : class WrappedException
location: class ForbiddenTest
WrappedException we;
^
2 errors

What gives?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Lew]

import sun.org.mozilla.javascript.internal.WrappedException;

What advantage does the WrappedException provides that you cannot get from
elsewhere?

D:\>javac ForbiddenTest.java
ForbiddenTest.java:1: package sun.org.mozilla.javascript.internal does not exist
import sun.org.mozilla.javascript.internal.WrappedException;
^
ForbiddenTest.java:5: cannot find symbol
symbol : class WrappedException
location: class ForbiddenTest
WrappedException we;
^
2 errors

What gives?

You aren't providing the classpath (option "-classpath" or "-cp") for javac.

 

[Joshua Cranmer]

D:\>javac ForbiddenTest.java
ForbiddenTest.java:1: package sun.org.mozilla.javascript.internal does
not exist
import sun.org.mozilla.javascript.internal.WrappedException;
^
ForbiddenTest.java:5: cannot find symbol
symbol : class WrappedException
location: class ForbiddenTest
WrappedException we;
^
2 errors

What gives?

Obviously, Java can't find it. Specifically, you're using a package
that's included with Eclipse's libraries that is not found in the actual
JRE distributions.

 

[Qu0ll]

What advantage does the WrappedException provides that you cannot get from
elsewhere?

This is just a test sample, I have no actual use for this particular class.
I just wanted to whip up something that highlighted the problem.

You aren't providing the classpath (option "-classpath" or "-cp") for
javac.

I must seem like a real novice huh? The class WrappedException is part of
the Java 6 JRE.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Qu0ll]

Obviously, Java can't find it. Specifically, you're using a package that's
included with Eclipse's libraries that is not found in the actual JRE
distributions.

Not so obvious - the package has nothing to do with Eclipse, it is a
standard part of the Java 6 JRE.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Joshua Cranmer]

Not so obvious - the package has nothing to do with Eclipse, it is a
standard part of the Java 6 JRE.

jcranmer@quetzalcoatl ~ $ javap
sun.org.mozilla.javascript.internal.WrappedException
ERROR:Could not find sun.org.mozilla.javascript.internal.WrappedException

Not in my version of the JRE. But if I:
jcranmer@quetzalcoatl /C/Program Files/Java/jre1.6.0_04/lib $ javap
-bootclasspath rt.jar sun.org.mozilla.javascript.internal.WrappedException
public class sun.org.mozilla.javascript.internal.WrappedException
extends sun.org.mozilla.javascript.internal.EvaluatorException{

Are you sure you have the right JRE?

 

[Qu0ll]

jcranmer@quetzalcoatl ~ $ javap
sun.org.mozilla.javascript.internal.WrappedException
ERROR:Could not find sun.org.mozilla.javascript.internal.WrappedException

Not in my version of the JRE. But if I:
jcranmer@quetzalcoatl /C/Program Files/Java/jre1.6.0_04/lib $
javap -bootclasspath rt.jar
sun.org.mozilla.javascript.internal.WrappedException
public class sun.org.mozilla.javascript.internal.WrappedException extends
sun.org.mozilla.javascript.internal.EvaluatorException{

Are you sure you have the right JRE?

I have only one JRE on this machine and if I look inside rt.jar I can see
the package and classes within it.

Are you saying that it should work?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Lew]

I must seem like a real novice huh? The class WrappedException is part
of the Java 6 JRE.

Results of my attempts:

$ javac -d ../build/classes/
testit/ForbiddenTest.javatestit/ForbiddenTest.java:3: package
sun.org.mozilla.javascript.internal does not exist
import sun.org.mozilla.javascript.internal.WrappedException;
^
testit/ForbiddenTest.java:8: cannot find symbol
symbol : class WrappedException
location: class testit.ForbiddenTest
WrappedException we;
^
2 errors

$ javac -d ../build/classes/ \
-cp /opt/java/java/jre/lib/rt.jar testit/ForbiddenTest.java

$ ls ../build/classes/testit/
ForbiddenTest.class

 

[Qu0ll]

...


Results of my attempts:

$ javac -d ../build/classes/
testit/ForbiddenTest.javatestit/ForbiddenTest.java:3: package
sun.org.mozilla.javascript.internal does not exist
import sun.org.mozilla.javascript.internal.WrappedException;
^
testit/ForbiddenTest.java:8: cannot find symbol
symbol : class WrappedException
location: class testit.ForbiddenTest
WrappedException we;
^
2 errors

$ javac -d ../build/classes/ \
-cp /opt/java/java/jre/lib/rt.jar testit/ForbiddenTest.java

$ ls ../build/classes/testit/
ForbiddenTest.class

I see. So what is Sun trying to say with this requirement, that this
package shouldn't be used? And why does NetBeans flag it as a forbidden
package?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Qu0ll]

[...]

I see. So what is Sun trying to say with this requirement, that this
package shouldn't be used? And why does NetBeans flag it as a forbidden
package?

In fact I am really starting to get the impression that this package is not
to be used. When I run my applet which makes use of those classes I get
this:

java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.sun.org.mozilla.javascript.internal)

Is there a way around this without signing the applet?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Owen Jacobson]

[...]

I see. So what is Sun trying to say with this requirement, that this
package shouldn't be used? And why does NetBeans flag it as a
forbidden package?

In fact I am really starting to get the impression that this package is
not to be used. When I run my applet which makes use of those classes
I get this:

java.security.AccessControlException: access denied
(java.lang.RuntimePermission
accessClassInPackage.sun.org.mozilla.javascript.internal)

Is there a way around this without signing the applet?

The sun. package hierarchy is documented[0] on Sun's website as being
part of the implementation of the Sun Java Virtual Machine. Classes and
packages whose names begin with sun. are not guaranteed to exist from
VM release to VM release, to exist from host platform to host platform,
to exist on any other VM, or to be available separately. This applies
to the sun.misc.Base64Encoder class, which comes up in a lot of
poorly-researched examples, too.

You, as an application developer, should probably be talking to the
org.mozilla.javascript. package hierarchy, which is available from the
Rhino download site, or talking strictly to the Java Scripting API (not
to any particular implementation), which will get you the
language-agnostic features but not the Javascript-specific ones. Which
is appropriate is somewhat dependent on your app.

-o

[0] <http://java.sun.com/products/jdk/faq/faq-sun-packages.html>

 

[Karl Uppiano]

I would like to use the Rhino classes built in to Java 6 but whenever I
try to include a class from the sun.org.mozilla.javascript.internal
package I get errors. Firstly NetBeans complains that the import is from
a forbidden package (even though Eclipse has no problem with it) and then
the compiler reports that the package(s) doesn't exist. I realise that
the package name includes the word "internal" but I have been able to use
other internal packages from the JRE without any dramas so why is it so
prickly about these classes and packages? And what's the point of
including these classes within the JRE if you cannot use them in a
program?

I believe that Sun makes some undocumented internal packages unavailable to
Java SDK end users because they do not want to support the internal API.
They want to retain the ability to modify the packages without concern for
breaking code developed by the Java development community at large. The fact
that Eclipse doesn't observe the restriction while NetBeans does is probably
partially due to the fact that NetBeans is sponsored by Sun. I'll bet
Eclipse will observe the restriction eventually.

I haven't tried this myself for your particular case, but if you can get a
copy of the packages directly from the JSR, and put the jars in your own
redistributable, and/or use the endorsed mechanism, I think you can gain
access to the packages you want.

 

[Qu0ll]

I would like to use the Rhino classes built in to Java 6 but whenever I
try to include a class from the sun.org.mozilla.javascript.internal
package I get errors. Firstly NetBeans complains that the import is from
a forbidden package (even though Eclipse has no problem with it) and then
the compiler reports that the package(s) doesn't exist. I realise that
the package name includes the word "internal" but I have been able to use
other internal packages from the JRE without any dramas so why is it so
prickly about these classes and packages? And what's the point of
including these classes within the JRE if you cannot use them in a
program?

Thanks to everyone who has replied on this subject.

My intention was to utilise the built-in Rhino implementation in an applet
and avoid having to include an additional Rhino JAR in the applet archive
list. This is purely in an attempt to reduce the overall footprint of the
applet. It now seems clear that these internal classes are not to be used
directly in this manner as several of you have pointed out but for various
reasons I need access to some of the Rhino classes that are not available if
I just use the scripting API. Therefore I am left with no option but to use
the external/separate Rhino implementation which is more up-to-date anyway
so it's no big deal.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Roedy Green]

My intention was to utilise the built-in Rhino implementation in an applet
and avoid having to include an additional Rhino JAR in the applet archive
list.

If you implement with JWS the jar will be loaded only once.
see http://mindprod.com/jgloss/javawebstart.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Nature provides a free lunch, but only if we control our appetites."
~ William Ruckelshaus, America’s first head of the EPA