You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Paul Ferraro <pm...@columbia.edu> on 2005/08/24 03:12:47 UTC
Eclipse org.eclipse.jdt.core.prefs
Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is set
to flag certain "unused code" warnings (e.g. unused imports,
unreferenced local variables, etc.) as errors?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Jesse Kuhnert <jk...@gmail.com>.
"Oh"...I didn't know so many warnings/errors were being ignored. I
guess I'd have to agree then. It's easier to frown and look
dissapointed with someone when they work right next to you vs the
internet...I'd go insane if I saw tons of warnings/errors being
checked in by people....
On 8/25/05, Kevin Menard <km...@servprise.com> wrote:
>
> On Aug 24, 2005, at 8:01 PM, Jesse Kuhnert wrote:
>
> > You could add in the checkstyle plugin for some of these things as
> > well?....
>
> Once again, more of a general experience thing than actual Tapestry
> dev, but marking them as error forces me to remove useless imports,
> unused variables, etc. up front. This code then never gets committed
> to the repository. Making them warnings and using checkstyle allows
> this "bad" code to go into the repository and requires the programmer
> to decide at some point to take the time and go through the whole
> project; I've found this generally doesn't happen. The other issue
> is that by deferring the action, it becomes harder to recall what the
> code is doing. By making it an error, you're forced to deal with the
> issue up front so it's generally clearer what's causing the "error".
>
> Anyway, just my thoughts on it.
>
> --
> Kevin
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Kevin Menard <km...@servprise.com>.
On Aug 24, 2005, at 8:01 PM, Jesse Kuhnert wrote:
> You could add in the checkstyle plugin for some of these things as
> well?....
Once again, more of a general experience thing than actual Tapestry
dev, but marking them as error forces me to remove useless imports,
unused variables, etc. up front. This code then never gets committed
to the repository. Making them warnings and using checkstyle allows
this "bad" code to go into the repository and requires the programmer
to decide at some point to take the time and go through the whole
project; I've found this generally doesn't happen. The other issue
is that by deferring the action, it becomes harder to recall what the
code is doing. By making it an error, you're forced to deal with the
issue up front so it's generally clearer what's causing the "error".
Anyway, just my thoughts on it.
--
Kevin
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Jesse Kuhnert <jk...@gmail.com>.
not that I have any say in any of this at all, but based on my
eclipse experience the warning would definitely be preferred to error,
unless you guys are absolutely requiring the thing marked as an error
be fixed by anyone immediately...Errors have always been fatal
"something very bad has happened" sort of things. .
You could add in the checkstyle plugin for some of these things as well?....
j
On 8/24/05, Paul Ferraro <pm...@columbia.edu> wrote:
> But by doing this we are *decreasing* the visibility of real compilation
> errors since they are now indiscernable from non-critical warnings.
> More importantly, when the Eclipse compiler flags these things as errors
> it does not generate .class files (as if there was an actual compilation
> error) and I can no longer run a one-off junit tests from within Eclipse
> if a dependency file is flagged as an error. This is quite
> couterproductive to the way I am used to using Eclipse. I guess this
> wouldn't be an issue if the current cvs head branch didn't contain so
> many of these non-critical errors.
> I still don't understand why we can't just declassify the warnings we
> don't care about (e.g. missing type parameters for generics) by setting
> the compiler settings to "ignore", leave warnings we do care about as
> "warnings", and reserve the "error" setting for actual compilation errors.
>
> Paul
>
> Richard Lewis-Shell wrote:
>
> > I prefer them to be errors. Warnings are too easy to ignore, even
> > when there are only a few of them...
> >
> > Paul Ferraro wrote:
> >
> >> But they are not errors... I'd rather be able to easily identify
> >> compilation errors than identify warnings.
> >> e.g. I had to revert the compiler warning settings so that I could
> >> track down the uncompilable AbstractFormComponent in CVS head.
> >> If you are having an issue with too many warnings, then wouldn't it
> >> be better to change the compiler settings to "ignore" the warnings
> >> you want to ignore (e.g. warnings regarding generics), and revert
> >> these settings back to "warning"?
> >>
> >> Howard Lewis Ship wrote:
> >>
> >>> Because those are errors? Normally, I'd want them to be warnings and
> >>> we could get rid of those warnings, but with JDK 1.5 and all the
> >>> deprecation going on, warnings are no longer useful ... lost in a sea
> >>> of useless information about generics and such.
> >>>
> >>> On 8/23/05, Paul Ferraro <pm...@columbia.edu> wrote:
> >>>
> >>>
> >>>> Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is
> >>>> set
> >>>> to flag certain "unused code" warnings (e.g. unused imports,
> >>>> unreferenced local variables, etc.) as errors?
> >>>>
> >>>> Paul
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Paul Ferraro <pm...@columbia.edu>.
Done. Eclipse will now ignore any warnings related to JDK 5.0 features
(with the exception of annotations).
I've reverted the non-critical compiler errors back to warning. To
facilitate this, I've also cleaned up the current code base (e.g. unused
imports, missing serialVersionUIDs, etc.).
The code base is now error/warning free! (as far as Eclipse is concerned)
Paul
Howard Lewis Ship wrote:
>Paul --- give it a try! I'm not wedded to these settings, let's see
>if warnings work better (when extraneous warnings are turned off).
>
>On 8/24/05, Paul Ferraro <pm...@columbia.edu> wrote:
>
>
>>But by doing this we are *decreasing* the visibility of real compilation
>>errors since they are now indiscernable from non-critical warnings.
>>More importantly, when the Eclipse compiler flags these things as errors
>>it does not generate .class files (as if there was an actual compilation
>>error) and I can no longer run a one-off junit tests from within Eclipse
>>if a dependency file is flagged as an error. This is quite
>>couterproductive to the way I am used to using Eclipse. I guess this
>>wouldn't be an issue if the current cvs head branch didn't contain so
>>many of these non-critical errors.
>>I still don't understand why we can't just declassify the warnings we
>>don't care about (e.g. missing type parameters for generics) by setting
>>the compiler settings to "ignore", leave warnings we do care about as
>>"warnings", and reserve the "error" setting for actual compilation errors.
>>
>>Paul
>>
>>Richard Lewis-Shell wrote:
>>
>>
>>
>>>I prefer them to be errors. Warnings are too easy to ignore, even
>>>when there are only a few of them...
>>>
>>>Paul Ferraro wrote:
>>>
>>>
>>>
>>>>But they are not errors... I'd rather be able to easily identify
>>>>compilation errors than identify warnings.
>>>>e.g. I had to revert the compiler warning settings so that I could
>>>>track down the uncompilable AbstractFormComponent in CVS head.
>>>>If you are having an issue with too many warnings, then wouldn't it
>>>>be better to change the compiler settings to "ignore" the warnings
>>>>you want to ignore (e.g. warnings regarding generics), and revert
>>>>these settings back to "warning"?
>>>>
>>>>Howard Lewis Ship wrote:
>>>>
>>>>
>>>>
>>>>>Because those are errors? Normally, I'd want them to be warnings and
>>>>>we could get rid of those warnings, but with JDK 1.5 and all the
>>>>>deprecation going on, warnings are no longer useful ... lost in a sea
>>>>>of useless information about generics and such.
>>>>>
>>>>>On 8/23/05, Paul Ferraro <pm...@columbia.edu> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is
>>>>>>set
>>>>>>to flag certain "unused code" warnings (e.g. unused imports,
>>>>>>unreferenced local variables, etc.) as errors?
>>>>>>
>>>>>>Paul
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Howard Lewis Ship <hl...@gmail.com>.
Paul --- give it a try! I'm not wedded to these settings, let's see
if warnings work better (when extraneous warnings are turned off).
On 8/24/05, Paul Ferraro <pm...@columbia.edu> wrote:
> But by doing this we are *decreasing* the visibility of real compilation
> errors since they are now indiscernable from non-critical warnings.
> More importantly, when the Eclipse compiler flags these things as errors
> it does not generate .class files (as if there was an actual compilation
> error) and I can no longer run a one-off junit tests from within Eclipse
> if a dependency file is flagged as an error. This is quite
> couterproductive to the way I am used to using Eclipse. I guess this
> wouldn't be an issue if the current cvs head branch didn't contain so
> many of these non-critical errors.
> I still don't understand why we can't just declassify the warnings we
> don't care about (e.g. missing type parameters for generics) by setting
> the compiler settings to "ignore", leave warnings we do care about as
> "warnings", and reserve the "error" setting for actual compilation errors.
>
> Paul
>
> Richard Lewis-Shell wrote:
>
> > I prefer them to be errors. Warnings are too easy to ignore, even
> > when there are only a few of them...
> >
> > Paul Ferraro wrote:
> >
> >> But they are not errors... I'd rather be able to easily identify
> >> compilation errors than identify warnings.
> >> e.g. I had to revert the compiler warning settings so that I could
> >> track down the uncompilable AbstractFormComponent in CVS head.
> >> If you are having an issue with too many warnings, then wouldn't it
> >> be better to change the compiler settings to "ignore" the warnings
> >> you want to ignore (e.g. warnings regarding generics), and revert
> >> these settings back to "warning"?
> >>
> >> Howard Lewis Ship wrote:
> >>
> >>> Because those are errors? Normally, I'd want them to be warnings and
> >>> we could get rid of those warnings, but with JDK 1.5 and all the
> >>> deprecation going on, warnings are no longer useful ... lost in a sea
> >>> of useless information about generics and such.
> >>>
> >>> On 8/23/05, Paul Ferraro <pm...@columbia.edu> wrote:
> >>>
> >>>
> >>>> Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is
> >>>> set
> >>>> to flag certain "unused code" warnings (e.g. unused imports,
> >>>> unreferenced local variables, etc.) as errors?
> >>>>
> >>>> Paul
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Paul Ferraro <pm...@columbia.edu>.
But by doing this we are *decreasing* the visibility of real compilation
errors since they are now indiscernable from non-critical warnings.
More importantly, when the Eclipse compiler flags these things as errors
it does not generate .class files (as if there was an actual compilation
error) and I can no longer run a one-off junit tests from within Eclipse
if a dependency file is flagged as an error. This is quite
couterproductive to the way I am used to using Eclipse. I guess this
wouldn't be an issue if the current cvs head branch didn't contain so
many of these non-critical errors.
I still don't understand why we can't just declassify the warnings we
don't care about (e.g. missing type parameters for generics) by setting
the compiler settings to "ignore", leave warnings we do care about as
"warnings", and reserve the "error" setting for actual compilation errors.
Paul
Richard Lewis-Shell wrote:
> I prefer them to be errors. Warnings are too easy to ignore, even
> when there are only a few of them...
>
> Paul Ferraro wrote:
>
>> But they are not errors... I'd rather be able to easily identify
>> compilation errors than identify warnings.
>> e.g. I had to revert the compiler warning settings so that I could
>> track down the uncompilable AbstractFormComponent in CVS head.
>> If you are having an issue with too many warnings, then wouldn't it
>> be better to change the compiler settings to "ignore" the warnings
>> you want to ignore (e.g. warnings regarding generics), and revert
>> these settings back to "warning"?
>>
>> Howard Lewis Ship wrote:
>>
>>> Because those are errors? Normally, I'd want them to be warnings and
>>> we could get rid of those warnings, but with JDK 1.5 and all the
>>> deprecation going on, warnings are no longer useful ... lost in a sea
>>> of useless information about generics and such.
>>>
>>> On 8/23/05, Paul Ferraro <pm...@columbia.edu> wrote:
>>>
>>>
>>>> Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is
>>>> set
>>>> to flag certain "unused code" warnings (e.g. unused imports,
>>>> unreferenced local variables, etc.) as errors?
>>>>
>>>> Paul
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Richard Lewis-Shell <rl...@mac.com>.
I prefer them to be errors. Warnings are too easy to ignore, even when
there are only a few of them...
Paul Ferraro wrote:
> But they are not errors... I'd rather be able to easily identify
> compilation errors than identify warnings.
> e.g. I had to revert the compiler warning settings so that I could track
> down the uncompilable AbstractFormComponent in CVS head.
> If you are having an issue with too many warnings, then wouldn't it be
> better to change the compiler settings to "ignore" the warnings you want
> to ignore (e.g. warnings regarding generics), and revert these settings
> back to "warning"?
>
> Howard Lewis Ship wrote:
>
>> Because those are errors? Normally, I'd want them to be warnings and
>> we could get rid of those warnings, but with JDK 1.5 and all the
>> deprecation going on, warnings are no longer useful ... lost in a sea
>> of useless information about generics and such.
>>
>> On 8/23/05, Paul Ferraro <pm...@columbia.edu> wrote:
>>
>>
>>> Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is set
>>> to flag certain "unused code" warnings (e.g. unused imports,
>>> unreferenced local variables, etc.) as errors?
>>>
>>> Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Kevin Menard <km...@servprise.com>.
On Aug 24, 2005, at 2:12 PM, Paul Ferraro wrote:
> But they are not errors... I'd rather be able to easily identify
> compilation errors than identify warnings.
> e.g. I had to revert the compiler warning settings so that I could
> track down the uncompilable AbstractFormComponent in CVS head.
> If you are having an issue with too many warnings, then wouldn't it
> be better to change the compiler settings to "ignore" the warnings
> you want to ignore (e.g. warnings regarding generics), and revert
> these settings back to "warning"?
Not totally related, but I have these set as errors for my projects
too. It helps to make sure useless code doesn't get committed. I
found it's quite easy to ignore warnings about things you generally
want to be warned about, but don't care about in some contexts (e.g.,
not specifying serialVersionID) and sometimes other things get lost
in this. With that said, the @SuppressWarnings annotation is rather
helpful. However, marking these other things as errors really hasn't
been a problem for me, since it is only flagging useless code.
--
Kevin
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Paul Ferraro <pm...@columbia.edu>.
But they are not errors... I'd rather be able to easily identify
compilation errors than identify warnings.
e.g. I had to revert the compiler warning settings so that I could track
down the uncompilable AbstractFormComponent in CVS head.
If you are having an issue with too many warnings, then wouldn't it be
better to change the compiler settings to "ignore" the warnings you want
to ignore (e.g. warnings regarding generics), and revert these settings
back to "warning"?
Howard Lewis Ship wrote:
>Because those are errors? Normally, I'd want them to be warnings and
>we could get rid of those warnings, but with JDK 1.5 and all the
>deprecation going on, warnings are no longer useful ... lost in a sea
>of useless information about generics and such.
>
>On 8/23/05, Paul Ferraro <pm...@columbia.edu> wrote:
>
>
>>Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is set
>>to flag certain "unused code" warnings (e.g. unused imports,
>>unreferenced local variables, etc.) as errors?
>>
>>Paul
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Eclipse org.eclipse.jdt.core.prefs
Posted by Howard Lewis Ship <hl...@gmail.com>.
Because those are errors? Normally, I'd want them to be warnings and
we could get rid of those warnings, but with JDK 1.5 and all the
deprecation going on, warnings are no longer useful ... lost in a sea
of useless information about generics and such.
On 8/23/05, Paul Ferraro <pm...@columbia.edu> wrote:
> Is there a reason why the org.eclipse.jdt.core.prefs file in CVS is set
> to flag certain "unused code" warnings (e.g. unused imports,
> unreferenced local variables, etc.) as errors?
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org