Do Eclipse's Refactoring Tools Violate The Java Language Specification?

Question

In Eclipse 3.5, say I have a package structure like this:

 tom.package1
 tom.package1.packageA
 tom.package1.packageB

if I right click on an the tom.package1 package and go to Refactor->Rename, an option "Rename subpackages" appears as a checkbox. If I select it, and then rename tom.package1 to tom.red my package structure ends up like this:

tom.red
tom.red.packageA
tom.red.packageB

Yet I hear that Java's packages are not hierarchical. The Java Tutorials back that up (see the section on Apparent Hierarchies of Packages). It certainly seems like Eclipse is treating packages as hierarchical in this case.

I was curious why access specifiers couldn't allow/restrict access to "sub-packages" in a previous question because I KNEW I had seen "sub-packages" referenced somewhere before.

So are Eclipse's refactoring tools intentionally misleading impressionable young minds by furthering the "sub-package" myth? Or am I misinterpreting something here?

Answer 1

Eclipse can't possibly violate the JLS in this case, because it has nothing to do with compiling or running Java source or bytecode.

The refactoring tools behave as they do because that behaviour is useful to developers. The behaviour is useful to developers because, for many intents and purposes, we do treat packages as hierarchal (a.b.c has some kind of relationship with a.b, even if that relationship is not consistent from project to project). That doesn't mean Java treats them as hierarchal intrinsically.

One example where people treat packages as very hierarchal is in configuring a logging framework such as log4j. Again, it's not intrinsic to log4j, but that's how people use it in practice.

Answer 2

Java's packages are not hierarchical, but Eclipse stores packages on your system's file structure.

tom.package1.packageA is represented on a Windows file system as tom/package1/packageA.

When you ask Eclipse to refactor a package name, you're asking Eclipse to change the name of the file system directory structure.

You can have packages in Eclipse like:

tom.package1.packageA
tom.package2.packageB
tom.package3.packageC

You'll just have different 2nd level file system directories.

Answer 3

Java packages are not hierarchical in the sense that importing everything from package A does not import everything from package A.B.

However, Java packages do correspond directly to the directory structure on the file system, and directories are hierarchical. So Eclipse is doing the correct thing - it is renaming the directory, which automatically changes the name of the parent directory of the renamed directory's children (to state the very obvious).

Answer 4

even java itself has the concept of subpackage:

http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html

java -ea[:<package name>"..." | :<class name> ]

Enable assertions. Assertions are disabled by default.

With no arguments, enableassertions or -ea enables assertions. With one argument ending in "...", the switch enables assertions in the specified package and any subpackages. If the argument is simply "...", the switch enables assertions in the unnamed package in the current working directory. With one argument not ending in "...", the switch enables assertions in the specified class.

If a single command line contains multiple instances of these switches, they are processed in order before loading any classes. So, for example, to run a program with assertions enabled only in package com.wombat.fruitbat (and any subpackages), the following command could be used:

java -ea:com.wombat.fruitbat... <Main Class>