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.
Please sign in to leave a comment.
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!"
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:
Now I'm ashamed... anyways, I've uploaded a new version that should fix this problem.
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
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
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
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 :)
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:
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.
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
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.
That would be unacceptably slow.
-
Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"
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:
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 :)
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:
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.
TestCase classes in test output path are not auto retroweaved yet?
Known bug, sorry. I'll be releasing a new version soon.
Shameless bump to say the 1.3 version was released[/url] today, including a working verifier ;)