Way too much time spent with Eclipse


L

lyallex

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
 
Ad

Advertisements

L

Lew

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

Unnamed packages are provided by the Java platform principally for convenience
when developing small or temporary applications or when just beginning development.

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

Daniel Dyer

Because the JLS explicitly forbids importing the unnamed (not "default")
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.
 
L

Lew

Daniel said:
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,
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.
 
D

Daniel Dyer

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

lyallex

Daniel said:
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
 
Ad

Advertisements

L

Lew

lyallex said:
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.
 
G

Guest

Lew said:
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
 
Ad

Advertisements

L

lyallex

Lew said:
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
 

Top