Reputation: 10585
From what I've seen, Android development requires the traditional Java style importing of each individual class/interface while the suggested templates in XCode import files like Foundation and UIKit. What is the difference in the compiler between Obj-C and Java that makes this sort of big import OK in one, but not OK in the other?
To be clear, I am not whining that this is not available in Java, I am just curious why it would be bad to do something like importing java.util.*
or creating some sort of super header file that imports a lot of stuff.
Upvotes: 0
Views: 564
Reputation: 308021
One important thing to note is that the only source code you need to compile any given Java class is the source code of that class.
Everything else needs to be available in compiled form only (i.e. as .class
files). This means that a single .java
file is always a syntacitcally closed unit that needs no other source code to make interpretable to a compiler.
This is quite different to how C-style languages treat external dependencies: they need type and function definitions (as well as macros and some things I probably forgot about right now) in order to be able to correctly parse and compile a .c
file (of course some .c
files might be syntactically closed, but that's not the usual case).
The closest you can get to including a huge .h
file in Java is using a .*
import to import all classes of a given package: import foo.bar.*
, but that's still miles away from the C/C++/Objective-C way.
And on a separate note: import foo.*
is probably a bit less common in Java than individual imports for a simple reason: Individual imports are much more explicit and make it very clear which classes are used and they are usually written by your IDE of choice anyway, so this choice doesn't even make Java code harder to write.
Upvotes: 2