BabyFace
asked on
Accessing non-packaged classes
Hi,
My JSP is being compiled into a package. But it uses a class which is not in a package (ie: no package statement). So a compiler error occurs... How can I access this class that has no package from a packaged class?
Thanks.
My JSP is being compiled into a package. But it uses a class which is not in a package (ie: no package statement). So a compiler error occurs... How can I access this class that has no package from a packaged class?
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The Java Tutorial claims that classes in the unnamed package are 'automatically' imported the same way java.lang classes and classes in the same package are imported without explicit import statements necessary. And this seems to happen in JDK 1.3. However, this is explicitly disallowed by the compiler in JDK 1.4 -- you can neither import by simple class name nor are classes in the unnamed package automatically available. This step was taken, by some accounts, because leaving classes in the unnamed package has always been discouraged.
A little more research leads me to believe that this may be compiler dependent. Note what the Java Language Spec says on the subject of unnamed packages (observe the plural):
"An implementation of the Java platform must support at least one unnamed package; it may support more than one unnamed package but is not required to do so. Which compilation units are in each unnamed package is determined by the host system.
In implementations of the Java platform that use a hierarchical file system for storing packages, one typical strategy is to associate an unnamed package with each directory; only one unnamed package is observable at a time, namely the one that is associated with the "current working directory." The precise meaning of "current working directory" depends on the host system.
Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just beginning development."
The strategy outlined in paragraph 2, an unnamed package for each directory, hasn't typically been implemented by the compilers that I have worked with. The Win32 JDK implementations typically implement a single unnamed package made up of all classes lacking a package statement in all directories named by the CLASSPATH. But that isn't the only possible interpretation of the JLS. And the compilation engine for JSPs in your server may have chosen to do something else.
Either put the class in a package (definitely the preferred solution) or, if not possible because you don't have source, wrap the class as suggested by objects. If you try importing the simple name from the JSP, that may work but I would expect it to be quite fragile -- in other words, an application server upgrade could 'fix' the unnamed package class reachability to bring it in line with JDK 1.4.
Jim
A little more research leads me to believe that this may be compiler dependent. Note what the Java Language Spec says on the subject of unnamed packages (observe the plural):
"An implementation of the Java platform must support at least one unnamed package; it may support more than one unnamed package but is not required to do so. Which compilation units are in each unnamed package is determined by the host system.
In implementations of the Java platform that use a hierarchical file system for storing packages, one typical strategy is to associate an unnamed package with each directory; only one unnamed package is observable at a time, namely the one that is associated with the "current working directory." The precise meaning of "current working directory" depends on the host system.
Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just beginning development."
The strategy outlined in paragraph 2, an unnamed package for each directory, hasn't typically been implemented by the compilers that I have worked with. The Win32 JDK implementations typically implement a single unnamed package made up of all classes lacking a package statement in all directories named by the CLASSPATH. But that isn't the only possible interpretation of the JLS. And the compilation engine for JSPs in your server may have chosen to do something else.
Either put the class in a package (definitely the preferred solution) or, if not possible because you don't have source, wrap the class as suggested by objects. If you try importing the simple name from the JSP, that may work but I would expect it to be quite fragile -- in other words, an application server upgrade could 'fix' the unnamed package class reachability to bring it in line with JDK 1.4.
Jim
ASKER
Thanks,
I don't know what I was thinking.
I don't know what I was thinking.
Jim