This discussion is archived
1 2 Previous Next 28 Replies Latest reply: Aug 20, 2013 12:58 AM by 9423755 Go to original post RSS
  • 15. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    masijade wrote:

     

    And as I said, have you even TRIED, yet.  But I'll take your answer as a RESOUNDING no.

     

    Jason_942375 wrote:

     

    NONE OF MY EXAMPLES USES A PACKAGE but only ONE of them does not compile. The question is, why?

     

    And you don't see that as a problem?  There is a REASON why this is STRONGLY discouraged in the specs.

     

    It's a QUESTION. It's not a PROBLEM.

     

    Can you answer the question, or can you not answer the question?

    So far, nobody has been able to answer the question.  And yes, you are included in that nobody. Telling me "you shouldn't use the default package", or "use a package, that'll make it compile" DOES NOT ANSWER THE QUESTION.

  • 16. Re: Why does this not work?
    masijade Explorer
    Currently Being Moderated

    Since you DON'T bother telling anyone that it posted somewhere else, YES.  As you said, you've received replies.  Did any of those replies mention the default package?  I see they did, so everyone here has wasted their time.

     

    Edit:  And besides, you sure waited a LONG time to do so.  <sarcasm>ALL of ONE day.  WOW!  I can see how your patience would be at an end.</sarcasm>

  • 17. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    masijade wrote:

     

    Since you DON'T bother telling anyone that it posted somewhere else, YES.  As you said, you've received replies.  Did any of those replies mention the default package?  I see they did, so everyone here has wasted their time.

     

    So you think "mentioning the default package" means "answering the question"?  You think that's sufficient?  Just the mere mentioning of the words "default" and "package" in a reply must mean, must surely connote, that the question has been answered?

     

    You're wasting my time mate. You haven't even bothered to try to understand the question. Best you add me to your "losers" list. And hope we never meet in person.

  • 18. Re: Why does this not work?
    rp0428 Guru
    Currently Being Moderated

    What has that got to do with it? I'm using the java.util package in my counter-example.

    EXACTLY! And as the doc says:

    The packages java, java.lang, and java.io are always observable

     

    The 'java.util' package IS PART OF the 'java' package so it is observable.

     

    It is interesting that nobody seems to be able (willing perhaps) to answer this, which must surely be a trivial question for most java programmers

    I have answered it TWICE now. What is interesting is that you don't seem to recognize the answer.

     

    If you DO NOT understand what it means to be observable then you should say so instead of ranting and raving.

     

    The term 'observable' means that you can 'observe' (see, reference) the packages 'top-level classes' and the packages sub-packages (and their top-level classes). That means that you do NOT need an import statement.

     

    You have to be willing to RTFM when you are given a reference to the appropriate sections. There are many further references to the topic in the link I gave you. Read the entire Chapter 7 Packages

     

    7.5. Import Declarations

    An import declaration allows a named type or a static member to be referred to by a simple name (§6.2) that consists of a single identifier.

    Without the use of an appropriate import declaration, the only way to refer to a type declared in another package, or a static member of another type, is to use a fully qualified name (§6.7).

    Hmm - seems to me the ones that compile for you are when you use 'a fully qualified name' of a class in an 'observable' package.

     

    7.1. Package Members

    The members of a package are its subpackages and all the top level class types (§7.6, §8) and top level interface types (§9) declared in all the compilation units (§7.3) of the package.

    •   The package java has subpackages awt, applet, io, lang, net, and util, but no compilation units.
    •   The package java.awt has a subpackage named image, as well as a number of compilation units containing declarations of class and interface types.

    If the fully qualified name (§6.7) of a package is P, and Q is a subpackage of P, then P.Q is the fully qualified name of the subpackage, and furthermore denotes a package.

    And this one

    All the compilation units of the predefined package java and its subpackages lang and io are always observable

    Hmm - so the 'java' package is observable and its members are 'its subpackages and all the top level class types ...'.  So 'java.nio.file.Path'  is a 'compilation unit of the predefined package java' and so is observable.

     

    Gee - I believe that is EXACTLY what I first said.

     

    You can choose NOT to believe an answer if you wish but reality exists independent of your belief.

  • 19. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    rp0428 wrote:

     

    What has that got to do with it? I'm using the java.util package in my counter-example.

    EXACTLY! And as the doc says:

    The packages java, java.lang, and java.io are always observable

     

    The 'java.util' package IS PART OF the 'java' package so it is observable.

     

    It is interesting that nobody seems to be able (willing perhaps) to answer this, which must surely be a trivial question for most java programmers

    I have answered it TWICE now. What is interesting is that you don't seem to recognize the answer.

     

    java.util is part of the "java" package?  Where's your source on that?  There is a java.lang package. There is a java.util package. They are separate packages. java.lang is included by default; java.util is not.

     

    Chapter&amp;nbsp;7.&amp;nbsp;Packages

    A compilation unit automatically has access to all types declared in its package and also automatically imports all of the public types declared in the predefined package java.lang

    Every compilation unit implicitly imports every public type name declared in the predefined package java.lang, as if the declaration import java.lang.*; appeared at the beginning of each compilation unit immediately after any package statement. As a result, the names of all those types are available as simple names in every compilation unit.

    All the compilation units of the predefined package java and its subpackages lang and io are always observable.

     

    Where's the reference to java.util being part of the "java" package?

     

    Even if what you said is correct, it's a complete red herring. It's immaterial. It misses the point entirely, as my good friend masijade managed to miss the point entirely. My second example used the Paths class in the java.nio.file package.  And it compiled with a full qualification of the Path class without needing an import statement.  As you would expect it to do. Are you now going to tell me that the java.nio.file package is part of the "java" package as well and that that was why it compiled without an import statement?

     

    Come on, you can do better.  At least, I think maybe you can. But maybe your hubris just gets in the way of all that immense brainpower.

  • 20. Re: Why does this not work?
    rp0428 Guru
    Currently Being Moderated

    Are you now going to tell me that the java.nio.file package is part of the "java" package as well and that that was why it compiled without an import statement?

    EXACTLY - now you seem to be catching on.

     

    That is precisely why it works. Just convert your question into a statement and you have the answer

     

    the java.nio.file package is part of the "java" package as well and that that was why it compiled without an import statement

    As that quote from section 7.1 above said

    If the fully qualified name (§6.7) of a package is P, and Q is a subpackage of P, then P.Q is the fully qualified name of the subpackage, and furthermore denotes a package.

    The members of a package are its subpackages and all the top level class types (§7.6, §8) and top level interface types (§9) declared in all the compilation units (§7.3) of the package.

    That shows that 'java.nio.file' means that  'file' is a subpackage of the 'java.nio' package and 'nio' is a subpackage of the 'java' package.

     

    The Java API for Package 'java.nio.file' lists the interfaces and classes in that package and 'Path' is one of the interfaces:

    http://docs.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html

     

    And 'nio' is a subpackage of the 'java' package. The Java API lists ALL of the top-level subpackages of the 'java' package and you can see that 'nio' is one of them

    http://docs.oracle.com/javase/7/docs/api/overview-summary.html

    java.nio

    Defines buffers, which are containers for data, and provides an overview of the other NIO packages.

    That java API doesn't list the subpackages so I provided that link above.

     

    That is what the 'hierarchical' naming system is all about: package, subpackage, sub-subpackage, . . . Interface/Class.

     

    Any of those embedded 'subpackages' is a package in its own right and a member of the parent package whose name precedes it.

     

    By George I think you have it.

  • 21. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    Could what you are saying be paraphrased thus:

     

     

    Any class descended from java may optionally be referenced by its fully qualified name, obviating the necessity of an import declaration. Eg.


         java.x.y.Zed z = new java.x.y.Zed();

     

    Any class not descended from java needs a package import declaration - eg


         import pkg1.Shape;

         ...

         Shape s = new Shape();

  • 22. Re: Why does this not work?
    dag72 Newbie
    Currently Being Moderated

    Your question with regards to why your code didn't compiled was answered, the problem is simply the fact that your class Test7 isn't known to the main() method when it is invoked. Hope this clears up any ambiguity.

  • 23. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    562c26ae-7ca6-42c9-a77d-b4e4a269adc5 wrote:

     

    Your question with regards to why your code didn't compiled was answered, the problem is simply the fact that your class Test7 isn't known to the main() method when it is invoked. Hope this clears up any ambiguity.

     

    Do you specialise in providing tautological explanations?

  • 24. Re: Why does this not work?
    dag72 Newbie
    Currently Being Moderated

    No but in this case the problem is obvious and everyone sees that...

  • 25. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    dag72 wrote:

     

    No but in this case the problem is obvious and everyone sees that...

     

    "Hey, my car's broken down. Can you help?"

    "Uh, yeah, I see your problem already"

    "Oh yeah, what is it?"

    "It's uh, not moving"

  • 26. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    Well, I just figured out why this wasn't working. The real reason why it didn't work was nothing to do with any overcomplicated observability rubbish; my instincts were right: it should have worked and indeed it would have worked all along were it not for the fact that there was a file called test.class file in the current directory.

    The clue, after all, was in the error message, which, after going back to this issue tonight, and trying to fix the damned issue again, I suddenly alighted on:

     

    C:\Users\J\My Documents\java>javac Test8.java

    Test8.java:8: error: cannot find symbol

            test.Test7.foo(10);

                ^

      symbol:   variable Test7

      location: class test

    1 error

     

    Eh, variable Test7 in class test?  What could that possibly mean?  Why is the compiler complaining about a class called test when it's supposed to be a package?  Well it was the test.class file that the compiler was finding and of course when it found test.class it assumed that that matched the call to "test.Test7.foo()" in Test8.java and didn't consider that test might be a package and Test7 a class inside that package. God knows how it got there but there got did it and it managed to screw up my compilation and cause a whole heap of grief.

     

    So in the end it had nothing to do with observability, and diagnosing the cause of the problem didn't need an intricate understand of the JLS based on a whole heap of JLS paragraphs and definitions about observability, the java.util package, java package, java.io, subpackages, and such like.

    Everything that I believed about how it should be working was correct - that you should be able to use either an import statement or a fully qualified class reference. It should not make any difference whatsoever. It's a programmer's convenience to use import statements. It is not mandatory for references to classes in your own packages to include an import statement in your .java file. I am pleased to say I stuck to my guns in the face of hostile enemy fire and refused to be browbeaten by explanations that just, to me, didn't make sense.

     

    Please take note chaps, especially my good friend and follower gimbal2 and my very good friend masijade, I did not at any time receive a solution to this problem either here or at "the other place".

     

    Issue solved

  • 27. Re: Why does this not work?
    masijade Explorer
    Currently Being Moderated

    So, your "problem" is simply your own refusal to stick to the most basic programming practices.

     

    1.  Classes begin with an upper case letter and packages with a lower.  This led to both a confusing error message as "test" was seen and expected to be a package, and a part of the problem as you typed "test" expecting a package and got a class.

     

    2.  Always give your classes a package.  Had this class had a package the "test" class would never have been found as the "default" package would not have been investigated.  The "default" package was only investigated as this class was part of the default package.

     

    So, you had been given the solution to your "problem" MULTIPLE times.  That was to give your class a package and to not use the default package, you simply chose to ignore it.  And you were given that solution before you ever opened this thread, it was given on the same day you opened the other thread.  You decided however, to not even ATTEMPT that solution and to search for any cause OTHER than your own bad programming practices.  And, in end effect, you didn't find any.  And this "test.class" byte code file existing in the same place as the source file for this class is ANOTHER of those bad programming practices as you should not create the binary byte code files alongside the java source files, although not following this practice is not NEARLY as bad as not following the other two.

  • 28. Re: Why does this not work?
    9423755 Explorer
    Currently Being Moderated

    Ah masijade, masijade, my good good friend masijade, I thought you had left me, never to excoriate me again for my human frailties!

1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points