Win a copy of Micro Frontends in Action this week in the Server-Side JavaScript and NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

import statements

 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Referring to my recent blog entry (please read it before posting replies), I'd be happy to hear about people's opinions on the benefits of

versus


Do you see specific value in these approaches? Do you see specific deficiencies in these approaches?
 
author & internet detective
Posts: 40213
816
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lasse,
I prefer the package.* apporach because you don't have 20 lines of imports clogging up the beginning of the code.

I recently discussed this with a coworker who prefers listing the imports individual. He says this is to easily see where a class came from. I use the find class feature of my IDE for this rather than look through a list. This also gives me the advantage of finding out what project/jar the class is in.

From Eric's reasoning:
"reflecting the intention that packages are highly cohesive units" - this I agree with
"while simultaneously reducing the effort of changing package names." - this I don't. In an IDE with decent refactoring support, there isn't any effort to do this.

One argument against Eric's idea is if you want an automated way of finding what classes use a particular class without an IDE. You could have an ANT build or shell script search for the fully qualified import.
 
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had a post prepared but then I realised I hadn't read your blog. It and the two comments posted below it together said everything I intended to post and more.

For me, IDEs pretty much make the whole discussion moot. However, the second comment makes an interesting point about gauging the actual degree of coupling this class has with others - that is a good one. So, I'll stick with what I do now and make sure Eclipse does explicit importing. Then, the size and content of the import list conveys some useful information.

A last note - Jeanne - the latest versions of Eclipse have code folding and by default the import statements (which are treated as one group) are folded so they don't clog up the top of the file. (Not sure if you use Eclipse but you post on it frequently enough in the IDE forum that I thought you might be interested. )


--Tim
[ June 23, 2004: Message edited by: Tim West ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Import statements! What's wrong with American made statements!

Maybe I need more sleep.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Stan James:
Import statements! What's wrong with American made statements!

Maybe I need more sleep.


Going to JavaOne, Stan? You better catch up with James Gosling and tell him about your idea for a new language feature
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No Java One. Maybe SD East. Anybody else?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, Stan, what exactly are these "American made" statements?
 
Jeanne Boyarsky
author & internet detective
Posts: 40213
816
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim,
I am interested. Thanks for telling me. We use WSAD at work and I use Eclipse at home.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As you point out in the blog entry, if you're using a good IDE, it doesn't really matter.

I think that means you should make the decision for the benefit of those using a simple text editor, or who happen to be reading a printout (which still happens to me occasionally). To me, that dictates importing classes individually, as it takes almost no effort to skip over thirty lines of import statements, while it takes a lot of effort to shuffle through all the code in half a dozen packages looking for some particular class.

If I'm not mistaken, Eric is wrong about having to import into every class individually; can't one instead use fully qualified names?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
If I'm not mistaken, Eric is wrong about having to import into every class individually; can't one instead use fully qualified names?


Well... I guess you can but yet you can't
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general I'd like to echo the feeling that I prefer the explicit information contained in an import list of actual classes. I have worked in the past with systems where some classes in a package are in one jar, and others from the same package are in a different jar. In this kind of situation, knowing which classes are actually being referenced is vital.

For most purposes, Eclipse just sorts this out for you, although I have noticed that it can get confused when moving classes between packages (it seems to prefer "import old.package.*" rather than explicitly importing only classes from the old package that are actually used. I also can't find the tool/refactoring "make all imports explicit", so I often have to go through the tedious process of deleting a package import, then "quick-fixing" the resulting errors. This is both clumsy and dangerous, especially where there are several classes with the same name in the system.

As related reading, interested participants may wish to take a look at this thread from last year about packages. A lot of interesting things were raised.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
I prefer the package.* apporach because you don't have 20 lines of imports clogging up the beginning of the code.



With all due respect, having a class depend on 20 classes in other packages is a code smell - it indicates that the class likely is doing too much and violates the Single Responsibility Principle.

But the most important argument for using explicite class imports is that it makes the code more stable. We already experienced a project not compiling against a newer JDK, simply because Sun added a new class to the JDK whichs name conflicted with one of our own classes.
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss:

With all due respect, having a class depend on 20 classes in other packages is a code smell - it indicates that the class likely is doing too much and violates the Single Responsibility Principle.

!!

What do you think is a reasonable number of classes to depend on?

Here's a typical import list for me:

That's not quite 20, but it's for a pretty small class - the whole file is only 219 lines long, half of which are comments. I find that if I want to maximize code reuse by using libraries as much as possible, I sometimes get up to 40 imported classes or so.

But the most important argument for using explicite class imports is that it makes the code more stable. We already experienced a project not compiling against a newer JDK, simply because Sun added a new class to the JDK whichs name conflicted with one of our own classes.

That's a very good point.
 
Jeanne Boyarsky
author & internet detective
Posts: 40213
816
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

With all due respect, having a class depend on 20 classes in other packages is a code smell - it indicates that the class likely is doing too much and violates the Single Responsibility Principle.


The number 20 was arbitrary. But sometimes you get a lot of imports through things you can't control. Our code generator generates commands with about 10 imports. (logging, exceptions, command interface, utility class, collection class, value objects, bean.)
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like em explicit and agree that a long list is something to think about. I didn't say it's necessarily bad, it just gets my attention. Swing apps get long lists in a hurry, and I wouldn't count Swing and AWT imports against anybody. It was nice to see the example above did not mix in lots of Java.util or business imports.

We use a vendor framework that in a prior release used fully qualified names everywhere and did few imports. I converted some classes to use imports and people asked, isn't that a lot of imports? My answer was, Duh! Yeah! And now we know just how perverted the dependencies in this framework are!
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
But sometimes you get a lot of imports through things you can't control. Our code generator generates commands with about 10 imports.



I think 10 imports are likely ok. And I certainly care much less about imports in code I don't have to touch manually anyway.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
What do you think is a reasonable number of classes to depend on?



I have to admit that I don't have a hard and fast number in mind.

I skimmed through some of my classes, though, and most of them seem to have between 5 and 10 imports, with a tendency to the lower value.

I also found a class with 17 imports, but I am actually not pleased with the size of that one...


Here's a typical import list for me:

That's not quite 20, but it's for a pretty small class - the whole file is only 219 lines long, half of which are comments.



I wonder why it does depend both on so "many" Swing classes *and* two concrete Set implementations. Can you tell us a little bit about what the class is doing?

BTW, I am a fan of many small classes, so I actually wouldn't call 100 LOC a very small class...

I find that if I want to maximize code reuse by using libraries as much as possible, I sometimes get up to 40 imported classes or so.



I find that maximizing code reuse also means building many small, very focused units of reusable code, and those small units typically don't depend on that many other units - wether thirdparty or not...
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ilja Preuss:
[I]

I wonder why it does depend both on so "many" Swing classes *and* two concrete Set implementations. Can you tell us a little bit about what the class is doing?[/I]

Sure. It's a list that allows the user to do certain manipulations, like additions and removals and reordering. I use such a list many times in my application, so it's worthwhile to make a reusable class.

To use a widget in Java, you need both a view-controller class and a 'model' class; that's why I end up with both a JList and a DefaultListModel. To make it scrollable, I need the JScrollPane. The JLabel is so I can have a title attached to the list, so I don't have to include it separately at a higher containment level. The awt.BorderLayout is needed so I can position the label relative to the list. I have to have JPanel so I can put all these things together into one reusable element. Like Stan said, Swing applications get long import lists in a hurry.

Unfortunately, the Swing 'model' classes are very limited and don't actually suffice for the data manipulation I need. I need to store the elements in a data structure of my own. What I need is an ordered set for this. That's why I use the TreeSet implementation. I need Iterator in order to be able to access the data in the set. I want to be able to construct my panel on unordered sets of data, so I need the Set interface so I can properly declare the constructor. Finally, I want to be able to return an ordered version of the data to a caller, so I need another interface - SortedSet - for the return type. Basically, that's four imports just to get one functionality - the functionality of a sorted set. In my experience, that's pretty typical for using Java collections; unlike Stan, I think this can reasonably lead to quite long lists of java.util imports in more complex classes.
 
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
List your imports separately, eschew the wildcard imports. The purpose is to keep the code self-documenting. Don't talk to me about letting your IDE do the heavy lifting here...one of the stalwarts of Java is that it's platform-independent...now you're writing IDE-dependent code? What if I use vi?

No, I would argue that your IDE should be advanced enough to accomodate the vi user, not that the vi user should be forced to run out and spend $1800 in licensing fees on your IDE, or on hardware to support a similarly-featured, but "free", IDE like eclipse.

And I routinely use IntelliJ at work, so I know that it can do this--it automatically adds the imports, you can configure it never to default to wildcard notation, and you can collapse that long list of imports in the editor if its cluttering up your code. So you have no excuse not to list them out and keep vi guy happy.

You might be thinking I'm wrong on this point, there's nothing wrong with using the features of your IDE. Well, then I've got bad news for you. I use an IDE that doesn't require me to use any import statements at all...I simply use fully qualified class names EVERYWHERE in the code, and my IDE's smart enough to only show the class name. You don't have a problem with me using fully-qualified class names everywhere, I hope? Good!


sev
 
Jeanne Boyarsky
author & internet detective
Posts: 40213
816
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sev,
I don't see how using the import package.* notation is IDE dependent. The code can be read in any IDE or editor. If there are only a couple imports:

it isn't such a big deal to figure out where the class came from. A full list of imports could bother the vi guy more because he has to read them without the option of hiding.

In any event, on many teams all developers must use the same IDE. We use WSADs code formatter feature to enforce certain coding standards like alignment.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
Sure. It's a list that allows the user to do certain manipulations, like additions and removals and reordering. I use such a list many times in my application, so it's worthwhile to make a reusable class.



This sounds very familiar to me! I just wrote a similar component in the last days. Here are the imports:



I think the class *is* a little bit too big, but currently I wouldn't know how to reasonably split it... :roll:

To use a widget in Java, you need both a view-controller class and a 'model' class; that's why I end up with both a JList and a DefaultListModel. To make it scrollable, I need the JScrollPane. The JLabel is so I can have a title attached to the list, so I don't have to include it separately at a higher containment level. The awt.BorderLayout is needed so I can position the label relative to the list. I have to have JPanel so I can put all these things together into one reusable element. Like Stan said, Swing applications get long import lists in a hurry.



Sounds reasonable...

Unfortunately, the Swing 'model' classes are very limited and don't actually suffice for the data manipulation I need. I need to store the elements in a data structure of my own.



What we have done in this case is implementing a "model"/view separation, too. For the above OrderedSelectionPanel class, there exists an OrderedSelectionModel which holds the data and applies action to them (like moving data around etc. The responsibility of the panel is to show the current state of the model, and to tell the model to do work in reply to button clicks.

I very much like this approach.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic