Complaint about Java class package - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

Complaint about Java class package

Complaint about Java class package# Java - 爪哇娇娃

k*r2009-06-27 07:06

1 楼

Package information is stored in two places:
1. package declaration in class files
2. physical file location
This really goes against some design principles - you don't
want to store the same info twice and have to keep them in
sync if you change any of them.
For example, if you want to put a set of classes into a
different package, you would have to modify every single
source file, as well as physically move the files to a
different directory. Moving files is trivial but modifying
every single

c*t2009-06-27 07:06

2 楼

I disagree. When you get multiple source directories etc, it is often
difficult and confusing to know the root of the package directory without
some pointers. The directory structure and the package decla help the
recognition of the package structure pretty easily. Besides, good IDEs
take care of new class file creation and refactoring etc.

【在 k***r 的大作中提到】

: Package information is stored in two places:
: 1. package declaration in class files
: 2. physical file location
: This really goes against some design principles - you don't
: want to store the same info twice and have to keep them in
: sync if you change any of them.
: For example, if you want to put a set of classes into a
: different package, you would have to modify every single
: source file, as well as physically move the files to a
: different directory. Moving files is trivial but modifying

g*g2009-06-27 07:06

3 楼

We all know why we need package name, to make classes unique and
avoid confliction as much as possible.
Now package info is meta data or you can consider it part of class
name and you certainly don't want it to get lost in transportation.
Now consider your proposal, let's remove 1 and count on 2 to determine
pacakge name.
If you have a class under abc directory, and you classpath contains
both the root and abc directory, what's gonna be the class name?
abc.xxx or xxx?
On the other hand, 2 can be

【在 k***r 的大作中提到】

k*r2009-06-27 07:06

4 楼

I think IDE's responsibility is to make thing easier, not to
fix a (Java language) design problem. Based on this principle,
it's IDE's responsibility to deduce the package name of any
class the developer is working on, and make it visible to
the developers, since the information is there (directory
structures.)
IDE certainly can help with refactoring. But I think it
shouldn't have to do this, if the package names aren't in
the class. And things still work if they aren't.
PS: as a matter of fact,

【在 c*****t 的大作中提到】

: I disagree. When you get multiple source directories etc, it is often
: difficult and confusing to know the root of the package directory without
: some pointers. The directory structure and the package decla help the
: recognition of the package structure pretty easily. Besides, good IDEs
: take care of new class file creation and refactoring etc.

s*n2009-06-27 07:06

5 楼

neither language spec nor javac requires such directory structure.
however in the spec, 7.2.1, this kind of file storage is suggested
"as an extremely simple example"
javac does not care where a source file is located; actually it
cannot check, since it doesn't know the 'root package' directory.
nevertheless, this is the de facto standard, for all developers
and tools that must find the source file from a full class name.

【在 k***r 的大作中提到】

: I think IDE's responsibility is to make thing easier, not to
: fix a (Java language) design problem. Based on this principle,
: it's IDE's responsibility to deduce the package name of any
: class the developer is working on, and make it visible to
: the developers, since the information is there (directory
: structures.)
: IDE certainly can help with refactoring. But I think it
: shouldn't have to do this, if the package names aren't in
: the class. And things still work if they aren't.
: PS: as a matter of fact,

k*r2009-06-27 07:06

6 楼

A decision needs to be made here. The decision can be one of these:
1. both are fine (both abc.xxx and xxx)
2. the first (whichever is declared in classpath first)
3. the deepest (abc.xxx)
4. the shallowest (xxx)
And I think #1 makes most sense. You can address a class like
that either way. Then again, having class path to a sub directory
may not be a good idea in the first place.
So overall I don't see any obstacles removing "package" from
classes.
This is definitely messy so I'm not suggestin

【在 g*****g 的大作中提到】

: We all know why we need package name, to make classes unique and
: avoid confliction as much as possible.
: Now package info is meta data or you can consider it part of class
: name and you certainly don't want it to get lost in transportation.
: Now consider your proposal, let's remove 1 and count on 2 to determine
: pacakge name.
: If you have a class under abc directory, and you classpath contains
: both the root and abc directory, what's gonna be the class name?
: abc.xxx or xxx?
: On the other hand, 2 can be

k*r2009-06-27 07:06

7 楼

You would want to do that anyway, not because there is a
standard/requirement or de fact to standard. So the information
is there. I'd rather this be a requirement, than the package
declaration in classes, because the former actually has great
value (in terms of organizing code) while the latter is purely
excessive if the file structure is required, or if everybody
is doing it that way (which justifies making it a requirement.)

【在 s******n 的大作中提到】

: neither language spec nor javac requires such directory structure.
: however in the spec, 7.2.1, this kind of file storage is suggested
: "as an extremely simple example"
: javac does not care where a source file is located; actually it
: cannot check, since it doesn't know the 'root package' directory.
: nevertheless, this is the de facto standard, for all developers
: and tools that must find the source file from a full class name.

s*n2009-06-27 07:06

8 楼

since it is part of identifier name, a critical concept to any language,
it should be included in the 'compilation unit'. a file path is only
meaningful in the context of a directory based file system; it is
widely used but still limited. imagine we want to view a source in a
web page - we want the source to be self contained.

【在 k***r 的大作中提到】

: You would want to do that anyway, not because there is a
: standard/requirement or de fact to standard. So the information
: is there. I'd rather this be a requirement, than the package
: declaration in classes, because the former actually has great
: value (in terms of organizing code) while the latter is purely
: excessive if the file structure is required, or if everybody
: is doing it that way (which justifies making it a requirement.)

k*r2009-06-27 07:06

9 楼

A web loaded jar/class file shouldn't be that different
from a local file, as long as some conventions are defined.
But you actually gave a good example by mentioning web:
the HTML page relations are all file system structure based,
and it can be relative. And it works perfectly :)

【在 s******n 的大作中提到】

: since it is part of identifier name, a critical concept to any language,
: it should be included in the 'compilation unit'. a file path is only
: meaningful in the context of a directory based file system; it is
: widely used but still limited. imagine we want to view a source in a
: web page - we want the source to be self contained.

g*g2009-06-27 07:06

10 楼

It's going to be a mess when it's a confusion even for a simple
example like this. In reality, it's not worth the trouble. Java
is pretty strict in the syntax, and this is one of the places
you want to be strict, a classnotfound exception in startup is
way better than a nosuchmethod exception in runtime.

【在 k***r 的大作中提到】

: A web loaded jar/class file shouldn't be that different
: from a local file, as long as some conventions are defined.
: But you actually gave a good example by mentioning web:
: the HTML page relations are all file system structure based,
: and it can be relative. And it works perfectly :)

j*z2009-06-27 07:06

11 楼

You are right. However it is small issue. IDE can perform refactor and sync
up file easily if package name is changed.

m*t2009-06-27 07:06

12 楼

They are actually really not the same thing - 1 is part of
a public API, while 2 is an implementation detail (of the
underlying classloader implementation)
The package delaration in a class, com.foo.Bar, is an explicit
contract that defines two things:
I. (The obvious) this class can be addressed by string
"com.foo.Bar",
II. (The not-so-obvious) in the rest of the class definition,
whenever there is a member declared to be "package accessible",
it is meant to be accessible to code _only_ from p

【在 k***r 的大作中提到】

g*g2009-06-27 07:06

13 楼

I like the DRY principle, have package info and class def in
two places are gonna be a mess.

【在 m******t 的大作中提到】

:
: They are actually really not the same thing - 1 is part of
: a public API, while 2 is an implementation detail (of the
: underlying classloader implementation)
: The package delaration in a class, com.foo.Bar, is an explicit
: contract that defines two things:
: I. (The obvious) this class can be addressed by string
: "com.foo.Bar",
: II. (The not-so-obvious) in the rest of the class definition,
: whenever there is a member declared to be "package accessible",

k*r2009-06-27 07:06

14 楼

HTML/HTTP obviously doesn't have a problem with this ...

【在 m******t 的大作中提到】

m*t2009-06-27 07:06

15 楼

Because they do not have the same design goal? An html
page never declares that it's only linkable from pages in
the same directory, for instance.
The ability to relatively address another entity is highly desirable
to html pages, but not much so for java classes.

【在 k***r 的大作中提到】

: HTML/HTTP obviously doesn't have a problem with this ...

k*r2009-06-27 07:06

16 楼

Implicit reference shouldn't be a problem, though.
I actually think it's a "nice to have".

【在 m******t 的大作中提到】

:
: Because they do not have the same design goal? An html
: page never declares that it's only linkable from pages in
: the same directory, for instance.
: The ability to relatively address another entity is highly desirable
: to html pages, but not much so for java classes.

F*n2009-06-27 07:06

17 楼

If you think twice, it is actually the same with URL and URI.
Relative name resolution equals to Class name resolution with imports. You
can move them around if they are in the same package or if imports are
correct.

【在 k***r 的大作中提到】