Packages demystified for a newbie

A

Andersen

Hi,

Having classes inside a subdirectory X implies they are in a different
package with the name X?
Having a package with name X implies they are in a subdirectory with name X?

As I understand classes have to be Public in order to be accessed from
other packages. How about sub-packages, i.e. Does a class under the
package x.y.z need to be public in order to be referenced via a class in
the package x.y ?

Regards,
Andersen
 
A

Antti S. Brax

Having classes inside a subdirectory X implies they are in a different
package with the name X?
Having a package with name X implies they are in a subdirectory with name X?

According to common (and best known) practise. But in the end,
you may have a file in directory X when it's package statement
says Y and it will compile just fine (as long that the code in
the class does not assume that it is in package X).
As I understand classes have to be Public in order to be accessed from
other packages. How about sub-packages, i.e. Does a class under the
package x.y.z need to be public in order to be referenced via a class in
the package x.y ?

Yes. There is no language defined superpackage-subpackage
hierarchy between packages.
 
T

Thomas Weidenfeller

Andersen said:
Hi,

Having classes inside a subdirectory X implies they are in a different
package with the name X?
Having a package with name X implies they are in a subdirectory with
name X?

Beginner's questions are best asked in comp.lang java.help. That said ...

Packages and subdirectories are somewhat related in common Java
implementations, but they need not be. Packages are a concept for
grouping and ordering classes. The common java implementations then map
the package organization to a subdirectory structure, so when Java needs
to find a class in a particular package it looks in a corresponding
subdirectory.

The package to which a class belongs is not defined by its subdirectory.
It is defined by the package statement in the source code and the full
name of the class as generated by the compiler from that information.
But in order to make it possible for Java to find the class when needed,
it should be placed in a subdirectory which matches the package.
As I understand classes have to be Public in order to be accessed from
other packages. How about sub-packages, i.e. Does a class under the
package x.y.z need to be public in order to be referenced via a class in
the package x.y ?

Packages *do not* form a hierarchy. There is no such thing as
sub-packages. Package x.y and x.y.z are not related, other than that
someone decided that both package names happen to start with x.y. Such a
naming is convenient for the programmer, but Java does not care about
the similar names. x.y and x.y.z are as different for Java as x.y and a.b.

The fact that some classes end up in subdirectories of other classes is
just an artifact of the mapping of package names to directories.

http://java.sun.com/docs/books/tutorial/java/interpack/index.html

has more.

/Thomas
 
A

Andersen

Thomas said:
Packages *do not* form a hierarchy. There is no such thing as

I know from Bloch's Effective Java that a class that is defined to be
Public is supposed to be part of the "public API" of your software,
which implies you will support it and somehow be backward compatible as
external developers might start using your code.

Now I have the unfortunate situation where two "layers" of this software
I am writing are related intimately code-wise, but not conceptually.
Concretely, one is a marshaller/unmarshaller, while the other is
handlers for those messages which the marshaller can deal with.
Conceptually I would like to separate the marshaller/unmarshaller from
the handlers, by for example putting them in a different package. Then
however, I need to make the classes Public, as the handlers need to
access them. But if I do that, I will be exposing those classes inside
the package as part of my "public API" (in some loose sense). Doing
that, however, will contradict the reason for a separate marshaller, as
I wanted to have a marshaller that I could completely rewrite or change
at a later stage. The whole whole concept of "modules" or packages seem
to be weak in JAVA, it would have been nice to have hiearachies. It
seems the module concept is much better in a language like ADA or Modula.

Regards,
Andersen
 
T

Thomas Weidenfeller

Andersen said:
I know from Bloch's Effective Java that a class that is defined to be
Public is supposed to be part of the "public API" of your software,
which implies you will support it and somehow be backward compatible as
external developers might start using your code.

"Technically" this is easy to "fix". Don't provide documentation for
these classes, and tell everyone that the particular classes are not
part of the API. Sun does the same, see
http://java.sun.com/products/jdk/faq/faq-sun-packages.html

Java programmers are used to this.

Or provide them non-public in the same package, but:
Now I have the unfortunate situation where two "layers" of this software
I am writing are related intimately code-wise, but not conceptually.
Concretely, one is a marshaller/unmarshaller, while the other is
handlers for those messages which the marshaller can deal with.
Conceptually I would like to separate the marshaller/unmarshaller from
the handlers, by for example putting them in a different package.

Just putting them in a different jar would also do. Instead of logically
separating them via packages, separate them physically via jars.
I wanted to have a marshaller that I could completely rewrite or change
at a later stage.

Just replace the jar which contains the public marshaller code.
The whole whole concept of "modules" or packages seem
to be weak in JAVA, it would have been nice to have hiearachies.

There are worse things than that in other languages. E.g. in C++ this
was supposed to be "fixed" with friends. That one opened up endless
opportunities for messing things up.
It
seems the module concept is much better in a language like ADA or Modula.

If you need ADA or Modula behavior, then maybe using these languages is
an alternative.

/Thomas
 
J

John C. Bollinger

Andersen said:
Now I have the unfortunate situation where two "layers" of this software
I am writing are related intimately code-wise, but not conceptually.

I'm sorry, but that doesn't make sense. If two collections of classes
are not conceptually related then why in the world would they need to
have related code?
Concretely, one is a marshaller/unmarshaller, while the other is
handlers for those messages which the marshaller can deal with.

Maybe you mean something different by "not conceptually [related]" than
I read into it, but your description there doesn't seem to agree about
the relatedness. As soon as you write "which the marshaller [...]" you
are stipulating a relationship at the conceptual level at least.
Conceptually I would like to separate the marshaller/unmarshaller from
the handlers, by for example putting them in a different package. Then

Why isn't it sufficient that the behaviors be implemented by different
classes?
however, I need to make the classes Public, as the handlers need to
access them. But if I do that, I will be exposing those classes inside
the package as part of my "public API" (in some loose sense). Doing
that, however, will contradict the reason for a separate marshaller, as
I wanted to have a marshaller that I could completely rewrite or change
at a later stage. The whole whole concept of "modules" or packages seem
to be weak in JAVA, it would have been nice to have hiearachies. It
seems the module concept is much better in a language like ADA or Modula.

I think you overestimate the usefulness of package hierarchies and
underestimate the additional complication and grief they would bring,
but that's beside the point. If you insist upon segregating these
classes into different packages, then you could still hide the
marshaller's implementation by giving it default access in its package
but having it implement a public interface (in the same or a different
package) by which it is used. This scheme is used in several places
through the platform API -- JDBC and JAXP, for instance, both make heavy
use of it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top