So I'm pretty new to Java and this may be a question conceived due to some misconceptions, but I'm just curious: Do all "forms" (I guess different JREs? Or VMs?), for example, I've heard of Dalvik, of Java include an automatically imported System.out? What makes them different from the standard one i downloaded from Oracle to learn with? Inform me if I'm not understanding any concepts correctly, please.
In addition to the Java language specification which, in section 7.3, says that
Every compilation unit implicitly imports every public type name declared in the predefined package java.lang, as if the declaration import java.lang.*; appeared at the beginning of each compilation unit immediately after any package declaration. As a result, the names of all those types are available as simple names in every compilation unit.
there is also a Java Compatibility Kit which any conforming implementation of Java must pass. Thus, anything which wants to call itself "Java" must include all the parts of Java, including System.out.
I was trying to understand the general hierarhcy of Java packages.
If you consult this Oracle page, it seems that there are 3 main packages:
java, javax and org.
All packages, in Java platform 7, start with one of these three.
Are these ones part of a bigger package?
I'd love to see a complete tree, but the one offered by Oracle is very confusing, because it's too detailed.
Another thing I did not undestand is why packages like "java.awt" and "java.awt.color", or "java.lang" and "java.lang.annotation", are put by Oracle on the same level.
I did read online that if you import a "parent-package", you don't import any classes form the "child-packages", and that makes sense. However, it's hard to think that there isn't a relation between java.awt and java.awt.color; It seems intuitive that the least is contained in the fromer.
So, given my current understanding, I would draw a tree that look like this:
No, there is no "bigger" package. The structure evolved over time, with different ideas and marketing influencing the naming.
You do not import packages in java, just classes. So before Java9, it does not really matter much even in which package a class resides except for the package-protected visibility scope (which is not used that much), and the lack of need to import classes from the same package.
Often classes from a subpackage are used by classes in a parent package, but not the other way round. But there is no strict rule about this.
Is the use of Java's default package a bad practice?
Yes, it is. Ideally, package names should be globally unique, to avoid naming collisions. Using the default package breaks this convention. It's also impossible to import a class from the default package.
Why do unnamed packages exist at all, if it's such a bad idea? From the JLS §7.4.2:
Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just beginning development.
There are problems on many different levels:
you can't import classes in the default package from classes that are not
you will get class loading problems if you try to resolve the default package in multiple artifacts
you can no longer use the default and protected scope like you normally can
there's no obvious distinction between your code and other code
Yes, it is. The problem is that it is not possible to import classes from the default package.
I was doing some experiments today in android source.
Let me tell the complete thing,
I compiled framework.jar from android source and decompiled it and generated smali source and kept it aside. Then from CyanogenMod repo I added the commits of a feature to android source and compiled framework.jar again and again decompiled smali source to see the changes in terms of smali so that I can port them over to my ROM.
The feature I am porting requires importing of certain classes e.g import dalvik.system.VMRuntime and extra coding for utilization of those imported classes. So now my problem is, I am only able to see the extra coding i.e utilization of those classes in the smali code but not those imports. So when I port only the smali code I get java.lang.NoSuchMethodError in logcat which shows that it is unable to find that method. The reason is clear because the necessary class is not imported then how to do it in smali code? i see no way to do that in smali and due to which the newly introduced methods don't work.
Any feasible solution to this?
The only thing an import does in java is make it so that you can mention a class without having to specify the full package name. In smali, there are no imports - everything always uses the fully qualified class name that includes the package.
As such, your problem is definitely not related to imports. It sounds like you are trying to use a method that simply doesn't exist on the device.
You can disassemble the framework jars from your device and find the definition of the dalvik.system.VMRuntime and see what methods are available. Or alternately add some reflection calls and log the info to logcat.
It's worth noting that VMRuntime is not part of the public API, and it may not be present or consistent on all devices or future versions of Android.
(I don't know smali, so there may be a much better solution)
No Java program ever requires any import statement. To use e.g. ArrayList you need to either import it or refer to it in full, as java.util.ArrayList.
There is a significant difference between e.g. a C++ #include and a Java import. A C++ #include directly inserts code in your program, typically the declaration for a class you are using. The process of getting the declarations is divided into two stages in Java. First the compiler determines the fully qualified class name, then it uses its own library and the classpath to find the declaration for that name. Java import is used only in calculating the fully qualified class name, and so is not needed for any class that is only referred to by its fully qualified name.
Perhaps you could pre-process the code you are adding to replace e.g. VMRuntime with dalvik.system.VMRuntime etc. so that you can compile it with no imports.
Here is an example of a short program that uses java.util classes, in different ways, without any import:
public class Test {
public static void main(String[] args) {
java.util.List<String> list = new java.util.ArrayList<String>();
list.add("bbb");
list.add("aaa");
java.util.Collections.sort(list);
System.out.println(list);
}
}
I recently started learning Java and found it very strange that every Java public class must be declared in a separate file. I am a C# programmer and C# doesn't enforce any such restriction.
Why does Java do this? Were there any design considerations?
Edit (based on a few answers):
Why is Java not removing this restriction now in the age of IDEs? This will not break any existing code (or will it?).
I have just taken a C# solution and did just this (remove any file that had multiple public classes in them) and broke them out to individual files and this has made life much easier.
If you have multiple public classes in a file you have a few issues:
What do you name the file? One of the public classes? Another name? People have enough issues around poor solution code organization and file naming conventions to have one extra issue.
Also, when you are browsing the file / project explorer its good that things aren't hidden. For example you see one file and drill down and there are 200 classes all mushed together. If you have one file one class, you can organize your tests better and get a feel for the structure and complexity of a solution.
I think Java got this right.
According to the Java Language Specification, Third Edition:
This restriction implies that there must be at most one such type per compilation unit. This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class within a package; for example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory.
Emphasis is mine.
It seems like basically they wanted to translate the OS's directory separator into dots for namespaces, and vice versa.
So yes, it was a design consideration of some sort.
From Thinking in Java
:
There can be only one public class per compilation unit (file).
The idea is that each compilation unit has a single public interface represented by that public class. It can have as many supporting “friendly” classes as you want. If you have more than one public class inside a compilation unit, the compiler will give you an error message.
From the specification (7.2.6)
When packages are stored in a file system (?7.2.1), the host system may choose to enforce the restriction that it is a compile-time error if a type is not found in a file under a name composed of the type name plus an extension (such as .java or .jav) if either of the following is true:
The type is referred to by code in other compilation units of the package in which the type is declared.
The type is declared public (and therefore is potentially accessible from code in other packages).
This restriction implies that there must be at most one such type per compilation unit.
This restriction makes it easy for a compiler for the Java programming language or an implementation of the Java virtual machine to find a named class within a package; for example, the source code for a public type wet.sprocket.Toad would be found in a file Toad.java in the directory wet/sprocket, and the corresponding object code would be found in the file Toad.class in the same directory.
In short: it may be about finding classes without having to load everything on your classpath.
Edit: "may choose" seems like it leaves the possibility to not follow that restriction, and the meaning of "may" is probable the one described in RFC 2119 (i.e. "optional")
In practice though, this is enforced in so many platform and relied upon by so many tools and IDE that I do not see any "host system" choosing to not enforce that restriction.
From "Once upon an Oak ..."
It's pretty obvious - like most things are once you know the design reasons - the compiler would have to make an additional pass through all the compilation units (.java files) to figure out what classes were where, and that would make the compilation even slower.
(Note:
the Oak Language Specification for Oak version 0.2 (postcript document): Oak was the original name of what is now commonly known as Java, and this manual is the oldest manual available for Oak (i.e. Java).
For more history on the origins of Java, please have a look at the Green Project and Java(TM) Technology: An Early History
)
It's just to avoid confusion in the sense that Java was created with simplicity in mind from the perspective of the developer. Your "primary" classes are your public classes and they are easy to find (by a human) if they are in a file with the same name and in a directory specified by the class's package.
You must recall that the Java language was developed in the mid-90s, in the days before IDEs made code navigation and searching a breeze.
If a class is only used by one other class, make it a private inner class. This way you have your multiple classes in a file.
If a class is used by multiple other classes, which of these classes would you put into the same file? All three? You would end up having all your classes in a single file...
That's just how the language designers decided to do it. I think the main reason was to optimize the compiler pass-throughs - the compiler does not have to guess or parse through files to locate the public classes. I think it's actually a good thing, it makes the code files much easier to find, and forces you to stay away from putting too much into one file. I also like how Java forces you to put your code files in the same directory structure as the package - that makes it easy to locate any code file.
It is technically legal to have multiple Java top level classes in one file. However this is considered to be bad practice (in most cases), and some Java tools may not work if you do this.
The JLS says this:
When packages are stored in a file
system (§7.2.1), the host system may
choose to enforce the restriction that
it is a compile-time error if a type
is not found in a file under a name
composed of the type name plus an
extension (such as .java or .jav) if
either of the following is true:
The type is referred to by code in other compilation units of the package in which the type is declared.
The type is declared public (and therefore is potentially accessible from code in other packages).
Note the use of may in the JLS text. This says that a compiler may reject this as invalid, or it may not. That is not a good situation if you are trying to build your Java code to be portable at the source code level. Thus, even if multiple classes in one source file works on your development platform, it is bad practice to do this.
My understanding is that this "permission to reject" is a design decision that is intended in part to make it easier to implement Java on a wider range of platforms. If (conversely) the JLS required all compilers to support source files containing multiple classes, there would be conceptual issues implementing Java on a platform which wasn't file-system based.
In practice, seasoned Java developers don't miss being able to do this at all. Modularization and information hiding are better done using an appropriate combination of packages, class access modifiers and inner or nested classes.
Why is java not removing this restriction now in the age of IDEs? This will not break any existing code (or will it?).
Now all code is uniform. When you see a source file you know what to expect. it is same for every project. If java were to remove this convention you have to relearn code structure for every project you work on, where as now you learn it once and apply it everywhere. We should not be trusting IDE's for everything.
Not really an answer to the question but a data point none the less.
I grepped the headers of my personal C++ utilty library (you can get it yourself from here) and almost all of the header files that actually do declare classes (some just declare free functions) declare more than one class. I like to think of myself as a pretty good C++ designer (though the library is a bit of a bodge in places - I'm its only user), so I suggest that for C++ at least, multiple classes in the same file are normal and even good practice.
It allows for simpler heuristics for going from Foobar.class to Foobar.java.
If Foobar could be in any Java file you have a mapping problem, which may eventually mean you have to do a full scan of all java files to locate the definition of the class.
Personally I have found this to be one of the strange rules that combined result in that Java applications can grow very large and still be sturdy.
Well, actually it is an optional restriction according to Java Language Specification (Section 7.6, Page No. 209) but followed by Oracle Java compiler as a mandatory restriction. According to Java Language Specification,
When packages are stored in a file system (§7.2.1), the host system
may choose to enforce the restriction that it is a compile-time error
if a type is not found in a file under a name composed of the type
name plus an extension (such as .java or .jav) if either of the
following is true:
The type is referred to by code in other compilation units of the package in which the type is declared.
The type is declared public (and therefore is potentially accessible from code in other packages).
This restriction implies that there must be at most one such type per
compilation unit. This restriction makes it easy for a Java compiler
to find a named class within a package.
In practice, many programmers choose to put each class or interface
type in its own compilation unit, whether or not it is public or is
referred to by code in other compilation units.
For example, the source code for a public type wet.sprocket.Toad would
be found in a file Toad.java in the directory wet/sprocket , and the
corresponding object code would be found in the file Toad.class in the
same directory.
To get more clear picture let's imagine there are two public classes public class A and public class B in a same source file and A class have reference to the not yet compiled class B. And we are compiling (compiling-linking-loading) class A now while linking to class B compiler will be forced to examine each *.java files within the current package because class B don’t have it’s specific B.java file. So In above case, it is a little bit time consuming for the compiler to find which class lies under which source file and in which class the main method lies.
So the reason behind keeping one public class per source file is to actually make compilation process faster because it enables a more efficient lookup of the source and compiled files during linking (import statements). The idea is if you know the name of a class, you know where it should be found for each classpath entry and no indexing will be required.
And also as soon as we execute our application JVM by default looks for the public class (since no restrictions and can be accessible from anywhere) and also looks for public static void main(String args[]) in that public class. Public class acts as the initial class from where the JVM instance for the Java application (program) is begun. So when we provide more than one public class in a program the compiler itself stops you by throwing an error. This is because later we can’t confuse the JVM as to which class to be its initial class because only one public class with the public static void main(String args[]) is the initial class for JVM.
You can read more on Why Single Java Source File Can Not Have More Than One public class