[Java lista] netbeans 5.5 rc1

[Peter Fabian]

Auth Gábor wrote:
> Halihó!
>
> Peter Fabian -Sun ONE ezt írta:
>   
>> 5.5 RC1
>>     
>
>   Egy kérdés: a 6.0 miben tud többet, mint az 5.5? Egyátalán minek kell 
> 5.5, ha 6.0 is van lassan? :)
>   
-az 5.5 fókusza: javaEE1.5, ejb3, webservices, uml stb stb.

-6.0 jövő év közepére tervezett ha jól emlékszem, néhány dolog ami 
olvasható a 6-ról (egy lapra összeömlesztett feature lista még nincs):

-Matisse roadmap:
http://form.netbeans.org/roadmap.html
-a másik nagy dolog az új editor infrastruktúra lesz
http://blogs.sun.com/jlahoda/entry/new_features_in_netbeans_ide
erről is beszélt Tim Boudreau a
http://www.artima.com/lejava/articles/future_of_netbeans.html
cikkben, ebből idézek:

"In 6.0, we're migrating to a new API for parsing a Java syntax tree. 
That is based on the new Java Compiler API spec [JSR 199], which is a 
canonical API for interacting with the Java compiler and with the data 
the compiler produces. It gives you access to the guts of the [Java] 
compiler, and especially to what the compiler's parser does. That allows 
us to integrate /javac/ directly into the IDE. It sits underneath the 
editor, and makes possible many new editor features. One thing you can 
do, for example, is to compile code on the fly as you type. Using the 
parser from the Java compiler also gives you really accurate information 
about the code, and allows you to build code refactoring tools that are 
more powerful than what's available in other tools today.

Speaking of refactoring, you may have heard of the Jackpot project that 
defines a pattern language for matching in a Java syntax tree and then, 
more important, for doing transformations on that tree. Jackpot came out 
of SunLabs, and is now available in development builds of NetBeans.

The implications of these tools are pretty profound, because they change 
the meaning of how you deal with backwards compatibility, and how much 
of an issue backwards compatibility is. Suppose that I'm maintaining a 
library, and need to make some backward-incompatible change. I paint 
myself into a corner where I can't fix a bug without breaking some part 
of the API, for instance, by making something that was legal, illegal in 
the new version. Nobody designs their APIs perfectly from the get-go, so 
those situations happen.

With these tools, I can write a simple transform that anybody using this 
library can run against their code, and that transformer will update 
their code to the new version. I'm not talking about a shell script, but 
something built around stuff that's in Java source files, something that 
does that update correctly, and is pretty fool-proof. For instance, we 
are shipping a rule that converts |StringBuffer|usages to 
|StringBuilder|, and another one that updates |StringTokenizer| to 
|Scanner|.

Jackpot has the potential to do rather large refactorings correctly, and 
it actually brings down the cost of writing transformations or 
refactorings rather, makes those refactorings reasonable even in 
esoteric situations. Just the other day, I was contemplating how to 
refactor existing Swing code that uses |ActionListener|s on UI controls 
to turn all those |ActionListener|s into |Action| objects, move the 
right code to the right places, and end up with something better 
factored, easy to understand, and compilable. That sort of thing nobody 
would have attempted prior to Jackpot---it would have just been too 
ambitious and too hard to get right for the amount of value such a tool 
would bring.

There are still cases where subtleties and mismatches prevent you from 
automatical update. For ninety-nine percent of the cases, you can write 
a transformer that removes the upgrade pain. And the transformer can 
flag even that remaining one percent. Sometimes the replacement for 
something that was deprecated or removed before may not have a direct 
equivalent for a method, if that method was rarely used. For that 
situation, deciding the right thing is up to the user. For all those 
transformations, you can see a preview and diff for every change that is 
to be made. So it's not just refactoring, it's code re-engineering.

Almost every piece of software is an evolving beast. Being able to 
integrate these transforms, and actually have upgrading not be painful 
in the long-term, is going to make a big difference in the way people 
code and in how people design."


-- 
Peter Fabian
AIM:fabianpetergabor
Sun Instant Messaging: pf120168 at sun.com
http://blogs.sun.com/fp