Jump to content
  • Advertisement
Sign in to follow this  
Elehisie

[java] import issues

This topic is 5130 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
Guest 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".

Because of this, (and other similar choices) pacakges are NOT in a hierarchy, and it is a lie to say that they are, except that Sun forces you to place them in folders on the hard drive in a hierarchy.

This has caused mcuh confusion over the years, and was a sad mistake to make, since it could easily ahve been avoided.

So...you need to do:

import java.nio.channels.*;

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.

Many people think you should avoid * where possible. They haev a point, because otherwise java.awt.List and java.util.List are identical. But do this only if your IDE is good enough to fix it for you. Sadly, Eclipse is broken with its imports, so I leave it at * for everythign.

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by CaptainJester
That was done on purpose.


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

I didn't say it wasn't deliberate, just that it was a decision I feel they made without thinking about it enough (like some of the "improvements" c# made deliberately compared to java, where it genuinely appears they simply didn't think about the *reasons* java does certain things for long enough to realise why they really shouldn't try to get rid of them).

Shrug. It was a bit of a rant, a personal bugbear, so I'm happy to accept it may just be me who hates it.

Quote:

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.


Yup. And I've done it so often (seriously doubted what a team was doing, and tried to think of a different arrangement that would solve things) that I've got used to the fact that it is actually a fact of life in a sufficiently complex OOP project. The best improvement I could think of was that "some projects may be too inter-dependent for OOP", but *assuming* you're happy with the vast number of imports you actually get a clean system using OOP, so I just shrugged and moved on.

Part of the problem is the primacy of the "package" in java, and the tendency to map "package" 1:1 with "jar file", and so create a new package for every module, etc. Which causes a proliferation of packages.

Also, I think an awful lot of people sub-consciously think of packages as hierarchical (they even frequently use the term "subpackage" without choking on it), and so e.g. when deciding whhat to name a new package, or whether to piggy-back on an existing one, they make a new subpackage thinking to get the best of both worlds, little realising that the ONLY place it makes a difference is in the javadoc docs where the index collapses subpackages...

Quote:

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


I was always too much of a coward to do that because of how much a header file in C could potentially be doing :).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by CaptainJester
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?


Yes, it is a bug.

Why?

Because the following works:

public MyClass()
{
MyClass( "a" );
}

public MyClass( String s )
...

but this does NOT:

public myClass()
{
String s = "a";
MyClass( s );
}

Strictly speaking, apart from the fact that in the first you have no ref to the string, they are identical. If you never use that ref, they are identical.

Yet one is allowed by the compiler and the other isn't.

This isn't a clever optimization (like realising that a complex piece of algebra reduces to something simple) - this is simple parsing. Both should produce exactly the same code.

Quote:

That is why there is an implicit call to super() if you don't provide one.


The same applies with super(...) - the "first-line" stuff is a dumb rule placed in the compiler. The best explanation I've ever found is "makes code slightly easier to read", but it also is often a PITA when writing classes with 3 or more constructors; it is a serious problem whenever you need to refer to the same identical argument twice in the delegation call, e.g.:

public MyClass()
{
AnObject o = AnObject.getInstance();
MyClass( o, o.getDate() );
}

public MyClass( AnObject o, Date d )
...

Since the compiler *allows* you to do:

public MyClass()
{
MyClass( AnObject.getInstance(), new Date() );
}

there's no reason why it should be disallowing the previous example - but that .getDate() call could be different for each instance (due to unique IDs etc), in which case you have an impossible-to-compile situation, and have to hack together ugly workarounds.



If you can give me a firm reason for the way it is now, then I would be grateful. I have been asking people about this for more than 4 years, and no-one I've worked with has ever come up with a decent explanation, nor have any of the Sun staff I've asked (and some have agreed it seems pointless).

Quote:

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.


...which I agree is more important than individual choice. Although...I have worked on projects where the initla coding standard was invented a long time previously and is now out of date. e.g. one was invented 5 years previously (when no-one thought the product version would last more than a year or two), and then the product got ported several times, each time extending the initial project by another few years.

We were left with coding standards that were ridiculous (the project moved from C to C++ at one of the porting stages) for hte language and tools (which had been extensively upgraded) we were using. We stuck with the original conventions for the sake of simplicity and making it easier to back-port and forwards-port bugfixes etc - but it cost us a lot of time and manpower, and sanity :(.

I left with the (unverifiable) suspicion that the increased confusion and difficulty of cross-porting updates would in fact have been less than the time saved by just adopting better C++ conventions on the later ports.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!