Exploring “Fluid” Frontiers for J2EE Apps

California Java researchers are exploring how "rapid prototyping" and "un-refactoring" techniques could help J2EE devs better J2EE updates and integrations. This project, winner of an Eclipse Innovation Award, brings loosely-coupled techniques to tight-coupled J2EE silos - with astonishing results. Take a tour of the "Fluid Architecture" project with lead, William Griswold, Ph.D, professor at University of California - San Diego.

Tags: AspectJ, Feature, Developer, Legacy, Eclipse, Java, Refactoring,

by Vance McCarthy
An innovative group of researchers in California are exploring how Open Source Eclipse devs can more efficiently tie traditional J2EE or legacy application code in with new loosely-coupled assets or services.

Integration Developer News spoke with William Griswold, Ph.D and professor at University of California - San Diego about his Fluid Architecture project, which is trying to apply 'reverse refactoring' technique to Open Source tools.

This group pushing the envelope on how enterprise devs can use aspect-oriented programming plug-ins for Eclipse to simplify building workflow, adding new features and even transforming their "what-if' prototypes into 'go live' code.

An Integration Developer News Interview
with William Griswold, Ph.D and professor,
University of California - San Diego

IDN: This plug-in is in the realm of getting Java -to-AOP easier from within the framework?
Griswold: Yes, I think so.

IDN: How does your work fit into current state of refactoring?
Griswold: The enterprise EJB definition of 'refactoring' is not the particular focus of our work. Our meaning for 'refactoring' is aimed at crosscutting concerns, as well as ways to make it easier and more efficient to update legacy code. The work, also, I should add, is all directed at adding plug-ins to the Eclipse Framework for Java or AspectJ.

IDN: So, talk a bit more about your view of refactoring?
Griswold: Our premise is that increase effectiveness [of updating legacy code], developers are dealing with crosscutting concerns. There are two sides to the coin to "crosscutting" concerns. One is the AspectJ side of it. And that goes like this: 'I know what my concerns are, I haven't written the code for them yet, and I can program them in AspectJ and that will give me good separation of concerns, good maintenance properties, etc.' Also, if a developers wants to change how memory management or security policies work, that's also well-defined, so will be easy to do with AspectJ.

But, then there is the other side of crosscutting concerns, where things are quite so clear. In this second side of the coin, I have a large code base, in Java, not in AspectJ, and the concerns are not separated So, I have ideas of what I'd like to achieve, but I also have to deal with a legacy code base. To make things a little clearer and easier, I'd like to bring that legacy code base into line with the way I think about my concerns. Or, in other words, to make the code look more like the way I draw [my crosscutting concerns] on my chalkboard.

IDN: So, is this problem at all similar to the one enterprise devs are facing when the begin to look a loosely-coupled projects that need to work with legacy J2EE tightly-coupled applications?
Griswold: Yes it's very similar. So, let's talk about how you get from Point B to Point A, if you will. In other words, how I get back to a bette4r point because I'm stuck starting from the wrong place.

IDN: Fair enough. How do you begin to untangle your existing code to make it easier to work with moving forward?
Griswold: The short answer is that we would like to repurpose the existing code by cutting and pasting, then wrapping it into abstractions, pulling the tightly integrated code apart, and then re-integrating that code we need with better technologies -- like AspectJ, or plug-in tech of some kind.

IDN: Sounds reasonable, but how do you begin that process without breaking what you have?
Griswold: That's a very important element. The team leader or architect has this problem, but doesn't always have all the details available. You may have bugs, you may not know where all the code is or how it's spread out throughout your enterprise. He also doesn't know how hard it will be to separate these components without breaking the current application, let alone how easy or hard it will be to re-integrated these components, even if he finds them all.

IDN: Where's the help for that? Or is that what your projects are geared toward?
Griswold: The fact is they are not getting a lot of help. AspectJ is a last stop in connecting all the dots. But it's still challenging to get started. Our work is aimed toward these problems of getting started. What we've done is create 2 new visual tools -- Aspect Browser and Star Diagram.

Aspect Browser gives you a system-wide, visualization of your cross-cutting concerns. Aspect Browser is mostly a visualization and workflow tool, it walks you thru stuff and shows you when you change code how it affects your code. Very powerful, but it doesn't prevent you from breaking your code while you do this.

It can't do it fully automatically, but you have to tell it some things. First, you have to give it a pattern. For instance, "I'm looking for all the tokens with the word 'cache' in them. It will highlight those throughout the system. I'm not interested in ALL 'caching,' I just want the 'page caching'. Then you are looking at 'caching' your page and those become the hot spots for your crosscutting concerns.

IDN: Aren't there conventional tools or editors that can do that?
Griswold: What GREP does is it generates a file and an old style editor will highlight but only for one search at a time. Our project for Eclipse can mange multiple searches at a time, and you can selectively turn them on and off. Since we are trying to understand the workflow as well we implemented a visualization tool that uses a cartography or maps. So we implement mapping technologies that lets you zoom in and out, go next, previous one, very mature technology. Programmers already think of code specially - directories, over here, down there, etc. And we turn that into a visualization.

IDN: What's it look like?
Griswold: The Eclipse plug-in for AspectJ (AJDT). They borrowed some of our ideas, but we borrowed some of our idea from a much older tool called SeeSoft. So, to get an idea of how our tool works, let's talk about a package of classes. We put them in a row side by side, normally in alphabet order -- A classes at the beginning, and Z at the end of the row. Each class is represented as a long strip top to bottom. The row of pixels is highlighted with the cache color, or highlighted with the color for page then it has page in it.

IDN: That's how I get multiple results?
Griswold: Yes. And, we can do it for Fortran and C, code that needs more help than Java.

IDN: And, this caching example would be a typical way where Eclipse devs could benefit you're your project?
Griswold: The caching problem is classic, where you're doing a lot of client/server stuff and caching is a really big deal for performance. But caching is implemented inconsistently, or suboptimally, or you get bugs -- and even in places where caching should be implemented. Tracking down that would be a classic.

IDN: What about error handling?
Griswold: Yes, exception handling and error handling. Often, devs often just implement their own recoveries on the side. So, yes, our tool can start searching for errors all over your code so you can regularlize all your exception handling. You probably need to log all that stuff at some point, too, and it's hard to get a log unless you have some rationale for your error handling.

IDN: In your visualization, you help me visualize my problem?
Griswold: You can take the same visualization, and can walk through all the code, zoom in into the editor and start modifying code and pulling out code.

IDN: What about the Star tool?
Griswold: Eclipse does have a built-in set of refactorings, which are reasonably straight-forward. But current refactoring transformation [tools] have limitations. They can be difficult to use and take a long time to run, and only work for Java. So, on the whole today's refactoring tools can be good for little chunks of code, but they can't help you with bigger challenges such as finding some caching code here and then some more caching code over there, and then finding out these pieces of code are supposed to be the same but they're not, or they don't cooperate the way they should. So, those are the kinds of problems our tool is designed to solve. Think of it as helping developers put the dots together.

IDN: So, put that in terms of a real hands-on project?
Griswold: Our tool starts by giving the developer or the team a big picture for visualization. Then, we use workflow feature to walk a developer through [his code] and then apply Eclipse refactoring and maybe even some hand-done refactoring.

But, beyond Java, we see there are a lot of benefits in evolving Java to AspectJ, and our tool helps with that transition as well. The way [Java] code gets tightly integrated is that 'Component A' really has to call 'Component B', and that's because 'A' knows that 'B' has to happen NOW. So, let's say 'B' is caching those things that should be cached from 'A'; we'll call that the 'cacher'

What should really happen now is the 'cacher' should notice what should be cached from 'A' and say, 'Hey, I just noticed that should be cached, so I will cache it now.' But working that way would require 'B' to call 'A,' which is the reverse of what we have in our code today.

Our whole point is that the 'cacher' should know what should be cached, rather than having to make everything from 'A' know the cacher. Similarly, everything shouldn't have to know about how error recovery takes place, the error recovery component should take care of that.

IDN: That sounds pretty formidable?
Griswold: Let's take it a step further. So far, I've summarized the work from our first two [Eclipse] projects., The third is very different but on the same topic.

IDN: How does the third one work?
Griswold: Let's say I want to add a new feature to my legacy system, but I don't know if it will be worthwhile. I also don't know how hard it is going to be. So, this problem is like refactoring, but now we are talking about adding new features into legacy system. The code has to be written and then integrated. And that integration can be very costly, and I'd like to get a 'yes' or 'no' answer about whether it's worth adding this new feature -- without having to invest in the integration.

IDN: How do you enable the developer to do that?
Griswold: AspectJ lets me write this new feature as a aspect or a set of classes. Then I can use AspectJ's 'reverse calling' capability to say to the code while it's running, "Whenever this situation arises in the system, run my code." And example might be, when an object creates some caching, or where then is an exception, implement the system-wide error recovery.

So, using AspectJ, I can write my new feature as a block of code, and have the aspect point into the execution of the system and essentially integrate my feature without having to modify my legacy system.

IDN: Is that approach helpful to devs concerned about finding more efferent ways to make changes and updates in their Java or legacy code?
Griswold: Exactly, this has a similar flavor.

Here's the observation, I proposed using AspectJ for rapid prototyping. One of the features of rapid prototyping is you get the thing you really want for less time and money. But, you also may have things left out. AspectJ has powerful features in that it can actually do invasive weaving of your new code into your [legacy] code. This method can get access to private variables and methods. And, even when a disciplined architect would not allow that [approach] to stand in their enterprise system, you can conduct the project as simply 'prototyping.'

So, we're suggesting developers use the invasive weaving AspectJ features to 'hack in" new or proposed feature as a prototyping exercise. And, because this needs to be architected right, we're also suggesting developers write a very aggressive aspect that can insinuate itself into part of the [legacy] system. From there, the developer runs our tool that 'un-aspectizes' the code.

IDN: What's the result of that process?
Griswold: Wherever the AspectJ code is weaving itself in the compiler, it now actually copies the code in into the source code. Basically 'un-refactors' it and puts it into the code. Before AspectJ advises a private method, now the code has moved into the private method. That means the violation has gone away because the aspect code is gone. We have not used AspectJ as a programming language per se, but as a tool.

IDN: So do devs need to learn AspectJ, or is this abstracted?
Griswold: Abstracting this would be the 2nd generation of the work, whereby a developer could write fairly normal code and then separately write some other code that has mapping into AspectJ.

IDN: All tools companies talk about change management as brittle and expensive. Are you looking to help fix that?
Griswold: To keep pace with your competitors, you have to release new features that are robust. AspectJ and AspectWerks have fused. What makes that possible is that they are very complimentary. AspectJ is for the java programmer, and if you want to be working at the next level up you should be using other tools.

IDN Do you envision the tools as a suite, or separate, for Eclipse?
Griswold: The first two will be a suite. The other tools will be different. It's going to be a tool like Eclipse refactoring, a button that says inline aspect and boom it gets woven into the source code, and it won't have a visualization component, per se.

IDN Is this an Open Source plug-in?
Griswold: It will be freely available for research purposes, and depending on how things go it could go Open Source at some point. Mostly, we just like to get our tools out there, and see what results.