Why "package" keyword and .h?

Question

1. Why in the files that are in a Java package I should write the "package" thing in it? It's not indirectly assumed that if it's in the directory, then it's in the package?

2. I come from the C++ world. I always imported the .h of the classes which I need from other files that use that class (I mean, I want only to "show" the header, not the implementation). But now I'm a bit confused about the imports in Java. How is this done in Java?

Answer 1

1. No, that is not assumed. After all, what's my package called? com.mypackage.stuff? src.com.mypackage.stuff? myproject.com.mypackage.stuff? C.Users.makakko.workspace.myproject.src.com.mypackage.stuff?

   If you only base the package off of the folders, is it relative to the drive root? What if the project is developed on a different drive letter on a different machine? Is it relative to the location of javac.exe? Again, what about different install directories? What about the working directory when running javac? But you can specify a location for javac to find your sourcefiles in. What if you want to do a simple test program, or teach someone Java who has never programmed before; do you have to use/explain the whole concept of package structure?

   If you omit the package specifier, then you're still in a package. It's just the "default package", which has no name.

2. Header files are more of an artifact from the way C needs to be compiled than a way to achieve information hiding. In C, a method must be defined before it can be referenced. If you want to have several methods which refer to one another, you have to define all of them before using any of them, hence the header. The headers in C++ carry over from that, but changes in C++ alter the necessity of headers.

   In Java, the compiler will look at all of your method and class signatures before doing anything which required the method/class. The function served by headers is put into the compiler itself. You can't depend on the header for your information hiding, because

   1. Code can be placed within a header file

   2. Unless you use real information hiding such as a separate library, a programmer can go find the c/cpp file that matches the header without issue

   Similarly in Java, you can only get real information hiding by removing the source. Once you've made the source inaccessible, you expose the API with public/protected classes, enums, and interfaces. For bonus points, write explanatory JavaDoc comments for everything, and run javadoc.exe over your source to produce separate documentation for anyone who will use your package(s).

Answer 2

1) The package declaration has to match the directory hierarchy on the project.

If I use package com.stackoverflow.bakkal; in Car.java then the following hierarchy is expected.

com/
|-- stackoverflow/
|   `-- bakkal/
|       |-- Car.java

2) If you want to hide an implementation you can use interface in Java instead of a class. Then distribute the actual implementations in .class files or JARs for example.

Mmm but an interface cannot be instantiated...

The interface works like a prototype in C++ to some extent. You have the contract, then the actual implementation comes from elsewhere.

I want to instantiate a class, but without giving the implementation, only the prototype

That's not possible even C++, how can you instantiate something without having its actual implementation? In C++ you'd still need to link to the object files. In Java you use .class files.

Answer 3

Packages are not assumed because Java's philosophy is that it's better to be explicit than implicit/assumed.

It does give you the ability to access anything in your current package, but anything outside needs to be explicitly imported. (I believe Java.lang is the exception because that contains so much base functionality such as String that there wouldn't be a single package that wouldn't use it).

This is also why you tend to see:

import java.util.ArrayList;
import java.util.LinkedList;

instead of:

import java.util.*;

This can seem annoying until the one day you are trying to figure out someone elses code and it hits you how much harder this would be if things were hidden/implied.

If you use Eclipse, Netbeans or IntelliJ, you'll never even notice because of two features.

First of all, if you hit ctrl-space in the middle of typing a class name it will not only complete the class name for you, but it will also automatically add it to the imports list.

Secondly if you ever get to where imports are "Wrong" or you don't use ctrl-space expansion, you can just type ctrl-shift-o (eclipse) to have it "Fix imports". This will automatically import things that need importing and remove imports you no longer need. Depending on your settings it will also expand or collapse *'s.

Once you get a system down you never even consider imports.