We have a lot of people using windows. Classes with Java 5 compliance
won't run under 1.4.*. I think we should wait until an official
switch by the eclipse team.
Uli
Am 21.09.2006 um 23:37 schrieb Pierre Frisch:
> 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 : Fri Sep 22 2006 - 04:12:53 EDT