Way too much time spent with Eclipse
9 Message(s) by 4 Author(s) originally posted in java programmer
| From: lyallex |
Date: Saturday, October 27, 2007
|
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 do not 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 not because you can not
app arently 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 have sure forgoten it now.
Why can not you use classes in the default package from within a named
package.
Thanks
| From: Lew |
Date: Saturday, October 27, 2007
|
wrote in
message :
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 do not 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 not because you can not 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 have sure forgoten it now.
Why can not you use classes in the default package from within a named
package.
Because the JLS explicitly forbids
import ing the unnamed (not "default")
package.
It'd 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 do not import the unnamed package then you can not refer to
classes within it from a named package.
Packages are fundamental to the organization of JAVA programs, thus the rule.
--
Lew
| From: Daniel Dyer |
Date: Saturday, October 27, 2007
|
wrote in message:
wrote in message:
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 do not 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 not because you can not 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 have sure forgoten it now.
Why can not 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 wasn't 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
| From: Lew |
Date: Saturday, October 27, 2007
|
wrote in message:
The confusion probably stems from the fact that this statement wasn't
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
| From: Daniel Dyer |
Date: Saturday, October 27, 2007
|
wrote in message:
wrote in message:
The confusion probably stems from the fact that this statement wasn't
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've
been easy to miss this fairly minor change at the time it happened and,
given Sun's usual commitment to JAVA backwards compatibility, it'd 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
| From: lyallex |
Date: Saturday, October 27, 2007
|
wrote in message:
wrote in message:
wrote in message:
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've
been easy to miss this fairly minor change at the time it happened and,
given Sun's usual commitment to JAVA backwards compatibility, it'd
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 have 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
wrote in message a class that did not 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
| From: Lew |
Date: Saturday, October 27, 2007
|
wrote in message:
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
| From: =?UTF-8?B?QXJuZSBWYWpow7hq?= |
Date: Saturday, October 27, 2007
|
wrote in message:
wrote in message:
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'll wait until the app needs to be updated for other
reasons.
Arne
| From: lyallex |
Date: Saturday, October 27, 2007
|
wrote in message:
wrote in message:
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 do not think anyone is doing any excoriating(?), they just do not 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 have finally got my head around classloaders.
JAVA still lights my fire even after all these years.
Duncan
Next Message: ""MAN+_-WOMAN_+|=SEX WORLD""
Blogs related to Way too much time spent with Eclipse
Some Thoughts on IDE Choices
Now, I also have another
way of looking at this, which is that IDEs cannot claim mere incremental benefit. What I mean by that is unlike most things, IDEs do not follow a law of linear improvement. I would argue that any
time spent ...
Top 10 reasons to use eclipse…
You don’t
spend too much time in digging into unclear documentation. However good is the software, i want to have a good API documentation and
eclipse has it. Free plugins: Once i have the base platform, i would want to use supporting
...
Dragonfire Factoid: Diabulimia–An Extremely Dangerous Way for ...
Really?? I replied. ?It?s
too bad our two countries don?t get along better. My grandfather
spent some
time in Iran, and he loved it.? (After thirty years in the Air Force, his military adventures are so
much better than mine.)
...
Java IDE Review
It has a TON of plug-ins to do pretty
much everything I wanted, but I admit I didn't
spend much time to figure them out. Overall, it's a really good editor, but a bit quirky. I liked the alt+arrow key combo for indenting code,
...
i was following web site the howto recover ubuntu after installing ...
Tomboy is great, but I forget to restart it, and it doesn’t remind me. you can use
Eclipse. Malachi, google calendar? Why not just save as jpeg from gimp? for development in pretty
much anything. Yeah, but I’m looking for something that
...
Ten Things I Think I Think
7: I Couldn’t Code
Java Without
Eclipse: I say this not because
Eclipse is just the greatest
Java IDE of all
time, but because I’ve invested so
much time learning so many of its tricks. Really any modern
Java IDE probably has equivalent
...