🔒 Locked

[java] import issues

Started by Elehisie Nov 26, 2004 at 8:37 AM 6 replies 950+ views

Original Post

Nov 26, 2004 at 8:37 AM

the only real difference I see in doing: import java.nio.*; or import java.nio.channels.SocketChannel; is that on the first, I get the whole NIO into my program, and the latter, I get only this bit of NIO which corresponds to the Socket Channel. but if I "import java.nio.*;" I get "unable to resolve symbol on lines like: ServerSocketChannel ssc = ServerSocketChannel.open(); which works fine if I do "import java.nio.channels.ServerSocketChannel;" so i have all this: import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.nio.charset.Charset; instead of the shorts: import java.io; import java.net.*; import java.nio.*; shouldnt the shorts work too?

CaptainJester

Nov 26, 2004 at 12:18 PM

Quote:
Original post by Anonymous Poster
Sadly, one of the major f-ups that Sun staff did when inventing java was to copy Microsoft and ignore all their knowledge of unix, and make "*" match "just one level of package hierarchy".

That was done on purpose.

Quote:
Original post by Anonymous Poster
Some people think you should never use *. They are morons. They have never written real, large, OOP software where you *usually* have many tens if not several hundred imported classes per source file.

I work on a real large OOP software project and we don't use any imports with '*'. I think is a matter of personal preference. And if you have several hundred imported classes in a source file, then you have to seriously look at what you are doing.

Quote:
Original post by Anonymous Poster
They are also misguided: good developers don't create classes with names like "List" except where they mean the main usage of that word in programming. For 99% of the time, a good developer thinks of a good name that is *probably* unique *unless* you are using an alternative library that does a similar purpose. e.g. If you are going to use two different implementations of Collections then you expect clashes - and the ability to NOT use * helps here. But almost all the time there will be no clash. This saves a lot of time and pain, especially when talking to people (it's so irritating to have to speak the full package name when trying to have a developer meeting, because the inventor couldn't be bothered to use a more sensible less vague name :))

Agreed.

You could say the same thing about C/C++. Why do I have to include all these header files. Just include everything.

Elehisie:
The '*' only imports the package level you are at. If you want to import the channels subpackage then you have to import that separately.

Elehisie

Nov 26, 2004 at 12:50 PM

i see -_-
anyway...

I dont mind much about importing hundreds of bazilions packages...

I come from Delphi, where you have extremely-long-refering-to-almost-everything "uses" clauses

its jsut better not to import the same things twice :)

CaptainJester

Nov 26, 2004 at 9:22 PM

Quote:
Original post by Anonymous Poster
Oh, like the compiler bug which won't let you delegate to other constructors except in the first line, for no actual reason, yet it has its own dedicated error message? :P

That is not a bug. How can you initialize your object if its parent object that it relies on for its definition is not initialized first? That is why there is an implicit call to super() if you don't provide one. That is also why if you provide a constructor that is not a no argument constructor in the parent, the child class will give a compiler error that it cannot find the constructor it needs(unless you specifically call the one with arguments).

On the other stuff, I can understand where you are coming from. People learn one way and they think it is gospel. For our project, the explicit import of each class was chosen as the coding standard, so it needs to be followed. Not because it is or is not the better way, but that is what was chosen as standard.

Zahlman

Nov 28, 2004 at 4:37 AM

I am inclined to agree with the AP on all counts, except the "you are likely to import huge numbers of classes per source file" business. A class with so many dependancies is probably itself too big.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.