[Ann] LockSmith: concurrency-oriented refactorings for IntelliJ IDEA

I've only been playing with it for 5 minutes, but so far...I like the direction
this is going!

Two comments so far (likely more somewhere next week):
-"make class threadsafe" seems to work on all methods, event methods that
don't mutate state
-JCiP @GuardedBy support would be very nice, especially with references from
the attribute value to the lock (simple ReferenceProvider?)

>"make class threadsafe" seems to work on all methods, event methods that
don't mutate state

Well, it's not enough to protect the mutators, you also have to protect the accessors, because otherwise you could be reading partially modified state. We decided for safety to protect all (non-private, non-static, non-constructor) methods, although we will admit that protecting completely empty methods seems odd. Note that if you request that a read-write lock be created, that methods which don't mutate state will be locked for read, which may allow for greater concurrency.

>JCiP @GuardedBy support would be very nice, especially with references from
the attribute value to the lock (simple ReferenceProvider?)

Marketing loved this idea, and dev said it was easy, so we'll be including it in version 1.1, available later today. The Split Lock, Merge Locks, Make Class ThreadSafe, and Lock Call-Sites refactorings are now JCiP aware, and renaming a lock field will rename any linked @GuardedBy annotations. We will also be adding a handful of JCiP inspections in version 1.2, simply because any given Sixth and Red River product will eventually accrete some inspections and intentions.

Sixth and Red River Software
"Code with Grace and Verve"

Hello Sixth and Red River Software,

>> "make class threadsafe" seems to work on all methods, event methods
>> that
>>

don't mutate state

Well, it's not enough to protect the mutators, you also have to
protect the accessors, because otherwise you could be reading
partially modified state. We decided for safety to protect all
(non-private, non-static, non-constructor) methods, although we will
admit that protecting completely empty methods seems odd. Note that
if you request that a read-write lock be created, that methods which
don't mutate state will be locked for read, which may allow for
greater concurrency.

You are quite right of course. It was late when I wrote that post.
I indeed should have written: "access state".

>> JCiP @GuardedBy support would be very nice, especially with
>> references from
>>

the attribute value to the lock (simple ReferenceProvider?)

Marketing loved this idea, and dev said it was easy, so we'll be
including it in version 1.1, available later today. The Split Lock,
Merge Locks, Make Class ThreadSafe, and Lock Call-Sites refactorings
are now JCiP aware, and renaming a lock field will rename any linked
@GuardedBy annotations. We will also be adding a handful of JCiP
inspections in version 1.2, simply because any given Sixth and Red
River product will eventually accrete some inspections and intentions.

Thanks. I rename stuff often, so I think this is usefull.

Btw, what's your opinion on the other JCiP annotations, both in terms of
usefullness and potential for tooling?

Regards,
-tt

+Btw, what's your opinion on the other JCiP annotations, both in terms of
usefullness and potential for tooling?+

Well, there's obvious potential for tooling around both @ThreadSafe and @Immutable, mostly in terms of inspections rather than refactoring (FindBugs already has some support for this). Otherwise, I think the JCiP annotations are very much an 80/20 compromise. They neatly cover the concurrency needs of almost all Java classes, but are nowhere near what's necessary for more complex and active classes. That said, I absolutely love 80/20 compromises, and think widespread adoption of the JCiP annotations would be an excellent step forward for the industry.

You might also want to look at the CMS-Fluid work. It's more powerful, but seems like it will require much more tooling and training.

Sixth and Red River Software
"Code with Grace and Verve"

LockSmith 1.1 has been released, with the new JCiP support available.

Sixth and Red River Software
"Code with Grace and Verve"

Hello Sixth and Red River Software,

It seems you're not providing variants in the reference provider?
I would at least expect completion suggestions for "this", and for member
fields. Currently I get no suggestions at all.

Also, it seems that making the provided references non-soft gets rid of the
(soft) references provided by the build-in filepath and resource key providers.

Regards,
-tt

Forgot to menion, above comment is about completion inside @GuardedBy("").

Taras,

Good catch. This will be fixed in the next rev (whose release was just delayed a week for reasons that should be obvious).

Sixth and Red River Software
"Code with Grace and Verve"

Here's another small enhancement request, which actually applies to all your
plugins.

Any registration / evaluation expiration ("expires in 8 days..." notices)
messageboxes are completely obscured at IDEA startup. I have to Alt-Tab away
from IDEA, and then Alt-Tab back to actually notice that there's a messagebox
active. Without knowing this, it's very easy to mistake this for a locked/dead
process.

Platform is Windows 2000, using the IDEA default JRE, and the Alloy.IDEA L&F.

If you're not able to fix this yourself, please ping Jetbrains to add some
functionality to make this more user-friendly. The first time I ran into
this I wasted it wasted a lot of my time.
I can only hope that no potential customers were annoyed enough to reconsider
a purchase..

Regards,
-tt

+256

Caused me some issues this weekend; pulled locksmith and dependency plugins for now.

Same thing also happens if the plugin key expires and and the registration window pops up. Sometimes, these can even be a bit of pain to get them to come out(alt-tab does not always do it).

Win XP, IDEA default JRE, and Windows L&F.

hello

I would have expected that LockSmith inspects and complains about the code below. Or am I overseeing something?

etienne

public final class Foo {
public void clear() {
// access not guarded as defined in annotation
_bar.clear();
}

private final Object LOCK = new Object();

/**

• @GuardedBy(LOCK)

*/
private final Map _bar = new HashMap();
}

At present, LockSmith only notices actual JCiP annotations, not the Javadoc form. We'll put it on the TODO list. Should be quick to add.

Sixth and Red River Software
"Code with Grace and Verve

Using annotations did not give me an inspection warning, neither:

public final class Foo {
public void clear() {
// access not guarded as defined in annotation
_bar.clear();
}

private final Object LOCK = new Object();

@GuardedBy("LOCK")
private final Map _bar = new HashMap();
}

etienne

That exact code does give us an inspection warning on the "_bar" in "_bar.clear()". Are you using the @net.jcip.annotations.GuardedBy annotation, or getting it from somewhere else? Is it possible you don't have the inspection turned on?

Sixth and Red River Software
"Code with Grace and Verve"

I checked: I don't even see these inspections in the 'Errors' settings. I'm using IDEA 6.0.5.

etienne

PS There are a few typos in the resources_en.jar: @GaurdedBy

The inspections have been fixed to work with document tags, as well as annotations, in version 1.2, now available via the plugin manager.

Sixth and Red River Software
"Code with Grace and Verve"

Very cool. The intentions now show up and work properly in my IDEA 6.0.5.

Thanks, etienne

The LockSmith inspection "FieldAccessNotGuarded" complains if I do not guard a field (that is annotated with @GuardedBy), assigning it a value in the constructor.

etienne