Is it forbidden to create classes in standard packages like javax.swing?
Hi,
Is it forbidden to create classes in standard packages like javax.swing?
The reason for doing this is to get access to "default" members (no modifier) of instances of classes located in such a package. These classes are part of JRE's rt.jar.
Trying this out produces the following result:
Classes get compiled but at runtime they fail to access the mentioned members by throwing an IllegalAccessError.
Thanks in advance
> Hi,
> The reason for doing this is to get access to
> "default" members (no modifier) of instances of
> classes located in such a package. These classes are
> part of JRE's rt.jar.
And attempting that is probably a really bad idea. Such ideas often come from not understanding how to correctly use a framework.
Regardless...
1. You can use reflection to access inaccessible members. Look it up in the java docs.
2. You can provide your own (non-distributable) replacements for java core classes using the bootpath command line options. Just copy the classes that you want from the source, modify them, package them and then use them.
Thanks for your reply, jschell.
My question is not about whether it is good practice to solve problems that way.
Thanks for your two proposals. Unfortunately both are not an alternative while running under security restrictions (for example an unsigned web start application).
The main points of my question are:
1. Is it forbidden to create classes in these packages?
2. Why do I get the IllegalAccessError at runtime?
Thanks.
I'm with jschell here. When you start attempting desperate measures like that, it's time to go back down the cliff you are trying to climb up and look for the main highway again.
I am rather certain that unless you can modify the security restrictions of the target system that it doesn't matter what you do that you are not going to be able to access that stuff.That sort of restriction is one of the primary reasons that java exists.
As I have mentioned before my question is not about whether someone should do that.I am interested in the reason for the IllegalAccessError.
> As I have mentioned before my question is not about
> whether someone should do that.
> I am interested in the reason for the
> IllegalAccessError.
Ok. But that isn't what I said.
You suggested that you do in fact want to access some values. I am pointing out that you are not going to find a solution (regardless of the actual implementation) because java only allows special stuff like that when you control the security context.
As to the error it occurs because you are not allowed to do that there.
If you posted the exact line (and some lines around it) that the exception occurs I might guess as to which of the many security restrictions you are violating. Or someone else might know specifically. From the educational point of view that might help. It will however not provide a solution.
Hi jschell,
the comment I added should have been the reply to DrClap's posting, not yours. Obviously I posted a bit too late.
Your idea about the "educational point of view" matches my interest.
Let's take a simple member, for example "volatileImageBufferEnabled" of RepaintManager:
package javax.swing;
public class TestApp {
public static void main(String[] args) {
RepaintManager.volatileImageBufferEnabled = true;
}
}
This leads to a pretty short and simple stacktrace:
Exception in thread "main" java.lang.IllegalAccessError: tried to access field javax.swing.RepaintManager.volatileImageBufferEnabled from class javax.swing.TestApp
at javax.swing.TestApp.main(TestApp.java:15)
Interestingly there does not seem to be any SecurityManager involved explicitly.
Is this mechanism hard-coded in the JVM?
It is part of the specification..See section 5.4.3.2, note at the end that it specifies the exception that you are getting. http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#73492
So it fails because these classes are in the same package but not in the same "runtime package" because of the probably different classloaders?
> So it fails because these classes are in the same> package but not in the same "runtime package" because> of the probably different classloaders?That would be my guess.You can confirm the class loader part via the java.lang.Class.
Seems to be a reasonable explanation.Thanks for pointing me to that part of the specs.It's good to keep this subtle difference between "package" and "runtime package" in mind.
