For example
NavigationHandlerImpl#_navigationCases

I already fixed a few occurrences.

There are also a few other checkstyle errors waiting to get fixed like methods 
which are 450 lines long.. 

Would be cool if you could take a look at it - txs!


LieGrue,
strub



----- Original Message -----
> From: Leonardo Uribe <lu4...@gmail.com>
> To: myfaces-dev <dev@myfaces.apache.org>; Mark Struberg <strub...@yahoo.de>
> Cc: 
> Sent: Wednesday, October 26, 2011 10:45 PM
> Subject: Re: MYFACES-3368 status
> 
> Yes I know that, but where in myfaces we have a problem like that? so
> we can discuss it in deep.
> 
> 2011/10/26 Mark Struberg <strub...@yahoo.de>:
>>  Again (think I posted this before already), a very good source for java mem 
> spec behaviour is the comment of Brian Goetz
>> 
>>  http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
>> 
>>  This also explains why you need to declare the field volatile - don't 
> wanna stress this, but I told this also before... ;)
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Leonardo Uribe <lu4...@gmail.com>
>>>  To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg 
> <strub...@yahoo.de>
>>>  Cc:
>>>  Sent: Wednesday, October 26, 2011 8:40 PM
>>>  Subject: Re: MYFACES-3368 status
>>> 
>>>  Hi
>>> 
>>>  I'm keeping an eye on the changes done. I don't remember any 
> problem
>>>  about 'double lock' on myfaces. Could you please be more 
> specific? In
>>>  my understanding everything works as expected.
>>> 
>>>  regards,
>>> 
>>>  Leonardo Uribe
>>> 
>>>  2011/10/26 Mark Struberg <strub...@yahoo.de>:
>>>>   Hi folks!
>>>> 
>>>>   I'm down to 24 checkstyle issues (with LineLength=160, 
> otherwise ~600
>>>  more) which are really non-trivial.
>>>> 
>>>>   A few of them are 'equals() without hashCode()' which are
>>>  definitely problematic
>>>>   Then we have a few variable namings which I didn't want to 
> change
>>>  without talking to you.
>>>>   And of course there are some 'double lock idiom' issues.
>>>>   It's safe to use double-locking as of Java5, but ONLY if the 
> locked
>>>  variable is declared volatile! We barely have this, so I left the check
>>>  enabled...
>>>> 
>>>> 
>>>>   Who is taking care of those remaining issues? Leo?
>>>> 
>>>> 
>>>>   LieGrue,
>>>>   strub
>>>> 
>>>> 
>>> 
>> 
>

Reply via email to