views:

211

answers:

3

We have a number of projects that use the same and/or similar package names. Many or these projects will build jar files that are used by other projects. We have found a number of foo.util foo.db and foo.exceptions where the same class names are being used leading to name space conflicts.

Does anyone know of a tool that will search a set of java code bases and automatically find name space conflicts and ambiguous imports?

+2  A: 

If you can load the projects into Eclipse, the Problems view will give you the conflicts and ambiguous imports. There is also a organize imports wizard that will help with any unnecessary imports.

AdamC
+3  A: 

It's simpler to fix your names in each individual project.

Really.

You don't need to know all the conflicts. Your package names should be unique in the first place. If they aren't unique, you need to rethink how you're assigning your package names. If they're "flat" (foo.this and foo.that) you need to make them taller and much more specific.

That's why the examples are always org.apache.project.component.lower.level.names.

You should have com.projectX.foo.this and com.projectZ.foo.that to prevent the possibility of duplication.

"But all that recompiling," you say. You'll have to do that anyway. Don't waste a lot of time trying to discover the exact, complete extent. Go with what you know, start fixing things now, and work your way through your code base fixing one thing at a time.

S.Lott
I agree in theory with your recommendation but there are ~35 projects and the initial goal is simply getting the app(s) to run on a different platform. After that goal is reached, larger less stupid code practices will be funded. Until we have a running app, there is little money.
sal
Do one package at a time. It's not hard to rename one package and then fix all the apps that depend on it. Then move on to the next package. While you're doing that, inventory your packages and find out who's responsible. One at a time.
S.Lott
A: 

I agree with S.Lott - you need to find out how this happened in the first place, and make it very painful for the people who did it wrong (i.e. make them go back and fix things). Modern IDEs (Eclipse being one of them) makes this kind of refactoring fairly easy.

The only thing I disagree with is about fixing things as you go. Instead, I strongly recommend that you pay your technical debt on this one now with a solid package name review. A couple of hours (and that's really all it should take) here will save you nightmare debugging down the road.

FYI - it is perfectly legal to have classes in the same package in different source folders (e.g.):

src/com/my/project test/com/my/project

Trying to differentiate between the above valid folder structure, and the situation you are winding up with is going to be very tough in any automated manner.

Kevin Day