ANN: Retroweaver Plugin

After too much whinning about the lack of retroweaver integration in IDEA, I'm proud to announce Retroweaver Plugin 1.0. This plugin will automatically retroweave all classes compiled by IDEA.

Right now, the plugin can't be any easier to use: all you have to do is install the plugin (it should be available on the Plugin Manager), and toggle the "Retroweave compiled classes" option in your "Build" menu. That's it, next time you compile the project, your classes will be automatically retroweaved. There are no configuration options whatsoever.

Actually... I lied. There are two configuration options, but they're not exposed in the UI. If you want to change them, you will have to open your .ipr file and edit the relevant options. You should find something like this on your .ipr file:

  
  
  
]]>

If you change "verbose" to "true", The plugin will spew the name of each retroweaved class in your compilation log. You can also change the target class version. The default is 48, which means the classes will be retroweaved to work with JDK 1.4. You can change it to 47 (JDK 1.3) or 46 (JDK 1.2). Changing it to any other value may have unpredictable results.

If you're confused about all this "retroweave" thing, and you're not sure about what it is, and how this applies to you, please visit the Retroweaver homepage at:

http://retroweaver.sf.net

Disclaimer: This wasn't developed by the Retroweaver team, but by myself, Marcus Brito, on a very boring day at work. Don't blame the Retroweaver guys for any problems with this plugin, blame me. My email address is show on my ITN profile if you need to yell at me.

Retroweaver is the work of Toby Reyelts:
Copyright (c) February 2004, Toby Reyelts
All rights reserved.

Retroweaver Plugin is the work of Marcus Brito:
Copyright (c) June 2005, Marcus Brito
All rigts reserved

For those who care, Retroweaver Plugin is released under the same license terms at retroweaver itself (BSD-like). I'll make the source (3 ridiculously simple classes) available as soon as I get home... in a few hours.

18 comments
Comment actions Permalink

Is that you Marcus, who uploaded broken XML to the repository? :))
http://www.jetbrains.net/jira/browse/IDEA-2929

-


Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

No! They forced me to do it, the aliens! It's not my fault... mumbles in a low voice

I even took care of correctly escaping the usual suspects in the plugin.xml:

Marcus Brito <mbrito@gmail.com>]]>

Now I'm ashamed... anyways, I've uploaded a new version that should fix this problem.

0
Comment actions Permalink

To keep a promise (and comply with the license), the sources are available as a darcs repository, here:

http://www.animegaiden.com.br/pazu/repos/retroweaver-plugin

If you've never used darcs for version control, read about it here:

http://www.darcs.net

0
Comment actions Permalink

Marcus

>To keep a promise (and comply with the license), the sources are available as a darcs repository, here:
>

>

A zip file in the wiki would be nice too :)

Alain

0
Comment actions Permalink

Marcus, could you please activate the -verifyrefs option, otherwise
Retroweaver seems useless, because then does not check the usage of 1.5-only
code (see http://www.javalobby.org/java/forums/m91837055.html)

Tom

0
Comment actions Permalink

That's what I'm working on, Thomas. The '-verifyrefs' option turns out not so simple as I expected -- for a first-time plugin writer, at least. To make it work, I need:

- A way to determine the project classpath (done)
- Remove JDK entries from this classpath (uh-oh)
- Add entries from a "target" JDK, chosen by the user (uh-oh)

Supposing that there is a way to do the above with the OpenAPI (I just need to find it out), I'll hopefully have that implemented in a couple of days. In the meanwhile, any advice is appreciated :)

0
Comment actions Permalink

I think it would be best to write your own reference verifier. The
verifier built into retroweaver sucks and is not usable for most
projects. It doesn't take inheritance into account, so if you call some
method in the JDK which is inherited from a superclass of the type on
which you're calling it, the verifier will say there's a problem. So, on
my projects I get hundreds of false positives which makes real positives
not worth it to search for.

Marcus Brito wrote:

That's what I'm working on, Thomas. The '-verifyrefs' option turns out not so simple as I expected -- for a first-time plugin writer, at least. To make it work, I need:

- A way to determine the project classpath (done)
- Remove JDK entries from this classpath (uh-oh)
- Add entries from a "target" JDK, chosen by the user (uh-oh)

Supposing that there is a way to do the above with the OpenAPI (I just need to find it out), I'll hopefully have that implemented in a couple of days. In the meanwhile, any advice is appreciated :)

0
Comment actions Permalink

I think it would be best to write your own reference
verifier. The
verifier built into retroweaver sucks and is not
usable for most
projects.


Eh, unfortunately I'm aware of the shortcomings of the Retroweaver built-in verifier. Problem is, I'm also aware of the limitations of my free time, and writing my own reference verifier might take longer than expected.

So that's the bad news: I probably won't be writing a decent reference verifier in the very near future. The good news is that Toby Reyelts (Retroweaver author) said he's working on improving the verifier, and when he's done with that, I'll be ready to integrate it into my plugin.

Also featured in this news flash: I've already figure out how to do the three tasks I outlined above using the OpenAPI. Hopefully I'll have a working version using the built-in (crappy, we know) Retroweaver verifier by wednesday, give or take.

0
Comment actions Permalink

I retract my words. While I was testing the new verifier functionality in the plugin with a couple of projects, I got convinced that the retroweaver verifier is useless indeed. Somehow I was used to know what methods are only available on JDK 1.5+ and instinctively I didn't use them -- I've never really used the retroweaver verifier.

Anyways... now I'll have to find time to write my own verifier, or wait for Toby Reyelts to implement the new one before thinking about exposing it in the plugin. sigh

0
Comment actions Permalink

I think the verifier would be easy to do using IDEA PSI API.

Marcus Brito wrote:
>>I think it would be best to write your own reference
>>verifier. The
>>verifier built into retroweaver sucks and is not
>>usable for most
>>projects.


Eh, unfortunately I'm aware of the shortcomings of the Retroweaver built-in verifier. Problem is, I'm also aware of the limitations of my free time, and writing my own reference verifier might take longer than expected.

So that's the bad news: I probably won't be writing a decent reference verifier in the very near future. The good news is that Toby Reyelts (Retroweaver author) said he's working on improving the verifier, and when he's done with that, I'll be ready to integrate it into my plugin.

Also featured in this news flash: I've already figure out how to do the three tasks I outlined above using the OpenAPI. Hopefully I'll have a working version using the built-in (crappy, we know) Retroweaver verifier by wednesday, give or take.


0
Comment actions Permalink

That would be unacceptably slow.

-


Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Don't you think that with caching of method signatures per JDK, it could
be acceptable to find all references using ASM or BCEL, then search the
cached method signature list from the JDK?

Maxim Shafirov (JetBrains) wrote:

That would be unacceptably slow.

-------------------
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

I've been experimenting a little more, and found a patch by Stefan Reich (of Dr.Java fame) on retroweaver sourceforge page that fixes the most critical problems with the verifier. With this patch applied, the verifier can find references on superclasses/interfaces, reducing the number of false positives. It's still not searching for fields in implemented interfaces, but that should be easy to fix.

Now the only caveat remaining is that the retroweaver verifier works on compiled classes -- meaning that I don't have a way to link warning messages back to a precise line/column in the source, and this seriously limits it's usefulness in a rich environment like IDEA.

For this reason alone, I'm thinking about writing a verifier that will work as an inspection, so we can get live feedback and batch analysis (otoh, we could lose compile-time verification). Any pointers in that direction would be appreciated :)

0
Comment actions Permalink

I'm thinking about it now, I think it would be an awesome in-editor
inspection, to get live feedback when you first use a non-1.4 feature.

Marcus Brito wrote:

I've been experimenting a little more, and found a patch by Stefan Reich (of Dr.Java fame) on retroweaver sourceforge page that fixes the most critical problems with the verifier. With this patch applied, the verifier can find references on superclasses/interfaces, reducing the number of false positives. It's still not searching for fields in implemented interfaces, but that should be easy to fix.

Now the only caveat remaining is that the retroweaver verifier works on compiled classes -- meaning that I don't have a way to link warning messages back to a precise line/column in the source, and this seriously limits it's usefulness in a rich environment like IDEA.

For this reason alone, I'm thinking about writing a verifier that will work as an inspection, so we can get live feedback and batch analysis (otoh, we could lose compile-time verification). Any pointers in that direction would be appreciated :)

0
Comment actions Permalink

As a side note, the new "alternate JRE for run configuration" feature in the new build is great for retroweaver users. Now you can compile your project with Java 5, have the plugin automatically retrofit your classes and then run your project with a 1.4 JRE, to make sure everything works -- all that with the press of one button.

0
Comment actions Permalink

TestCase classes in test output path are not auto retroweaved yet?

0
Comment actions Permalink

Known bug, sorry. I'll be releasing a new version soon.

0
Comment actions Permalink

Shameless bump to say the 1.3 version was released[/url] today, including a working verifier ;)

0

Please sign in to leave a comment.