Netbeans short class names

[Peter Ream]

Sorry if this has been asked and answered. I am very new to java. I have written my first java application twice. Both times using the eclipse IDE. I am now giving netbeans a try. When I generated my first JFrame, in netbeans, I got the fully qualified class name javax.swing.JFrame. In eclipse with javax.swing.JFrame imported it uses the short name JFrame. Is this frowned upon in netbeans and therefor not allowed? I have been googling for sometime and have not found a way to accomplish this. Any help?

[Knute Snortum]

I believe you are looking at generated code, am I right? This is just the style that the generated code uses. I think using import statements and short names in your code is the preferred way, but I'll post this to the IDE forum to get other opinions.

[Peter Ream]

Knute Snortum wrote:I believe you are looking at generated code, am I right? This is just the style that the generated code uses. I think using import statements and short names in your code is the preferred way, but I'll post this to the IDE forum to get other opinions.

Yes, generated code. Sorry, didn't even see IDE forum.

[Stevens Miller]

Knute Snortum wrote:I think using import statements and short names in your code is the preferred way, but I'll post this to the IDE forum to get other opinions.

My opinion is that your opinion is correct.

As a C-to-Java programmer, I jumped to the false conclusion that "import" was Java's version of C's "#include" preprocessor directive (which may mean it isn't even part of C, but that's a topic for another thread).

All import does for you is allow you to refer to names defined within other packages, without having to qualify those names with their full package names. There are a mix of views on how best to use import, but I would venture to say that everyone uses it at least some of the time. Where it can fail you is if you must refer to symbols in two different packages that have the same short names. Consider these three classes, each in a different package:

package thehill.jack;

public class PailOfWater
{

}

package thehill.jill;

public class PailOfWater
{

}

package thehill;

import thehill.jack.*;
import thehill.jill.*;

public class Hill
{
    PailOfWater pail = new PailOfWater();
}

Line 8 in that third bit is going to cause a compiler error, because the compiler knows (owing to the import statements at Lines 3 and 4) that both the thehill.jack package and the thehill.jill package define a symbol named PailOfWater. The compiler has no way of knowing which one you mean. You can solve this problem by refactoring one of the two packages (but that would mean refactoring all their clients in the light-cone created since you first deployed the second package), or you can resolve the ambiguity with full qualification:

package thehill;

import thehill.jack.*;
import thehill.jill.*;

public class Hill
{
    thehill.jack.PailOfWater pail = new thehill.jack.PailOfWater();
}

Note that, even though both packages are fully imported, there is no ambiguous reference in the code above, so the compiler happily tolerates the fact that a symbol of the same name is defined in two different, imported packages. Until it needs to find an unqualified symbol in an imported package, the compiler doesn't care if that symbol is defined more than once.

Note also that none of what I've said depends on thehill.jack and thehill.jill starting with thehill., as it will apply if those packages were just named jack and jill, (I just named them the way I did so they'd all show up near each other in "Experiments" project package tree in NetBeans).

As for JFrame in particular, you will see that NetBeans loves to subclass JFrame to create your "main" window for you. This is usually harmless, but folks here persuaded me that it's not the best practice, and offers no meaningful benefits. Better is to create a JFrame directly, and put a JPanel into it that you use the NetBeans GUI editor to create. If you are just getting started, go ahead and use the JFrame subclasses that NetBeans creates for you. Just remember someday, if you can, that creating your own JFrame is probably what you ought to be doing.

[Peter Ream]

Stevens Miller wrote:

Knute Snortum wrote:I think using import statements and short names in your code is the preferred way, but I'll post this to the IDE forum to get other opinions.

My opinion is that your opinion is correct.

As a C-to-Java programmer, I jumped to the false conclusion that "import" was Java's version of C's "#include" preprocessor directive (which may mean it isn't even part of C, but that's a topic for another thread).

All import does for you is allow you to refer to names defined within other packages, without having to qualify those names with their full package names. There are a mix of views on how best to use import, but I would venture to say that everyone uses it at least some of the time. Where it can fail you is if you must refer to symbols in two different packages that have the same short names. Consider these three classes, each in a different package:

package thehill.jack;

public class PailOfWater
{

}

package thehill.jill;

public class PailOfWater
{

}

package thehill;

import thehill.jack.*;
import thehill.jill.*;

public class Hill
{
    PailOfWater pail = new PailOfWater();
}

Line 8 in that third bit is going to cause a compiler error, because the compiler knows (owing to the import statements at Lines 3 and 4) that both the thehill.jack package and the thehill.jill package define a symbol named PailOfWater. The compiler has no way of knowing which one you mean. You can solve this problem by refactoring one of the two packages (but that would mean refactoring all their clients in the light-cone created since you first deployed the second package), or you can resolve the ambiguity with full qualification:

package thehill;

import thehill.jack.*;
import thehill.jill.*;

public class Hill
{
    thehill.jack.PailOfWater pail = new thehill.jack.PailOfWater();
}

Note that, even though both packages are fully imported, there is no ambiguous reference in the code above, so the compiler happily tolerates the fact that a symbol of the same name is defined in two different, imported packages. Until it needs to find an unqualified symbol in an imported package, the compiler doesn't care if that symbol is defined more than once.

Note also that none of what I've said depends on thehill.jack and thehill.jill starting with thehill., as it will apply if those packages were just named jack and jill, (I just named them the way I did so they'd all show up near each other in "Experiments" project package tree in NetBeans).

As for JFrame in particular, you will see that NetBeans loves to subclass JFrame to create your "main" window for you. This is usually harmless, but folks here persuaded me that it's not the best practice, and offers no meaningful benefits. Better is to create a JFrame directly, and put a JPanel into it that you use the NetBeans GUI editor to create. If you are just getting started, go ahead and use the JFrame subclasses that NetBeans creates for you. Just remember someday, if you can, that creating your own JFrame is probably what you ought to be doing.

Thank you for your lengthy response. I kind of knew that about the jack and jill packages, but it is good reinforcement. As for netbeans subclassing JFrame, I found that to be the case with eclipse also. I haven't found a pro/con at my initial stage. When I run into a difference, I'll redo the code.

I was thinking there might be an option in netbeans to use short class names in the generated code ( eclipse does this by default). It was just a difference I noticed in my code.