[news.eclipse.technology] Re: Eclipse just seems wrong

[sharples@xxxxxxxxxx (Colin M Sharples)]

Gregg Wonderly wrote:
> There is no such statement in any copy of the spec I've ever read.

I'm sorry, I have to disagree with this assertion. A similar question
posted someone elsewhere prompted me to re-read this part of the JLS, and
as I read it, Eclipse *is* conforming to the spec.

The examples given in section 7.2.1 quite clearly show the directory
structure corresponding to the package hierarchy.

Capter 7 starts off by stating:
"A package can be stored in a file system (§7.2.1) or in a database
(§7.2.2). Packages that are stored in a file system have certain
constraints on the organization of their compilation units to allow a
simple implementation to find classes easily."

In other words, an implementation which stores its source units in a
filesystem does *not* have complete freedom to store them as it sees fit.
Only if the source is stored in a database does the implementation have
the freedom to organize the source as it likes - but it must provide an
export mechanism which will conform to the filesytem rules.

Furthermore, section 7.6 says:
"When packages are stored in a file system (§7.2.1), the host system may
choose to enforce the restriction that it is a compile-time error if a
type is not found in a file under a name composed of the type name plus an
extension (such as .java or .jav) if either of the following is true:
 - The type is referred to by code in other compilation units of the
package in which the type is declared. 
 - The type is declared public (and therefore is potentially accessible
from code in other packages). 
This restriction implies that there must be at most one such type per
compilation unit. This restriction makes it easy for a compiler for the
Java programming language or an implementation of the Java virtual machine
to find a named class within a package; for example, the source code for a
public type wet.sprocket.Toad would be found in a file Toad.java in the
directory wet/sprocket, and the corresponding object code would be found
in the file Toad.class in the same directory."

In other words, every top-level type *must* be found in a directory which
reflects the package of that type.

If your javac implementation allows you to use the -d option to compile
source files which do not live in a directory corresponding to the
package, then it is simply choosing not to enforce this restriction. But
the spec is quite clear that compiler implementations *are* perfectly at
liberty to enforce this restriction, so Eclipse *does* conform to the
requirements of the JLS.

-- 
Colin M Sharples/New Zealand/IBM
IT Architect, IBM Business Consulting Services