Develop Reference

Bidirectional reference to parent package in Java [duplicate]

I'm working now together with others in a grails project. I have to write some Java-classes. But I need access to an searchable object created with groovy. It seems, that this object has to be placed in the default-package.
My question is: Is there a way to access this object in the default-package from a Java-class in a named package?

You can’t use classes in the default package from a named package.
(Technically you can, as shown in Sharique Abdullah's answer through reflection API, but classes from the unnamed namespace are not in scope in an import declaration)
Prior to J2SE 1.4 you could import classes from the default package using a syntax like this:
import Unfinished;
That's no longer allowed. So to access a default package class from within a packaged class requires moving the default package class into a package of its own.
If you have access to the source generated by groovy, some post-processing is needed to move the file into a dedicated package and add this "package" directive at its beginning.
Update 2014: bug 6975015, for JDK7 and JDK8, describe an even stricter prohibition against import from unnamed package.
The TypeName must be the canonical name of a class type, interface type, enum type, or annotation type.
The type must be either a member of a named package, or a member of a type whose outermost lexically enclosing type is a member of a named package, or a compile-time error occurs.
Andreas points out in the comments:
"why is [the default package] there in the first place? design error?"
No, it's deliberate.
JLS 7.4.2. Unnamed Packages says: "Unnamed packages are provided by the Java SE platform principally for convenience when developing small or temporary applications or when just beginning development".

In fact, you can.
Using reflections API you can access any class so far. At least I was able to :)
Class fooClass = Class.forName("FooBar");
Method fooMethod = fooClass.getMethod("fooMethod", String.class);
String fooReturned = (String)fooMethod.invoke(fooClass.newInstance(), "I did it");

Use jarjar to repackage the jar file with the following rule:
rule * <target package name>.#1
All classes in the default package of the source jar file will move to the target package, thus are able to access.

You can use packages in the Groovy code, and things will work just fine.
It may mean a minor reorganization of code under grails-app and a little bit of a pain at first, but on a large grails project, it just make sense to organize things in packages. We use the Java standard package naming convention com.foo.<app>.<package>.
Having everything in the default package becomes a hindrance to integration, as you're finding.
Controllers seem to be the one Grails artifact (or artefact) that resists being put in a Java package. Probably I just haven't figured out the Convention for that yet. ;-)

just to complete the idea:
From inside default-package you can access objects resided in named packages.

Why do internal classes have to be imported?

In any IDE, when working with a class in a package and I need to use a class from another one, I have to import it. Why doesn't the IDE just automatically import the packages so there is no need to do it manually?

Because sometimes different classes have same 'short' name so the IDE does not know which one you meant. For example if you copy-paste code into your IDE containing Date, it does not know if you meant java.sql.Date or java.util.Date. In these cases the IDE will offer you to choose from all available classes with that name.

First, In Eclipse, you can use Ctrl-SHIFT-O to automatically import anything you need.
From the java package tutorial:
For convenience, the Java compiler automatically imports two entire
packages for each source file: (1) the java.lang package and (2) the
current package (the package for the current file).
The IDE will not import all your packages because 1.
You may not need them, why import them?
More importantly, you can have classes in different packages with the same name, then this will cause name ambiguities.
If a member in one package shares its name with a member in another
package and both packages are imported, you must refer to each member
by its qualified name. For example, the graphics package defined a
class named Rectangle. The java.awt package also contains a Rectangle
class. If both graphics and java.awt have been imported, the following
is ambiguous.
This would cause unnecessary headache making sure you are always referring to the correct package. By importing packages and classes yourself, you can be sure that you are always using the specific class that you intended to.

This is my thought. Think this way,
Suppose you have two classes having the same name in different packages like this, then how does IDE resolve the package import? How does it know which SendFormAction to be imported?
So generally IDE's give you an option to import the packages [cntrl+shift+O in eclipse IDE]
and if there is confusion, it will ask you which one to import.
com.xyz.action [package]
SendFormAction.java
com.abc.action [package]
SendFormAction.java

How are these classes able to access the default package (post-compile)?

This is taken from the bytecode of Minecraft. Most of the jar's classes are found in the default package, however there is another package, "net.minecraft.client", which has the main class (Minecraft.class) that runs the game loop, sets up OpenGL, etc. I don't have the source, but if I open up Minecraft.class in JD-Gui, it has the following import setup:
package net.minecraft.client;
import aaa;
import aai;
import ajq;
import ajv;
import akf;
import aki;
import aqx;
import aqz;
import ara;
import arb;
... (many more classes from the default package)
public abstract class Minecraft implements Runnable, mc {
...
}
How does this work? Let's say I have a folder with a similar setup (default classes that need to be accessed by other packages) and want to compile it with a batch file. What method of compiling could replicate this result?

This is taken from the source of Minecraft.
I don't think so. (EDIT: The question was edited to make this "bytecode" - which doesn't make much sense, as bytecode isn't Java source code. Anyway...)
How does this work?
It doesn't, fundamentally. The code you're looking at in JD-Gui isn't the original source code - it's code which represents the bytecode as accurately as JD-Gui is able to manage.
I strongly suspect the original source code does use packages, but then uses an obfuscator of some kind to rename the classes and put them in the default package. I strongly suspect this isn't the only kind of change which leaves valid bytecode which couldn't actually be directly compiled from valid source code. (For example, I strongly suspect there are method names which are valid in bytecode but not in source code.)
Let's say I have a folder with a similar setup (default classes that need to be accessed by other packages) and want to compile it with a batch file. What method of compiling could replicate this result?
You wouldn't. You'd have source code set up using packages (as all sane, non-trivial Java code does), compile it and then post-process the bytecode.

Java String import

I have one doubt. When we use ArrayList or HashMap in Java, we have to import java.util.ArrayList or java.util.HashMap. But when we use String, it doesn't require the import statement. Can anyone clarify, why?

String is present in package java.lang which is imported by default in all java programs.

Everything in the java.lang package is implicitly imported (including String) and you do not need to do so yourself. This is simply a feature of the Java language. ArrayList and HashMap are however in the java.util package, which is not implicitly imported.
The package java.lang mostly includes essential features, such a class version of primitives, basic exceptions and the Object class. This being integral to most programs, forcing people to import them is redundant and thus the contents of this package are implicitly imported.

Java compiler imports 3 packages by default.
1. The package without name
2. The java.lang package(That's why you can declare String, Integer, System classes without import)
3. The current package (current file's package)
That's why you don't need to declare import statement for the java.lang package.

I'm bit late here, but just for new reader, According to my understanding
String is present in package java.lang which is imported by default at class loading time by rt.jar which is present at class path. Bootstrap Classloader (Primodial ClassLoader) is responsible for loading rt.jar.
We always include rt.jar in our classpath, otherwise, you don't have access to core java classes e.g. java.lang.String, java.lang.Thread, java.util.ArrayList or java.io.InputStream etc. and all other classes from Java API.
rt.jar will always reside under $JAVA_HOME/jre/lib and you can open it by using WinRAR or WinZip client

import java.lang.String;
This is an unnecessary import. java.lang classes are always implicitly imported.
This means that you do not have to import them manually (explicitly).

import command in Java

What exactly is the difference between the following commands:
import javax.swing.JPanel;
and
import javax.swing.*;
If I use second one, compiler will import all files from swing or only the needed ones, will be any difference in size of the executable? thanks in advance

The first one imports only javax.swing.JPanel class.
The second one imports all classes which are present in javax.swing package, excluding the classes in its subpackages, such as the ones in javax.swing.event package, etc.
The import keyword does not literally import the given classes. It basically just points the compiler to the classes which are to be present in the classpath in order to be able to locate the dependency classes and thus successfully compile the code. The size of the compiled class depends on the size of the sole source code (this includes the import statements), it does not include the size of the imported classes.
See also
Java tutorial - Using package members

First of all, in Java you don't produce executables (well, you can, but not directly). At run time, the JVM will load whatever is needed for the program to run from a library that is already on the disk, so your executable won't grow.
Having a catch-all import merely reduces the need to explicitly list everything you are importing. It's actually often discouraged because that could later create conflicts (e.g., what if you were already obtaining x.y.Foo and now there is also w.v.Foo in your w.f.* import).
Some IDEs (such as Eclipse) can fix the latter into the former for you automatically.

There is no difference in terms of execution of your application. Only difference is during the compile time it may be a bit (unnoticeable in most cases) slower. A lot of people prefer the .* over fully qualified packages because of code readability.
I asked this question myself once too and I found this explanation to be pretty good.

The first one will import that specific package but the second one will import all packages in swing. The first one will be smaller because it is only one package.

for example, import java.lang.* will import all the classes that exist in package java.lang (but no subpackages). By all I mean any class we really use in project, nothing what is not required will be imported (so I was taught).