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

We are pleased to announce the release of LockSmith, bringing the power of automated refactoring to concurrent Java programming. IntelliJ IDEA has long been most powerful automated refactoring tool available. LockSmith extends this power to concurrent programming, helping you to build multi-threaded applications quickly and safely.

Refactorings provided by LockSmith include

*Split Lock
*Merge Lock
*Make Class Thread-Safe
*Lock Method Call-Sites
*Split Critical Section
*Shrink Critical Section
*Merge Critical Sections
*Convert Synchronization Field To Lock
*Convert Simple Lock to Read-Write Lock
*Convert Read-Write Lock to Simple Lock
*Make Field Atomic
*Make Field ThreadLocal

Single-developer licenses for LockSmith are available for $39. 14-day evaluation are also available. LockSmith requires IntelliJ IDEA 5.0 or greater. To learn more about LockSmith or to request a license, visit us at http://www.sixthandredriver.com

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

18 comments
Comment actions Permalink


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?)


0
Comment actions Permalink

>"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"

0
Comment actions Permalink

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


0
Comment actions Permalink

+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"

0
Comment actions Permalink

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

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

0
Comment actions Permalink

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


0
Comment actions Permalink

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


0
Comment actions Permalink

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"

0
Comment actions Permalink

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


0
Comment actions Permalink

+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.

0
Comment actions Permalink

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();
}

0
Comment actions Permalink

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

0
Comment actions Permalink

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

0
Comment actions Permalink

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"

0
Comment actions Permalink

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

0
Comment actions Permalink

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"

0
Comment actions Permalink

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

Thanks, etienne

0
Comment actions Permalink

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

0

Please sign in to leave a comment.