Re: [Codenarc-developer] CodeNarc 0.8.1 - New rules - SystemRunFinalizersOnExit

[Hamlet D'A. <ham...@gm...>]

I think it is a concurrency issue. Here is the deprecated message from
the Javadoc:

"This method is inherently unsafe. It may result in finalizers being
called on live objects while other threads are concurrently
manipulating those objects, resulting in erratic behavior or
deadlock."



-- 
Hamlet D'Arcy
ham...@gm...



On Wed, Apr 28, 2010 at 1:24 AM, Chris Mair <chr...@ea...> wrote:
>>> I think the new rules should go under a category called "concurrency"
>
> I agree. I was thinking the same thing after sending my email. This deserves
> a category all by itself.
>
> What about your SystemRunFinalizersOnExit rule? That's not really
> concurrency.
>
> -----Original Message-----
> From: Hamlet D'Arcy [mailto:ham...@gm...]
> Sent: Tuesday, April 27, 2010 12:51 AM
> To: Chris Mair
> Subject: Re: CodeNarc 0.8.1 - New rules
>
>
> I think the new rules should go under a category called "concurrency", but I
> was too lazy to create a new group... I just wanted to get my rules done and
> go to bed. I definitely plan on creating a few more rules around concurrency
> so that there is a more full-featured concurrency set. I would recommend
> moving the rules to concurrency but maybe waiting a few days to see if I
> really do have the time to create them :)
>
> I was pretty surprised how easy it was to create a tested rule. The only
> hangup was the integration tests failing on a giant HTML page comparison (i
> think).
>
> On Tue, Apr 27, 2010 at 4:24 AM, Chris Mair <chr...@ea...> wrote:
>> Hamlet,
>>
>> Awesome! So far I have collaborated with a few other developers by
>> individual email, but that was mostly just discussions. Yours is the
>> first formal submission of a completed rule + tests.
>>
>> I was intending on creating a new "Design" ruleset. Would your rules
>> be as appropriate there as in "Basic"? I had modeled the basic ruleset
>> on PMD -- those rules are considered "universal". That being said, the
>> categorization into rulesets is inevitably fuzzy and somewhat
>> ambiguous.
>>
>> I just created codenarc-developer and codenarc-user mailing lists on
>> SourceForge. So far, there are no publicly available rules that I am
>> aware of outside the CodeNarc distribution.
>>
>> Thanks.
>> Chris
>> -----Original Message-----
>> From: Hamlet D'Arcy [mailto:ham...@gm...]
>> Sent: Monday, April 26, 2010 2:59 AM
>> To: chr...@ea...
>> Subject: Re: [groovy-user] [ANN] Announcing CodeNarc 0.8.1
>>
>>
>> Hi Chris,
>>
>> I am interested in writing some CodeNarc rules.
>>
>> Is there a mailing list somewhere?
>> How does the community collaborate?
>> Are there any community rules that are not part of the core product?
>>
>> --
>> Hamlet D'Arcy
>> ham...@gm...
>>
>>
>>
>> On Wed, Feb 3, 2010 at 5:05 AM, Chris Mair <chr...@ea...>
>> wrote:
>>>  CodeNarc is a static analysis tool for Groovy source code.
>>>
>>>
>>>
>>> Version 0.8.1 is a bug-fix release and addresses some
>>> incompatibilities and bugs that crept in related to changes across
>>> Groovy 1.6 and 1.7:
>>>
>>>
>>>
>>> Bug Fixes
>>>
>>> Fix Bug #2943025: “NestedBlockDepthRule: Produces erroneous results
>>> on Groovy 1.6.x.”
>>> https://sourceforge.net/tracker/?func=detail&aid=2943025&group_id=250
>>> 1
>>> 45&atid=1126573
>>> Fix Bug #2943028: “PackageNameRule may show incorrect violations for
>> classes
>>> within the default package when running in Groovy 1.6.x.”
>>>
>> https://sourceforge.net/tracker/?func=detail&aid=2943028&group_id=2501
>> 45&ati
>> d=1126573
>>> Fix Bug #2935587 "Building CodeNarc 0.8 fails." - Problem from Joern
>> Huxhorn
>>> (Jan 18, 2010) – Unable to build from the downloaded
>>> CodeNarc-0.8-bin.tar.gz.
>>>
>> http://sourceforge.net/tracker/?func=detail&aid=2935587&group_id=25014
>> 5&atid
>> =1126573.
>>> Fix StackOverflow in Groovy 1.7.0 for some rules: All rules that
>>> implement the visitVariableExpression(VariableExpression expression)
>>> visitor method: UnusedVariableRule, UnusedPrivateFieldRule,
>>> GrailsSessionReferenceRule, GrailsServletContextReferenceRule –
>>> Removed call to
>>> super.visitVariableExpression(expression) since that seems to cause
>> problems
>>> (StackOverflow) in Groovy 1.7.0.
>>> DuplicateImportRule: Document that this rule does not work when
>>> running under Groovy 1.7 (i.e., will not produce any violations), and
>>> does not distinguish between multiple duplicate imports for the same
>>> class.
>>>
>>> http://codenarc.sourceforge.net
>>>
>>>
>>
>>
>
>
>
> --
> Hamlet D'Arcy
> ham...@gm...
>
>