 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2007Way too much time spent with Eclipse
Hello I have the following interface in my working directory (C:\java>) public interface Foo { public void doSomething(); } As you can see, there is no expicit package definition so this class is in the default package. Why do I want to do this ? well it's part of an exploration of classloading and the classloader architecture and for the fist time in I don't know how many years I'm working on the command line without Eclipse to tell me when I did something stupid. To cut a long story short I wanted to refer to this interface in a packaged class and I can't because you can't apparently use classes in the default package from within a named package. I'm trying to understand why this is but I'm not getting too far, I'm sure I did know it once, a long time ago but I've sure forgoten it now. Why can't you use classes in the default package from within a named package. Thanks > Hello > [quoted text clipped - 19 lines] > Why can't you use classes in the default package from within a named > package. Because the JLS explicitly forbids importing the unnamed (not "default") package. It would defeat the whole point of having packages. <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.2> > Unnamed packages are provided by the Java platform principally for convenience > when developing small or temporary applications or when just beginning development. <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5> > A type-import-on-demand declaration (§7.5.2) imports all the accessible (§6.6) > types of a named type or package as needed. > It is a compile time error to import a type from the unnamed package. Of course, if you don't import the unnamed package then you can't refer to classes within it from a named package. Packages are fundamental to the organization of Java programs, thus the rule.  SignatureLew >> Hello >> I have the following interface in my working directory (C:\java>) [quoted text clipped - 16 lines] > Because the JLS explicitly forbids importing the unnamed (not "default") > package. ... > <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5> >> A type-import-on-demand declaration (§7.5.2) imports all the accessible >> (§6.6) types of a named type or package as needed. It is a compile time >> error to import a type from the unnamed package. The confusion probably stems from the fact that this statement was not in the previous version of the JLS and (prior to JDK 1.4) Sun's compiler did allow classes from the unnamed/default package to be used from named packages. Dan. SignatureDaniel Dyer https://watchmaker.dev.java.net - Evolutionary Computation for Java > The confusion probably stems from the fact that this statement was not > in the previous version of the JLS and (prior to JDK 1.4) Sun's compiler > did allow classes from the unnamed/default package to be used from named > packages. Somewhere in the last five years they must have lost the excuse to be confused by that. "Prior to JDK 1.4" is already obsolete, and long since. The JLS second edition did have some restrictions on the unnamed type, but they were implicit. For example, <http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#70209> > A type-import-on-demand declaration (§7.5.2) imports all the accessible types > of a named type or package as needed. Note that it explicitly refers to a named type or package. That leaves single-type-import declarations as the only way to pull in classes from the unnamed (not "default") package, equivalent to having no import in such a case. It remains that the changes to that part of the JLS are three years old now, and after all this time one should no more be stuck in the old way about the unnamed package than about the memory model. SignatureLew >> The confusion probably stems from the fact that this statement was not >> in the previous version of the JLS and (prior to JDK 1.4) Sun's [quoted text clipped - 4 lines] > confused by that. "Prior to JDK 1.4" is already obsolete, and long > since. ... > It remains that the changes to that part of the JLS are three years old > now, and after all this time one should no more be stuck in the old way > about the unnamed package than about the memory model. Yes, but I think that the OP's confusion is justifiable. It would have been easy to miss this fairly minor change at the time it happened and, given Sun's usual commitment to Java backwards compatibility, it would be surprising to discover that the rules have changed since the last time they tried to use the unnamed package (assuming, of course, that the OP developed pre-1.4 Java and that this was the root of their misunderstanding). Dan. SignatureDaniel Dyer https://watchmaker.dev.java.net - Evolutionary Computation for Java >>> The confusion probably stems from the fact that this statement was >>> not in the previous version of the JLS and (prior to JDK 1.4) Sun's [quoted text clipped - 20 lines] > > Dan. Yes, well I've been developing in Java since way back. I first used JDK 1.1 around the end of '97 and did my final year degree project using J2SE 1.2 around end 1999/bginning 2000. That was probably the last time I wrote a class that didn't have a package declaration in it ... As for anything prior to JDK 1.4 being obsolete, my last position was with a company that had a viable product range still being developed and maintained in Java 1.3 and they are still making money and see no reason to change just because the latest greatest thing has been released. Personally I like to use the latest versions for no other reason that it is the latest version and I like to keep up with things so in the end I had to go :)) Still, I think I get the picture now. Thanks for taking the time to reply. Duncan > As for anything prior to JDK 1.4 being obsolete, my last position was > with a company that had a viable product range still being developed and > maintained in Java 1.3 and they are still making money and see no reason > to change just because the latest greatest thing has been released. This "latest greatest thing" they excoriate is Java 1.4, which itself is over five years old, almost six, and going into End-of-Life in its own right. That seems beyond conservatism. SignatureLew >> As for anything prior to JDK 1.4 being obsolete, my last position was >> with a company that had a viable product range still being developed [quoted text clipped - 7 lines] > > That seems beyond conservatism. If it cost hundreds of thousands of dollars to certify the application with a new Java version, then there are reasons not to upgrade. And I think IBM still support 1.3.1 - if you pay for a service contract. SUN may even do the same for Java on Solaris. That said - it is a risk that need to be evaluated. If the app is expected to live for many years, then it becomes a question of "when" instead of "if". But often it will wait until the app needs to be updated for other reasons. Arne >> As for anything prior to JDK 1.4 being obsolete, my last position was >> with a company that had a viable product range still being developed [quoted text clipped - 7 lines] > > That seems beyond conservatism. http://dictionary.reference.com/browse/excoriate excoriate: to denounce or berate severely; flay verbally: Gosh, I had to look that one up ;-) I don't think anyone is doing any excoriating(?), they just don't see the point of changing something that still earns them their salaries. Sounds like good commercial sense to me. I do agree that there probably will come a time when it's all just a bit too old hat and they have to move on. Anyway, let's not argue about it, far more important things to be getting on with now that I've finally got my head around classloaders. Java still lights my fire even after all these years. Duncan Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.