Being able to import the libraries in the main program file and they will be loaded for the entire project rather than having to import the same libraries for every file that needs to use them.
IE: I have 2 files, both require the Swing library and currently I have to import the Swing library in both files. Wouldn’t it be easier if I could just loaded up in 1 file where the main method is and be done with importing libraries throughout the rest of the project?
Importing and loading is not the same thing!
Normally a lib is loaded only once when first used, regardless how many files to import it.
So don’t wait for future Java versions… even the oldest onces will be sufficient.
Yeah, you’re not importing a library with the “import” keyword, you’re allowing the use of shortened names from that package. The “import” command is just there to make your life easier, otherwise you’d be writing “java.lang.String = new java.lang.String();” etc.
I think what KILER was getting at was being able to stick a bunch of imports in one file then just include this file in each in someway.
EDIT: Just clarifying, not agreeing or disagreeing.
Kev
If he is, I hope not 
Or, rather than making changes to the language, you could use an IDE that manages imports for you. Using Eclipse, for example, I rarely even think about imports anymore (one keystroke adds imports automatically, all I have to do is resolve ambiguities).
Thanks.
Yes I am talking about never having to worry about imports again.
I should get Eclipse, I used Eclipse before but I prefer JCreator.
I think this is really a bad idea.
[quote]I think this is really a bad idea.
[/quote]
Why do you believe that?
Another question, I have installed Eclipse 3.0 M6 and I like it much better than JCreator (I didn’t like Eclipse 2.1 for some reason) and when I organise imports it doesn’t do “import javax.swing.*;” instead it “import javax.swing.JFrame;” is there a performance improvement or smaller memory footprint for the program if you import only what you specifically need?
Thanks
[quote]is there a performance improvement or smaller memory footprint for the program if you import only what you specifically need?
[/quote]
No, and no. The use of asterix to import all the classes/interfaces provides convenience to the programmer (if many classes in a package are imported). The import statement is used by the compiler only.
http://java.sun.com/docs/books/tutorial/getStarted/applet/import.html
from the above link:
[quote]The java.applet. and java.awt. prefixes tell the compiler which packages it should search for the Applet and Graphics classes.
[/quote]
I think it’s a great idea to specify the class you’re importing, if you’re importing only 1 or 2 classes, if only for informational puporses to yourself in the furture or to other developers. Just a stylistic choice on my part, however.
There’s a setting in Preferences->Java->Organize Imports that allows you to specify how many classes imported from the same package will cause a generic * import instead.
[quote]is there a performance improvement or smaller memory footprint for the program if you import only what you specifically need?
[/quote]
As said, it doesn’t affect runtime performance but using import javax.swing.*; might affect the speed of compilation although I never experienced much difference myself.
It also raises the chance of running into ambiguities which is one of the reasons I don’t like your global import idea. Another (for me much more important) reason I don’t like your idea is that you create code for classes that might not compile without some import statement in some other class. How do you know which class? A class with a main(String[] args) or something? What if there are more of such classes in a project? I just want to be able to use the source of a class ‘as is’, without seaching a source tree with some import statements that class might depend on because it wont compile otherwise.
I think such a global import potentially creates a lot of confusing problems and just feels very ‘un-java’ to me.
All info needed (including dependencies) for the compiler to compile a class should be in its source. Not in another source for another class.
Erik
The whole point of Import is namespace CONTROL.
Without explicit imprt you are quickly back to the C world where you never quite know what you are linking to because more then one source file can declare the same visible symbol and its undefined which one you get at link time.
This has been the source of many hard to find C bugs and lots of heartache in the past.
“Includes” are aslo dangerous as heck because they make opaque changes to the meaning of a source file.
Trust me, its all better this way. And a good IDE (eg Forte, Elipse, JBuilder) makes it pretty painless too.
However, I usually work on projects where most classes import many hundreds of other classes - a side-effect of having a highly componentized / modularised system, with a large number of libraries providing extra features etc.
I would rather shoot myself in the head than use explicit class imports anywhere; even having to maintain the * imports by hand takes far too long (not including ANY java., most classes have 5-20 separate . imports)
[quote]However, I usually work on projects where most classes import many hundreds of other classes - a side-effect of having a highly componentized / modularised system, with a large number of libraries providing extra features etc.
[/quote]
I think there is something wrong here. We have thousands of classes and hundreds of packages, but import lists are rarely more than about twenty lines. Many classes will interact with a huge number of other classes, but these are covered by a relatively small number of interfaces.
Maybe. However…
e.g. looking at java packages, many classes need 5 lines just importing the IO packages (io, net, nio*3)
e.g. every method that implements (or overrides an implementation) of an interface that throws a package-specific Exception then needs that package; in java.* the most common occurrences I tend to see are SQLException and IOException.
Going back to the non-java classes, a game server project I have in my workspace right now has over 200 classes (this is for a small/simple game). Not unreasonably, that’s partitioned into 12 direct packages (mostly sub-packages), and a further 4 packages which are dedicated to overriding particular behaviour from particular implementations of particular 3rd party libs (i.e. the libs could realistically be replaced by any of 2 or 3 alternatives, invalidating all the overrides; we need to be able to easily ignore those overrides - placing them in one package (and a stand-alone JAR) makes this easy; any suggestions for a better way would be appreciated, but I think we’ve tried pretty much everything at least once already :)).
Now, that’s not including ANY of the packages that have to be imported from other products / 3rd party libs. At the moment, this small game is using 3 different external products, one of which alone has about 15 packages (although one of the others only has one package for the whole product…). Using that product - which is a base engine - means frequently importing 5-10 different subpackages; since it has dependencies on yet more libs, sometimes (depending upon your game, and what bits of the engine you’re using) you need to import considerably more.
Personally, I would absolutely love to see java have a recursive import; I’d be even happier if the naming system got “upgraded” into making use of the implicit hierarchies. I’ve always found it suprising that java uses a hierarchical naming system, but explicitly states there is no actual hierarchy - the fact that A is a subpackage of B has no meaning in java. I consider this to be wrapped up with the miserable lack of any serious package-management in JAR and packages; it appears that whoever did these parts of java originally either had little knowledge of management systems, or far too little resources and was forced to design and spec something almost entirely useless.
The java world would be a far, far better place if it had a “real” package management system. The present hacks to the JAR spec to make it allow primitive naming and versioning are far from adequate. In fact, in a recent mailing list discussion about “deploying complex systems” I had to warn someone off java simply because they’d have to spend months re-inventing the wheel and writing their own (unless they were happy to do this…).
I don’t seem to have any problem with this whatsoever… the IDE takes care of the imports. Any trouble with pluggable code is best solved with interfaces anyway, so no need to go changing imports.
But I’d love an import mystuff.**; statement to import stuff recursively from subpackages.
Cas
wrt. deployment - you are getting the distinction between compiler namespaces and deployed version control confused. Webstart takes care of jar versioning well.
Cas
[quote]wrt. deployment - you are getting the distinction between compiler namespaces and deployed version control confused. Webstart takes care of jar versioning well.
Cas
[/quote]
I was only trying to say that the two are fundamentally interlinked; of course they are separate, but the major use cases for one normally heavily involve the other and vice versa. You cannot have a proper versioning system that does not incorporate nor rely upon a naming scheme (which is what the compiler namespace stuff is; only it’s a very simplistic and weak naming scheme; note that it’s already widely used in java for more than just selecting imports - it’s used as a generic namespace e.g. for 1: starting JARs, 2: explicitly qualifying classes and objects at runtime, 3: selecting classes at invocation time (e.g. choosing a class to run); these could - theoretically - use separate naming schemes, but don’t).
I’ve not personally used webstart but I struggle to see how it would solve ANY versioning problems AT ALL for server applications ? (which I suspect is where versioning is biggest as a PITA in java right now; and incidentally AFAIAA is the area that pushed sun to extend the manifest spec (i.e. for the benefit of j2ee))