Way too much time spent with Eclipse

Discussion in 'Java' started by lyallex, Oct 27, 2007.

  1. lyallex

    lyallex Guest

    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
    lyallex, Oct 27, 2007
    #1
    1. Advertising

  2. lyallex

    Lew Guest

    lyallex wrote:
    > 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.


    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.

    --
    Lew
    Lew, Oct 27, 2007
    #2
    1. Advertising

  3. lyallex

    Daniel Dyer Guest

    On Sat, 27 Oct 2007 14:30:15 +0100, Lew <> wrote:

    > lyallex wrote:
    >> 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.

    >
    > 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.

    --
    Daniel Dyer
    https://watchmaker.dev.java.net - Evolutionary Computation for Java
    Daniel Dyer, Oct 27, 2007
    #3
  4. lyallex

    Lew Guest

    Daniel Dyer wrote:
    > 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.

    --
    Lew
    Lew, Oct 27, 2007
    #4
  5. lyallex

    Daniel Dyer Guest

    On Sat, 27 Oct 2007 15:53:55 +0100, Lew <> wrote:

    > Daniel Dyer wrote:
    >> 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.


    ....

    > 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.

    --
    Daniel Dyer
    https://watchmaker.dev.java.net - Evolutionary Computation for Java
    Daniel Dyer, Oct 27, 2007
    #5
  6. lyallex

    lyallex Guest

    Daniel Dyer wrote:
    > On Sat, 27 Oct 2007 15:53:55 +0100, Lew <> wrote:
    >
    >> Daniel Dyer wrote:
    >>> 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.

    >
    > ...
    >
    >> 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.
    >


    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
    lyallex, Oct 27, 2007
    #6
  7. lyallex

    Lew Guest

    lyallex wrote:
    > 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.

    --
    Lew
    Lew, Oct 27, 2007
    #7
  8. Lew wrote:
    > lyallex wrote:
    >> 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.


    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
    =?UTF-8?B?QXJuZSBWYWpow7hq?=, Oct 27, 2007
    #8
  9. lyallex

    lyallex Guest

    Lew wrote:
    > lyallex wrote:
    >> 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.
    >


    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
    lyallex, Oct 27, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. SB
    Replies:
    0
    Views:
    364
  2. Dan
    Replies:
    0
    Views:
    350
  3. RSoIsCaIrLiIoA
    Replies:
    8
    Views:
    272
    Mark McIntyre
    Dec 21, 2005
  4. cpp4ever
    Replies:
    3
    Views:
    359
    Francesco
    Sep 8, 2009
  5. Phonethics Mobile Media

    urllib2.urlopen taking way too much time

    Phonethics Mobile Media, Apr 19, 2010, in forum: Python
    Replies:
    0
    Views:
    450
    Phonethics Mobile Media
    Apr 19, 2010
Loading...

Share This Page