Re: Warnings when building wolips

From: Ulrich Köster (ulric..bjectstyle.org)
Date: Wed Sep 20 2006 - 07:00:58 EDT

  • Next message: Andrus Adamchik: "Re: [DONE] Re: Java App Bundle task"

    I don't like the idea of an update to 5. The default VM for Eclipse
    is 1.4. That means I have to answer a zillion emails on how to launch
    Eclipse with 1.5 and so on.

    The settings in the project are stronger then the workspace settings
    and we have per project settings.

    Uli

    Am 20.09.2006 um 12:27 schrieb Pierre Frisch:

    > One more question how does everyone feel about moving to Java5
    > source code compliance level? 5.0 source level compliance allows
    > us to use annotations and reduce the amount of type cast.
    >
    > By the way I have 553 warnings with the settings that Mike proposed.
    >
    > Pierre
    >
    > On 17-Sep-06, at 2:04 PM, Pierre Frisch wrote:
    >
    >> I can live with that setting although the parameter never read is
    >> one that I prefer to fix and in the medium term it would be good
    >> to add the serializable field in our component template as it
    >> would save a lot of grief to new users.
    >>
    >> How do you want me to do this in practice? I don't have commit
    >> access so I can send diff but it may be a bit tedious....
    >>
    >> Pierre
    >>
    >> On 17-Sep-06, at 11:59 AM, Mike Schrag wrote:
    >>
    >>> I think Pierre and I must run with a lot more of the stock
    >>> Eclipse warnings enabled since you only have 12 warnings
    >>> visible. Here are some notable ones that I love and/or hate :)
    >>>
    >>> Warnings that Can Catch Bugs
    >>> * Deprecation (not so much bugs, but just good to know)
    >>> * Local variable is never read (might imply that you used the
    >>> wrong variable somewhere)
    >>> * Unused local or private member (same)
    >>> * All the Name Shadowing warnings (this is just ASKING for
    >>> bugs). The only one I am likely to turn off is "field hides
    >>> another field" because it doesn't have an option to turn off
    >>> checks for static fields (Project Wonder has _Entity.log and
    >>> Entity.log that triggers this otherwise). Every other one of
    >>> these is just a good idea
    >>> * All the Potential Programming Problems warnings except Box/
    >>> Unbox and Serializable
    >>> * Parameter assignment
    >>> * Undocumented empty block
    >>>
    >>> Warnings that Don't Catch Bugs, but I Like to Fix Them
    >>> * Non-static access to static member
    >>> * Unused import
    >>> * Unnecessary else statement
    >>> * Unnecessary cast or instanceof
    >>> * Unnecessary declaration of thrown exception (this can give
    >>> false positives because of subclasses, though)
    >>>
    >>> Warnings I Don't Like
    >>> * Parameter is never read (this can give false positives because
    >>> of subclasses)
    >>> * Discouraged access rules (this was a really obnoxious addition
    >>> to Eclipse plugins because they hide tons of API that we use)
    >>> * Serializable (this catches a lot of stuff with WO)
    >>> * Unqualified access to an instance field (I personally hate
    >>> this.whatever)
    >>>
    >>> ms
    >>>
    >>> On Sep 17, 2006, at 2:04 PM, Ulrich Köster wrote:
    >>>
    >>>> First of all. The problems view includes a nice filter:
    >>>>
    >>>>
    >>>> <Bild 5.png>
    >>>>
    >>>> <Bild 6.png>
    >>>>
    >>>>
    >>>> A concerted effort would be something new for us. :-)
    >>>>
    >>>> I'm working on http://objectstyle.org/jira/browse/WOL-298 for
    >>>> quite a
    >>>> while. Most of the warnings belong to this task. You're welcome to
    >>>> reduce the numbers. (I'm doing that whenever I have the time for
    >>>> that. The deprecation stuff raised the number again.)
    >>>>
    >>>> The settings are in the svn. Any comments?
    >>>>
    >>>> Uli
    >>>>
    >>>> Am 17.09.2006 um 18:39 schrieb Mike Schrag:
    >>>>
    >>>>> The first step is probably to agree on what warning sets we
    >>>>> care about and commit those preferences into SVN. For instance,
    >>>>> if you turn on all warnings in Eclipse, there are some that you
    >>>>> can't actually fix without breaking things (unusued variables
    >>>>> and exceptions that are actually used by subclasses, for
    >>>>> instance). But I agree with you, I'd like to pick the warnings
    >>>>> we collectively think are important and knock them out. I did
    >>>>> a pass on Project Wonder just this past weekend and it's so
    >>>>> nice to have an empty warnings list.
    >>>>>
    >>>>> ms
    >>>>>
    >>>>> On Sep 17, 2006, at 12:11 PM, Pierre Frisch wrote:
    >>>>>
    >>>>>> Could we make a concerted effort to remove warnings when
    >>>>>> compiling wolips there are over 300 warnings when building
    >>>>>> wolips and the number is growing not diminishing!!! I really
    >>>>>> think we should try to reduce that number to 0. This is
    >>>>>> annoying for me as I am trying to work on wolips while having
    >>>>>> other projects open and I both sets of warning mix. I have
    >>>>>> always believe that warning are important and I have found
    >>>>>> over the year that fixing them pays big dividends when you
    >>>>>> look for that hard to find bug.
    >>>>>>
    >>>>>> Yes I am ready to volunteer and do some of the work.
    >>>>>>
    >>>>>> Thank you for the good work
    >>>>>>
    >>>>>> Pierre
    >>>>>
    >>>>
    >>>
    >>
    >



    This archive was generated by hypermail 2.0.0 : Wed Sep 20 2006 - 07:01:02 EDT