You know that the default VM on MacOS is now 1.5 and leopard will
have a 1.6 default. I was merely suggesting upgrading our code base
to 1.5 I think we can build 1.4 libraries with 1.5 code base although
I have not tested it.
Pierre
On 20-Sep-06, at 4:00 AM, Ulrich Köster wrote:
> 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 : Thu Sep 21 2006 - 17:37:41 EDT