How many warnings is too many?

[ricky.clarkson]

Thomas,

For normal uses
there is no point extending JPanel. But banning a component extending
JComponent is absurd.

To my eyes, the main difference between JPanel and JComponent is that
JPanel is opaque by default. I might have missed something. So I will
read your text as if you said JPanel twice and omitted JComponent..

What you say is true only if abnormal uses are justified. What are
these abnormal uses?

 

[Chris Smith]

Thomas,


To my eyes, the main difference between JPanel and JComponent is that
JPanel is opaque by default. I might have missed something. So I will
read your text as if you said JPanel twice and omitted JComponent..

What you say is true only if abnormal uses are justified. What are
these abnormal uses?

There's a difference of intent that matters. JPanel is intended to be
used as a container for other components, and not contain a lot of logic
of its own. I'm certain that's what Thomas meant. No point in
extending when you're just going to add children... but there is a point
in extending if you're implementing a true custom component.

The fact that custom components sometimes extend JPanel, or that
JComponent is technically a container, is irrelevant.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Don=3Ft you think it could be meaningful if the (static) inner class is
semantically very connected to its enclosing class? For example, I have
a class Function, which has a method getDomain, which returns an element
of the public static inner class Domain. Domain is nothing but a small
container class for two set variables, with appropriate getters. I
could very easily make that a top level class, but it sort of seems to
say something about the nature of this class that it belongs to the
Function class. Function.Domain is more meaningful than just Domain.

Until of course I think of other uses for the Domain class, but that
seems unlikely.

I=3Fm just asking for an opinion here, not criticising.

That's quite possibly the case. When you do this, though, you're also
tying the maintenance of the two together. Encapsulation just doesn't
do much good within a source file, unless your source files are WAY too
big.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Monique Y. Mudama]

I don't like extending classes where it isn't necessary. For normal
uses there is no point extending JPanel. But banning a component
extending JComponent is absurd.

Tom Hawtin

I can't get Ricky's post for some reason (news server must be
burping), but anyway, I'm working on a pretty complicated graphing app
right now, and I really don't think it would make sense to do anything
other than paint.

 

[Steve W. Jackson]

Working as a US gov't subcontractor I know that the Dept of Justice does
not allow any code to be put into operations if it has even 1 warning as
a result of a compile.

Which merely proves that the people in charge at DOJ are as ridiculously
anal as their DoD counterparts I've worked for over the years... As
another respondent has indicated, some warnings *may* be acceptable,
depending on their cause.

 

[Steve W. Jackson]

Monique,

There's no need to extend JPanel or JComponent. Most extensions are
just a way of saving typing (as in keypresses). The one that *looks*
like it's valid is overriding paintComponent for custom drawing, but
even that can be better done using an Icon and, usually, a JLabel.

If your class isn't supposed to be Serializable, but extends a class
that is, then you have a logic error. You are subclassing something
you shouldn't.

It's like buying a car and then complaining when someone asks for a
lift. Oh yeah, that happens..

This idea of not subclassing Swing components flies in the face of the
OO paradigm. If I'm going to have a JPanel with a series of other
components on it that will be used in multiple locations across my
application, then the very idea of NOT creating a subclass of JPanel for
that purpose is telling me to do it the hard way numerous times.

= Steve =

 

[Chris Smith]

This idea of not subclassing Swing components flies in the face of the
OO paradigm. If I'm going to have a JPanel with a series of other
components on it that will be used in multiple locations across my
application, then the very idea of NOT creating a subclass of JPanel for
that purpose is telling me to do it the hard way numerous times.

Not necessarily. You are welcome to write a method that builds and
returns this JPanel. You don't have to do it twice.

Of course, subclassing does give you extra options; i.e., it's far
easier to write a template method in a superclass than to pass in a
callback to a factory method. But the mere desire to avoid writing the
same code twice can't justify inheritance relationships.

Fortunately, OO design tends to just "make sense" after a certain amount
of practice. After you've practiced creating reusable clusters of
components without subclassing, it becomes obvious when subclassing is
necessary (or, as in the case of using Icon for custim components from
earlier this thread, avoiding it is too kludgy to be worthwhile).

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Monique Y. Mudama]

Not necessarily. You are welcome to write a method that builds and
returns this JPanel. You don't have to do it twice.

Of course, subclassing does give you extra options; i.e., it's far
easier to write a template method in a superclass than to pass in a
callback to a factory method. But the mere desire to avoid writing
the same code twice can't justify inheritance relationships.

What about a desire for readability?

Inheritance from JPanel immediately gives another developer an idea of
the intent of the class. And a callback to a factory method in this
case sounds suspiciously like obfuscation.

Fortunately, OO design tends to just "make sense" after a certain
amount of practice. After you've practiced creating reusable
clusters of components without subclassing, it becomes obvious when
subclassing is necessary (or, as in the case of using Icon for
custim components from earlier this thread, avoiding it is too
kludgy to be worthwhile).

As I may have said before, my current project involves an enormous
amount of drawing, and I really do need to deal with painting.

 

[ricky.clarkson]

When I see that a class inherits from another, I start looking for
overridden methods. If I don't find any, I wonder why it inherits at
all.

I think public static JPanel createRoutingTablePanel() expresses intent
equally as well as:

final class RoutingTablePanel extends JPanel.

I'm not sure why you would need a callback to a factory method, or what
that exactly is.

Subclassing JPanel just to add some buttons to it seems to me to be
akin to renaming a car whenever you add something new, e.g., electric
windows. Oh yeah, car manufacturers do that..

Do you subclass String when you want to only hold addresses in it? No.
You can't. Sun actually made String final, apparently for
implementation reasons. I'm very glad they did.

class Address extends String
{
}

As opposed to:

class Address
{
private final String data;
}

The way you are forced to do it means that you can't accidentally treat
your Address as a String.

Subclassing JPanel to make RoutingTablePanel means you could
accidentally treat the RoutingTablePanel as a JPanel, i.e., removeAll
and put new stuff on it, nicely confusing the RoutingTablePanel class.

 

[Thomas Hawtin]

Thomas,



To my eyes, the main difference between JPanel and JComponent is that
JPanel is opaque by default. I might have missed something. So I will

You are apparently not alone in missing something. JPanel is not
guaranteed to be opaque by default. It is PL&F dependent. For my machine
the PL&F that matches the common native look & feel may or may not set
JPanels to opaque depending upon which version of Java I use.

http://java.sun.com/docs/books/tutorial/uiswing/components/toplevel.html#contentpane

Tom Hawtin

 

[Scott Ellsworth]

I suppose this is a rather odd question but how many warnings is too many
when you are using a Java compiler like the one in Eclipse 3.1.1?

For me, even one warning showing up in production code is too many. I
try to eliminate them during development, but one might survive a day or
two during creation. Thus, I only activate warnings I am willing to
eliminate.

Our teams have a policy of mandatory and optional warnings. By this, we
mean that we have agreed on a set of warning messages that we will
eliminate when we get them. There is a much larger set that we suggest
programmers turn on, and eliminate as they get the chance.

This way, as code evolves, different people turn on different warnings
to eliminate them, and once we all feel that the code is 'pretty good',
we move a warning from the optional to the mandatory list.

Using the default settings for the 1.5 compiler in a fresh install of
Eclipse 3.1.1, my various projects have over 4000 messages between them, 22
of which are 'errors' that I have yet to repair. The rest are warnings of
one kind or another. I could decrease this number substantially by either
setting many conditions to 'error' or 'warning' when they are currently
'ignore' or increase it substantially by setting 'ignore' conditions to
'error' or 'warning'. And, of course, I could probably make the vast
majority of them go away simply by rewriting code.

This is typical. We saw much the same when we started using IDEA and
Eclipse. We turned off most of them, turned on a few that we thought
valuable, and have added one or two a month since. Most of us using
IDEA have had a larger set that we would routinely turn on and fix the
code, but that was a target of opportunity.

To put it another way, if you were considering hiring me to write Java for
you and asked me for an example of a completed project to inspect, what
conditions would YOUR compiler be set to detect and ignore and how many
errors and warnings would you consider acceptable? I'm going to guess that
the number of errors should always be zero in a completed project - correct
me if I'm wrong - but that some warnings would be tolerated, on the theory
that fixing every conceivable minor warning is not required to prove that
you write good code. Am I close?

Pretty close - for IDEA, I would suggest spending an afternoon reading
all of the possible warnings, then deciding which ones make sense for
your style. You can then use that as a matter of discussion during an
interview. For example, many of the 'optimization' ones are a bit
dodgy, while the threading and 'data members not private' ones have
caught problems for us.

Thus, if your code threw warnings with my set, I would want to know why.
A response like 'I see no real benefit in replacing a one character
string with an actual character, as both are equally expressive of
programmer intent.' might well fly with me, even though I usually have
that warning on.

Scott

 

[steve]

Working as a US gov't subcontractor I know that the Dept of Justice does
not allow any code to be put into operations if it has even 1 warning as
a result of a compile.

thats the problem with the government just not consistent.
it should be 3 counts and your out.

 

[Oliver Wong]

I suppose this is a rather odd question but how many warnings is too many
when you are using a Java compiler like the one in Eclipse 3.1.1?

87. 86 is just barely passable, 85 is okay. But once you've got 87, you
know you have problems.

Using the default settings for the 1.5 compiler in a fresh install of
Eclipse 3.1.1, my various projects have over 4000 messages between them,
22 of which are 'errors' that I have yet to repair. The rest are warnings
of one kind or another. I could decrease this number substantially by
either setting many conditions to 'error' or 'warning' when they are
currently 'ignore' or increase it substantially by setting 'ignore'
conditions to 'error' or 'warning'. And, of course, I could probably make
the vast majority of them go away simply by rewriting code.

I've got 15058 warnings in my current Eclipse workspace. The settings of
what are considered warnings and what aren't vary from project to project.
"Externalized Strings" is turned off everywhere, I think.

Some of my code is machine generated, so I can't just go in and fix the
warnings. I have to change the code-generator so that the code it generates
no longer generates warnings. Except the code-generator itself is generated,
so I can't directly edit that either.

That's my excuse for having 15058 warnings. When I'm programming at
home, for fun, none of my code is generated, and there's probably 0 warnings
right now, though it occasionally does reach the single non-zero digit
range. And I try to turn all the warnings on, except sometimes I get lazy,
and turn "externalized strings" off.

The only time I use "@SuppressWarning" is for those "impossible to
avoid" situations with generics, and I accompany the annotations with a
comment explaining why I believe that the warning is unavoidable.
Unfortunately, @SuppressWarning seems to work on a whole method, instead of
on a particular warning, so I occasionally have to remove them to make sure
I didn't introduce new warnings without my realizing it.

I'd be surprised if anyone turned _all_ conditions to 'warning' or 'error'
and then fixed every single one of the warnings and errors so that the
entire workspace was error-free but maybe I'm wrong. That's why I'd like
some feedback on just how many errors and warnings is considered okay and
what is considered excessive.
Surprise!


To put it another way, if you were considering hiring me to write Java for
you and asked me for an example of a completed project to inspect, what
conditions would YOUR compiler be set to detect and ignore and how many
errors and warnings would you consider acceptable? I'm going to guess that
the number of errors should always be zero in a completed project -
correct me if I'm wrong - but that some warnings would be tolerated, on
the theory that fixing every conceivable minor warning is not required to
prove that you write good code. Am I close?

For what it's worth, when I got this job, they never asked me anything
about my philosophy on warnings. On the other hand, they did give me a
(simple) programming problem and asked me to solve it, so they got to see
what kind of code I wrote. Maybe they combed it for warnings, maybe they
didn't. At any rate, the code I gave them had zero warnings with the default
warning/error/ignore settings they had on the workstation they were testing
me on.

Also, errors should almost always be zero, as the javac compiler will
refuse to compile code with errors. Eclipse seems to be able to compile code
with errors (I believe it just replaces the erroneus block with boilerplate
code which just throws an exception), so it's conceivable there might be
shops out there who are willing to tolerate errors in an Eclipse
environment.

Also, when you're compilation tools, sometimes things that one tool
(e.g. javac) considers an error is not to be considerd an error by another
tool (e.g. your inhouse compiler), so there are cases there where errors
might be okay too.

Can anyone give me guidelines to help me determine just what warnings I
should never tolerate and which I should feel free to ignore without
making me look like a bad coder?

I think "number of warnings" is not where you should focus your concern.
For every setting in Eclipse, do you understand what the warning associated
with it means? Could you explain it to another programmer?

- Oliver

 

[Oliver Wong]

When I see that a class inherits from another, I start looking for
overridden methods. If I don't find any, I wonder why it inherits at
all.

Because the child class has an IS-A relationship with the parent class,
and it adds methods, without changing the behaviour of the existing methods?

I think public static JPanel createRoutingTablePanel() expresses intent
equally as well as:

final class RoutingTablePanel extends JPanel.

I'm not sure why you would need a callback to a factory method, or what
that exactly is.

I don't know about the "callback" part, but based on the name
"createRoutingTablePanel", this sounds like a factory method.

Subclassing JPanel just to add some buttons to it seems to me to be
akin to renaming a car whenever you add something new, e.g., electric
windows. Oh yeah, car manufacturers do that..

Well, there is the concept of "what are the childrens of this widget"? A
"TwoButtonPanel" might have zero children, if you haven't added any buttons
to that Panel, while a "JPanel with two buttons" always has at least 2
children.

Do you subclass String when you want to only hold addresses in it? No.
You can't. Sun actually made String final, apparently for
implementation reasons. I'm very glad they did.

class Address extends String
{
}

As opposed to:

class Address
{
private final String data;
}

The way you are forced to do it means that you can't accidentally treat
your Address as a String.

class Age extends Number {

/*...Other methods here...*/

public Time getExpectedTimeOfDeath() {
return NOW;
}
}

Is this really so bad?

Subclassing JPanel to make RoutingTablePanel means you could
accidentally treat the RoutingTablePanel as a JPanel, i.e., removeAll
and put new stuff on it, nicely confusing the RoutingTablePanel class.

JPanel, specifically, is somewhat of a headache to subclass, because you
have to make sure that every operation defined on JPanel also makes sense
for your subclass (and there are so many operations!) If this is not the
case, then your subclass probably does not have an IS-A relationship with
JPanel.

- Oliver