Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Will this be possible in future versions of Java?  (Read 2612 times)
0 Members and 1 Guest are viewing this topic.
Offline K.I.L.E.R

Senior Member




Java games rock!


« Posted 2004-01-01 07:32:41 »

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?

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #1 - Posted 2004-01-01 15:02:19 »

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.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #2 - Posted 2004-01-01 16:31:59 »

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.

Hellomynameis Charlie Dobbie.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 119
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2004-01-01 16:36:53 »

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

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #4 - Posted 2004-01-01 17:33:20 »

If he is, I hope not Smiley

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline morbo

Senior Newbie





« Reply #5 - Posted 2004-01-01 21:09:55 »

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).
Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #6 - Posted 2004-01-05 23:22:47 »

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.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #7 - Posted 2004-01-06 19:13:42 »

I think this is really a bad idea.

Offline K.I.L.E.R

Senior Member




Java games rock!


« Reply #8 - Posted 2004-01-07 01:27:49 »

Quote
I think this is really a bad idea.


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

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
kul_th_las
Guest
« Reply #9 - Posted 2004-01-07 01:40:41 »

Quote
is there a performance improvement or smaller memory footprint for the program if you import only what you specifically need?


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.


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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline morbo

Senior Newbie





« Reply #10 - Posted 2004-01-07 02:47:54 »

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.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #11 - Posted 2004-01-07 06:39:16 »

Quote
is there a performance improvement or smaller memory footprint for the program if you import only what you specifically need?


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

Offline Jeff

JGO Coder




Got any cats?


« Reply #12 - Posted 2004-01-17 00:40:43 »

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2004-01-17 07:33:40 »

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)

malloc will be first against the wall when the revolution comes...
Offline Mark Thornton

Senior Member





« Reply #14 - Posted 2004-01-17 08:26:51 »

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.

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.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #15 - Posted 2004-01-17 09:06:16 »

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 Smiley).

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..).

<gets off soapbox> Smiley

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2004-01-17 12:52:35 »

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 Smiley

Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2004-01-17 12:54:16 »

wrt. deployment - you are getting the distinction between compiler namespaces and deployed version control confused. Webstart takes care of jar versioning  well.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2004-01-17 22:08:45 »

Quote
wrt. deployment - you are getting the distinction between compiler namespaces and deployed version control confused. Webstart takes care of jar versioning  well.

Cas Smiley


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))

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (37 views)
2014-07-18 06:55:21

Zero Volt (35 views)
2014-07-17 23:47:54

danieldean (28 views)
2014-07-17 23:41:23

MustardPeter (31 views)
2014-07-16 23:30:00

Cero (46 views)
2014-07-16 00:42:17

Riven (47 views)
2014-07-14 18:02:53

OpenGLShaders (36 views)
2014-07-14 16:23:47

Riven (36 views)
2014-07-14 11:51:35

quew8 (32 views)
2014-07-13 13:57:52

SHC (69 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!