It seems there a 'default package' in eclipse.
What's it?
Leaving a class without a package, i.e. in the default package, is fine if you're just hacking something up for an example or something.
However, as soon as you start adding more and more classes without packages you'll soon find things getting messy.
The main reason not to use the default package is the potential for conflicts with other code. This is where it is helpful to use the "reverse domain name" style of package naming such as "com.stackoverflow.utils.MagicConverter".
Use packages.
The default package is for classes that do not have any package declared. However this is discouraged (eclipse warns you) - you can't import these classes.
Related
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.
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
Classes in tests package cannot find classes in default package.
If I move to classes in default package to tests, the errors disappear.
I'd like to know the reason of these errors.
To have access to classes from another package, you should import this package.
But according to JLS you can't do it with default unnamed package.
Because the class is situated in the different package and should be available to the current class via import directive. And because the class you want to import is in the default package that has not name, you can't do that, rather than move to the named package and apply the above.
Check if you have a dependency on that module in which the AddChild1_wy_v1,java is located
If it's a library then check if it is imported to your project and can be used
Import the class to the class from which you are trying to use it
???
Profit
I think it is a bad idea to put classes in the default package. Create a new explicitly named package for you classes and move them all there. If you use Eclipse's Refactor->Move menu option, it will put in all the tedious package declarations for your classes.
Then your tests can import the package.
So, I've got this problem - a strange problem. I have a library as part of an IDEA project - in which all the code is publicly visible under 'tk.*' (IE: all classes exist in sub-packages of tk). Should the attempt be made to import a class residing within that package IDEA highlights the import statement (only th 'tk' mind you - which is strange enough), citing the reason mentioned later. Despite the apparent "errors", the project (consisting of a formidable number of files) compiles successfuly - very much so, infact.
Info:
The highlight reason (when you hover over the aforementioned highlight): 'tk' is not public in ''
Note about this: the file importing from said package IS NOT in the default package.
It would seem that the importing from packages residing in other libraries is not found at fault by IDEA
The class(es) imported by aforementioned file(s) are not package-private, nor protected, nor private - they are public
The project's path settings should be correct, however I am open to the suggestion that these may be at fault
Notes:
Sorry if this quiestion reads wierdly - I'm rather distracted by the environment in which I currently reside.
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.