Develop Reference

Inspection to separate one java package from the rest of the project

I have a java package foo.bar. It contains few classes, that are frequently modified, improved etc in this time of project.
I don't want any developer to use classes from the other packages in this one. I want this package to be separated in its usage. So this package must be isolated.
I could make an external jar, but that would introduce much more handling for little number of classes, that it does not make sense.
I want this inspection to be run from my build process.
I tried several code-inspection tools (pmd...) but I was not able to configure this. How to do this?

GWT refactoring: classes, modules, rename the whole project

I am writing here because of desperation caused by refactoring a GWT project.
My first try:
After I read all the praises of the refactoring tool from Eclipse ( I am using it as IDE) I simply right clicked on a module ( what a fool i was ) and use the refactoring option. My project became unusable.
First Conclusion:
Found out that I need to start with the classes and then go up and refactor a module at a time.
Second try:
Refactored some classes, worked fine until I messed something related to a ui.xml file. Project unusable!
Second Conclusion:
Be careful at the ui.xml files!
Third try:
Went pretty well, but I got ahead of myself and tried to remove some comments or replace class names in comments. Predictable result : project unusable!
Third Conclusion:
Try again!
Forth try:
Fail!
Fifth try:
Fail!
You get the picture.
Can someone experienced with GWT please offer some guidelines about the mystical realm of refactoring?

GWT has some rules based on naming conventions (e.g. the two interfaces for GWT-RPC, the *.ui.xml files and the class that uses them through UiBinder, the files related to ClientBundle or ImageBundle methods, the *.properties files for I18N), so failing to respect them when renaming/moving one class/file will break it.
GWT also sometimes references classes by name in non-Java files (#eval in the *.css of a CssResource, or in *.ui.xml files), non-Java portions of classes (JSNI) or string literals (e.g. in #ProxyForName and #ServiceName). Failing to update them all will break the build.
Because a tool makes it easy to refactor does not mean you should let it do it blindly: it's just a tool, you have to understand what it does and double-check it (hint: check the box in Eclipse that forces a preview before applying the refactoring) so it doesn't do too much or too few.

How to organise Eclipse workspace into folders without breaking Android

I've been working on an Android app in Eclipse, and it's gradually grown in complexity to the point where I find it difficult to locate individual classes in the Package explorer.
Java isn't my strong point, I come from a Visual Studio/C Sharp background, so my first thought was to move logical groups of classes into new packages, a bit like creating a new code folder in Visual Studio.
I created a new package, com.mycompany.myapp.activities and dragged all the Activity.java files into here.
The whole thing went pretty badly, I got tons of import errors, resources failed to build, and so on. The auto refactor tool messed up my Manifest file pretty badly too. It just doesn't seem like it was designed to work that way - I ended up moving them all back, and wasted two hours fixing it.
So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them? I'd like to make a folder for 'Data Model', one for 'Activities', one for 'Interfaces' and so on.
How would I go about doing this? Or am I thinking about this the wrong way?

So my question is, does Eclipse have some way to organise .java files into logical subfolders without having to create new packages for them?
AFAIK, no. You just need to fix up stuff related to moving your code into packages.
I got tons of import errors
Your app's R.java is generated into your application package (com.mycompany.myapp), and any classes in that same package get R via auto-import. Code residing in other packages needs to import that class (e.g., import com.mycompany.myapp.R). Hence, if you refactor a class from your app's package to a sub-package, you need to add the import.
resources failed to build
That seems unlikely, as resources know nothing about Java packages. However, without any details, it is difficult to provide you with concrete assistance.
The auto refactor tool messed up my Manifest file pretty badly too
You would need to adjust your <activity> elements to ensure they point to the newly-repackaged classes. Ditto for any other components that you repackage (e.g., services). Beyond that, without any details, it is difficult to provide you with concrete assistance.
It just doesn't seem like it was designed to work that way
Certainly, moving activities into other packages is supported. Whether the ADT plugin handles all aspects of it with aplomb is another issue. If you come up with concrete repeatable scenarios where the ADT plugin is not doing the right thing, file an issue at http://b.android.com.

Tools for analyze Java source code

For a student project I need to extend a Java project.
The problem is that this project doesn't have a lot of comments and it's hard to analyze it.
I'm searching for something to generate a class diagram and, if possible, a sequence diagram.
I have already tried umbrello (but there are some bugs with big classes) and agilej but the project has a lot of packages and sub-packages and I did not find how to generate the diagram recursively.
Are there other tools to do this?
Thank you in advance.

In Eclipse you have the option to set the package presentation to Flat or Hierarchical. In the flat mode you see the fully qualified name of each package under the src/ folder, and in the hierarchical mode you have to expand to see src/com/mypackage etc. In AgileJ when you are in flat mode (the default mode for Eclipse) then whatever you drag from the package explorer, be it a project, folder, library, Java source file, class or whatever, it will recurse down through the ownership tree and add the classes which it finds as you would expect it to do.
The anomaly you describe in you question - not recursing through the sub-packages - happens when you have the package explorer in hierarchy mode. In this case what happens is that the class diagram just receives notification of a drop of a package - but it has no way of knowing the package presentation mode of the package explorer or even if the drag originated from the package explorer.
So if you really want to recurse down through a hierarchy of packages, and for some reason don't want to multiple select them with the package explorer in flat mode, then the easiest thing to do is switch to the Resource perspective and in the Navigator view find the folder which is the parent of all the packages you want to include then drag that onto the class diagram. That will kick off a recursive search for classes down through the sub-packages.
Please note that if you drag in a large enough number of classes (the exact threshold is configurable) then it will offer to filter them down - for example you might want to filter out unit tests or generated classes. If you try to add a really large number of classes (again, it is configurable, but by default it is 200) then you'll be blocked - but what is the point of a single class diagram with 200 classes on it, it will only result in an unreadable class diagram.

Another eclipse plugin is called 'metrics', which you can find on sourceforge. It can provide a bunch of information about a Java project, both in textual and graphical form.

Why do Java sources have so many folders inside each other?

Every time I look at some Java source code, I find myself surfing in a folder that has folder that has folder that has folder in it etc. Why does Java require so many nested folders, which have nothing else in them except the new subfolder?
For example:
https://github.com/halfninja/android-dragcontrol3d/tree/master/src/uk/co/halfninja/android
That's probably not the worst example, but there are two folders "uk" and "co" that just don't make sense. I see this in Java sources only!
And for example minicraft: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=398
import com.mojang.ld22.gfx.Font;
import com.mojang.ld22.gfx.Screen;
import com.mojang.ld22.gfx.SpriteSheet;
Why not just write:
import gfx.Font;
import gfx.Screen;
import gfx.SpriteSheet;
That's so much cleaner.
(I have never programmed in Java.)

These are there to prevent conflicts with other jars. Having something like the company url in the package name makes it likely to be unique enough to not conflict with someone else's package and classes.
Your example is a good one, since it seems pretty reasonable to imagine two people thinking of using "gfx" as a package name and with classes like Font or Sprite. Now, if you wanted to use both of them, how could you since the package and class name would be the name?

Your way is cleaner, but it assumes nobody else in the world is ever going to create a package called gfx, which is a pretty weak assumption. By prepending your reversed domain name, you create a unique namespace that avoids collisions.
This fits perfectly with the "culture of sharing" that pervades Java programming, in which applications typically combine large libraries from many sources.

In Java, the convention is to name your packages (which correspond to the folder structure containing your code) with information identifying your organization (typically including a TLD and the company name) and project (which might add a few more sections).
Being more specific like this also reduces the likelihood of namespaces accidentally colliding with eachother.

It's merely an organizational technique for preventing namespace conflicts. Nothing more or less. Java package names match the underlying directory structure, so any organizational pattern at the package level will be reflected there. It's typical for teams to start their package names with their organization's name and wax specific. This is simply convention, but it's ingrained and should be followed absent a very good reason.

It's all about Namespaces. With 'Namespaces', you can create 2 classes with the same name, located in different packages/folders. This Namespace logic can also be used for creating 'Access Privileges', etc etc. Below are some links:
1) Namespace
2) Java Package
3) Java Package Naming Conventions
EDIT: Let us assume that you are creating a new project and are using 2 open source frameworks from companies/organizations - comA and comB. Also, let us assume that comA and comB have created a class in their projects with the same classname. Now, with the Java package naming conventions, we have com.comA.SomeClass and com.comB.SomeClass. You can import and use both the classes in your class, without having a conflict. This is just a simple example. There are other uses from this naming convention.

If you want to share code with everyone else, but use generic names without conflict. its considered good practice to include you domain name (backwards)
Everyone write a package called gfx.Font you wouldn't be able to use more than one version in the same application.
You might feel your code will not be shared with the world (or even should not be shared) In which case, a shorted package structure may be simpler.
If you use an IDE, it does a good job of hiding long package structures so you don't need to worry about it.

This is due to recommended packaging structure. In large projects, so many packages/libraries are used and in order not to put source files into same folder with another library, programmers put their source codes into unique folders. As websites are unique, it is a convention to use packaging structure that looks like folder structure of websites.

Java does not require anything: you can just put all your classes in the default package and surf away. But for serious projects that kind of organization is not only wise, it's mandatory. The com.mojang.ld22 part is just a convention:
com = either this or org, java/javax for official packages
mojang = second part is company name
ld22 = third part is application name