Friday, June 27, 2008

Notes from Eclipse Day at Googleplex

Before I go into any details, I want to say that the Google t-shirt that I got for attending was almost worth the airfare, hotel stay and car rental. Man am I a cheap date or what? Also I would be remiss if I didn't thank Robert Konigsberg and the rest of the Google Open Source Office for organizing the event.

It was great to meet Ian Skerrett, Bjorn Freeman-Benson
, and others that I have only had opportunity to communicate with over blogs or mailing lists. It was also nice to catch up with Chris Aniszczyk and Wes Isberg there as well. Of course while this is all nice and dandy, lets get to the actual event.

Eclipse @ eBay: Michael Galpin
Mr. Michael Galpin did what amounted to the "keynote" address of the event. He went into a brief history of eBay and the technologies used to develop the site and then went into some of the work that has been done at eBay with Eclipse. Before I continue, I should mention that I worked as a contractor for eBay for a little over a year and that I have a better perspective than most on what is going on there. eBay is HUGE into Eclipse, in fact, I wonder if there are many organizations more committed to using Eclipse and working on creating developer tools using Eclipse. Still I found the presentation on what eBay is doing with V4 in the presentation layer quite eye opening. I was working on an Eclipse plugin to support their internal SOA framework, so I was a bit segregated from V4 work. Now I kinda wish I wasn't so segregated, some of it is quite cool. I mean I know I always wanted to leverage Dervlets, but Spyglass is pretty cool. There is a nice PDF of the presentation notes available at this link. One thing to note is how Java centric eBay really is, just about everything is a Java class. I wish I had asked during my time there why the decision was made to do that, particularly the tradeoffs. One other thing, I wish my plugin work and the SOA framework had garnered a bullet in that presentation somewhere, oh well. I mean Wes Isberg's simple, but cool, Auto-configuration plugin got a mention. Not that I am jealous or anything. ;)

One final note, Mr. Galpin literally said that there are plans to open source all the tools shown during that presentation. People should hold them to that promise.

How Mylyn Changes the Way I Develop: Bjorn Freeman-Benson
After the eBay session, the event bifurcated into two parallel tracks. The net effect was that you needed to choose which event to attend. While I have an abstract interest in CDT at the current moment, I was more intrigued by the session on Mylyn. I mean I have tried to use it and I see the arguments for something like that. What I haven't done is well, get it. I have tried it and never managed to successfully integrate it into my workflows. I have gotten to know and respect Mr. Freeman-Benson while interacting with him over at the Eclipse Dash project, so I was hopeful he might allow me to 'get it' or at least motivate me to try again.

Before I get into the notes I have from the presentation I need to pass off some advice. This goes to Bjorn or anyone else giving a presentation, don't ever give a presentation that someone else prepared, period. I know it was probably due to the fact that Bjorn was stepping in for someone else, but yikes.

In the beginning Bjorn covered the motivation for Mylyn, things that I think everyone will admit that modern software engineers have to deal with even with a nice IDE like Eclipse. The problems are the need to context switch, to mulitask and to manage information overload. He did not go into the traditional ways that developers in Eclipse try to manage this, but it bears mentioning. Eclipse users usually use multiple workspaces, multiple workbench instances and try to make use of things like project/team sets. None of the traditional ways are satisfactory. So what is Mylyn's approach? First off, I love this, Mylyn allows you to keep all your stuff in just one workspace. Mylyn's focus is on cutting down the full workspace to only those elements that you need at a given time.

So how does Mylyn accomplish some of this? Well in Mylyn the notion of a task is made a first class citizen. Before you do anything in Eclipse using Mylyn, you need to do it in the context of a task. Mylyn has stuff to manage tasks and to integrate with common issue tracking packages like Bugzilla and JIRA, among others. Mylyn also allows you to be able to acquire your tasks from multiple sources. So once you have a task, Mylyn stores contextual information about what elements in the workspace you associate with a given task. This is where some of the black magic kicks in, Mylyn has a Degree of Interest Model that it maintains in order to know what to filter out of your views. This has always been the rub for me to start with Mylyn, everything is hidden at first and you must start from a task.

The cool thing though is that once a context is created, it is possible to share that easily with other team members. Now the cool thing for me is that the context is not shared via a team provider, but that Mylyn will create an attachment in the issue tracker that another team member can use automatically in their Eclipse workbench using Mylyn. I love that since it is logically associated with the task and that they did not punt the trouble to the team provider.

Another cool item, in fact, a killer app type item for those who like Agile software development methodologies, is the automatic time tracker. When you are using Eclipse with Mylyn, you are always with in the context of a task, so when you are doing stuff in the IDE then, Mylyn will keep a timer. This is a killer app, since anyone who does agile knows that the most difficult thing to do is to estimate the time to implement a given feature. In fact, it is so difficult that XP for instance tells you to use 'yesterday's weather', in other words, look at the last time you had to implement a given feature, and use that time. Well that only works if you accurately track your time on task. Mylyn could make this seamless and easy. This feature alone makes me want to use Mylyn, even if I leave the filtering off all the time.

I want to make one more comment about the presentation on Mylyn concerning workspace provisioning. Bjorn went into alot of Q&A with the audience and did cover more details of Mylyn. Still, what struck me about the presentation was how close Mylyn is to a full workspace provisioning solution. I need to look at Eclipse Buckminster and check out Genuitech's Pulse product again. Workspace provisioning for me is almost as big a deal as P2 and the Eclipse provisioning effort. I mean how long does it take for new people to be able to install Eclipse and get all they need to be able to check out the code from SCM and start working with it? I mean really, how long, do you even know?

Building Great RIA with ATF: Philippe Ombredanne
First off, I want to say I got the chance to meet Philippe at this event and I really like him. Second, is there any Eclipse project that he hasn't been intimately involved with? I think the list of projects at Eclipse he has been involved with would rival some of my earliest Christmas wish lists to Santa, I mean wow! Most of the presentation (at least the part that I was able to grok) covered the ATF project's live Javascript debugger. I am not an AJAX developer, so I admit much of what he showed was a bit lost on me, but even I admit the fact that you could monitor requests easily. He demonstrated how a click in the ATF embedded browser to Google Maps would show up as request response pairs in a nice viewer inside Eclipse. Makes me want to try and do some Web mashups (me even!). The other thing that struck me was the fact that they took the Mozilla Firefox XUL Runner build and embedded it as a bundle inside of Eclipse. I thought that was cool, since it provides an embedded browser to play with that is not the Eclipse default browser and I wonder what kind of API I could potentially play with. You know I am thinking a Groovy/Eclipse Monkey script to try it out. Awww yeah!

Wiring Hacker Synapses: Collaborative Coding and Team Tooling in Eclipse: Scott Lewis & Mustafa K. Isik
First off I want to say that I love what this demo and plugin could entail. Being able to do shared sessions on the same document is the first step towards better collaboration and hopefully better software development in general. If you haven't seen the video, go Google for Cola and ECF and check it out. The simple demo that Mustafa did there was in the most part better than attending this presentation. I wish he had done some more demo instead of theory. Still this is a good first step. The problem comes later. With shared sessions, how do you integrate properly with Team providers and make sure that the workspaces are provisioned correctly? I think that they should focus on allowing a remote Eclipse user to "shadow" the workspace of a local Eclipse user. This way you have a "master" workspace that the local user is responsible for provisioning and the responsibility is removed from the remote user. Still ECF is very cool, I wish them the best of luck.

Concluding Remarks
At the end of the sessions, there was free food and adult beverages for all. I ran one of the two demo stations there. In hindsight, I think that expecting people to really have any more brainpower to devote to Eclipse after five continuous hours of sessions was a bit much. Still I really want to thank those that came over and gave me the chance to show off Groovy Monkey and discuss my plans for Eclipse Monkey.

Once again thanks to Google and to the folks at the Eclipse foundation for showing up. Thanks to all the participants who attended. The event was, for the most part, packed, not the smaller affairs that Eclipse Democamps that I have attended in the past have been.

Monday, June 23, 2008

Don't call it a static or dynamic language!

I was talking the other day with someone recruiting me for a position. Smart organizations will contact you with someone who can try and sift the wheat from the chaff. In other words, they'll ask you questions in particular computer science or even, *gasp*, Java questions. Well this one guy asked me a standard question, 'what are the advantages and disadvantages of statically typed versus dynamically typed languages?' Now the full debate on that question could not only fill a whole series of blog entries, but could be a book by itself, which I will not get into here. Still as I was giving my answer I prefaced my comments by saying something that I have put a fair bit of thought into, which was: 'I don't like the name static or dynamic typing, I prefer the notion of implicitly typed and explicitly typed languages.'

First off let me start with the definitions of explicit and implicit, both of these are horked from Merriam Webster Online. Implicit is defined as "capable of being understood from something else though unexpressed : implied or involved in the nature or essence of something though not revealed, expressed, or developed." Explicit would be defined as "fully revealed or expressed without vagueness, implication, or ambiguity : leaving no question as to meaning or intent" or as "fully developed or formulated ." I think a good way to think about this is to consider the following question, "are details hidden from you or not?"

WTF (What The Friendly) does this have to do with Programming Languages?
I think if you consider it for a while, the language debate between statically and dynamically typed is clearer when it is considered in terms of whether it emphasizes implicitness or explicitness. First off, all languages and programming platforms are implicit to some degree, since there is no way to encapsulate all of the factors that go into programming a software system to a developer. If they did, the resulting interface to the developer would probably be enough to make an airline pilot's jaw drop. Still the point applies if you focus on types. Most of the debate about programming languages focuses on the issues of types, so it is a good area to concern ourselves with. By my reckoning, a strongly/statically typed language, like Java for instance, would be considered 'explicitly typed' in this nomenclature. A dynamically/weakly typed language, like Python or Ruby for instance, would be called an 'implicitly typed' language from now on. An optionally typed language like Groovy would be optionally explicit or optionally implicit, depending on the developers mood that day. ;)

Actually in my opinion, most of the interest in Groovy is due to its 'implicit' capabilities and therefore I would really put in that category. I know you can explicitly type things in Groovy, but that is really an enabling feature. Enabling feature, you say? Yeah, an enabling feature, kinda like (Note: I have no personal experience with the following analogy, really...) how a drug dealer might give out free samples to hook you in and then afterwords start charging. So being able to specify types in Groovy gives Java developers, like myself, a warm fuzzy about trying out the new features and, therefore, try out the Groovy language.

Ok this is awfully pedantic, so what?
So the question that might be formulating in your mind is, "ok so you have a new definition, how does this help anything?" Well for one thing, no matter what you do with software code, the types are there, period. The difference is if they are hidden or not. In the next few sections I am going to compare equivalent sections of code in Java and in Groovy, but I think that the point holds if we were in Ruby, Smalltalk or Python, even though the examples would vary.

I want to show a quick example from groovy and Java, in this I am going to create an instance of ArrayList:

List<> list = new ArrayList<>();

def list = []

So let me ask you a question? What is the difference in this case? Well for one the amount of actual keystrokes to write the examples. Beyond that, there is not much difference, in both cases you have a variable declaration of list that is initialized with a java.util.ArrayList instance. So what is the advantage of the Java version? Well Java's explicitness is key here, you know straight away that list is of type java.util.List and that it is an instance of java.util.ArrayList. Therefore, someone new to the Java platform would probably have an easier time figuring out what is going on in the Java line(at least not including generics, which is another post entirely) than with the Groovy line. To understand the groovy line you need to know that the array notation is shorthand for instantiating a List object and that by default an ArrayList is used, therefore I would term Groovy an "implicit" language in this case.

One other not so small point, if I was looking at this from a tool developer's viewpoint, I prefer the Java version to the Groovy version, in probably just about every case. In general, it is easier to write tools to analyze and provide support to base Java (or other explicitly typed language) than it is to any implicitly (read: dynamic) typed language.

Another example, I am going to do the simple "HelloWorld" application in both Groovy and Java:

public class HelloWorld
public static void main( String[] args )
System.out.println( "Hello World!" );

Groovy: HelloWorld.groovy
println "Hello World!"

This is the example that should drive the point home. What is the difference? In the end the bytecode will be functionally the same in both the Groovy and Java cases (Notice I don't say that the bytecode would be exactly the same). The big difference is that the Java version is explicit, not only about types, but also in requiring a class definition and explicit main method. In Groovy, the type is inferred implicitly from the file name and the main method is also implied.

What about the tools man?
The final example I want to consider is the Domain Specific Language (DSL) in the two kinds of languages. Actually, I lied, I am only going to show an example of a builder in Groovy and skip showing the example in Java, because the example for Java would be far too painful to consider. I want to consider the following example because I want to get to the point about what 'explicit' versus 'implicit' means for tool developers.

Example: AntBuilder (Groovy)
// Going to zip up a file
def ant = new AntBuilder() destfile:"${zip.location}", basedir:"${project.location}" )

What all is going on here? You have an instance of AntBuilder being created and a method called zip being invoked. There is an example of named parameters, which is a very cool feature for Groovy I think. Finally, you see there two GStrings (Groovy Strings, quite the name no?) with its built in templating. There is a lot going on here, someone wanting to write a tool would probably take a deep breath, but envision that he/she will be able to do it. The trick is what about the zip method. What about the zip method? Lets get to that next.

In the previous examples, the types and their signatures are just below the surface so to speak. The notation '[]' is a shorthand for java.util.List and in the case where the statements are just put into the Groovy file without a class definition, means there is an implicit class definition and static main method. In the above example, there is no such nicety. Why would I say that? I mean the variable ant is an instance of AntBuilder right? Yes, but look at the javadoc for AntBuilder, where is the method definition for zip? There is not one, but if you want to see for yourself go ahead and look, I'll wait.

The AntBuilder class is an example of a Builder in Groovy which does something like what java.lang.reflect.Proxy does. Proxy provides an InvocationHandler, which has a method called invoke() which the Java platform provides as a hook to allow you to provide runtime implementations of arbitrary types. The Groovy Builder support allows for creation of nodes and invocation of methods on those nodes. All of this means that not only is the full type definition for AntBuilder implicit, but that there is really no way at compile time to figure it out. What I mean is that there is no way for a source code tool developer to write general tools to provide the kind of language support that is available in explicitly typed languages for DSLs. In the first two examples, you could easily imagine being able to provide tooling support for those cases, the types and signatures were implicit, but they could be figured out relatively simply, there is no real way to do it in the last case.

Tooling support is an area that is usually skipped in alot of discussions on explicitly typed versus implicitly typed languages. It is dismissed by implicit proponents with, "well tooling will just catch up." I don't consider it trivial and, having dabbled a bit in providing IDE support for Groovy, I don't assume that the tooling will just be there in the future. Implicitly typed language designers and proponents need to give this its full consideration, elsewise the best your language could hope for is to be the next Lisp, praised by some and used by none.

So the difference between the two languages in the above examples is best exemplified by asking three questions. First, which version do you think someone new to your codebase or the Java platform would understand better? Usually an explicitly typed language like Java (or maybe Scala/Haskell) would be favored. Second, which version do you think someone with experience with your codebase or the Java platform would prefer to write? Usually, I would think that an implicit language like Groovy, Ruby or even Python would be preferred. Third, what kind of tool, particularly IDE support do you want or need? If your project thinks that the first question is more important than the second one, then an explicit language like Java should be your choice. If the second question seems more important, then an implicit language like Groovy should be your choice. The third question can only be answered by surveying what is available and trying it out to see if it is good enough.

Thursday, June 19, 2008

JRuby on Rails good or bad for Java?

I am going to apologize for the incendiary title. I think the work the JRuby team has been doing at Sun, particularly with enhancing the JVM for dynamic languages, is great and a service to the entire Java community. The real point of this post is a question to Sun and the rest of the Java community. What is the question? Simple. Y'all why all the emphasis on JRuby and JRuby on Rails and not an equivalent amount of love (read: attention/resources) to the Groovy/Grails platform? I am combining consideration of both Ruby and Groovy with their equivalent Web frameworks RoR and Grails since they really are the killer apps (read: primary motivation for developers to try them) for both languages at this time.

So why all the attention at Sun to JRuby? Well I think there is probably a mentality at Sun to think they need to win more people over to the Java platform. That thinking leads them to wanting to support Ruby and Ruby on Rails on the Java platform. This is not the end of the world or necessarily bad thinking. Why? Well you would think the more developers on the Java platform the "mo' better" right? I admit that being a Groovy/Grails proponent, the attention leaves me a bit jealous, but as I said earlier, they have been doing good work and, you know, envy gets you nowhere. Still it begs the question, what about the people who are already on the Java platform doing their work? What is being done to improve their experience and to keep them happy working with the Java platform?

Note: I keep referring to the Java platform since Java really encompasses three components, the JVM runtime, the platform libraries and the Java language. I think of the platform as the libraries and the JVM, in other words, the full Java runtime minus the development time Java language support.

Give Groovy Some More Love Everyone!
Groovy/Grails is native to the Java ecosystem and should be (read: is) easier to support on the Java platform. Groovy/Grails has a far flatter (read: easier) learning curve for existing Java developers. How do I know that it is an easier learning curve? Simple, Groovy is the single reason I have not really tried to do development work in Ruby or another dynamic language. Every time I started to drift off the reservation, for one reason or another, I found that Groovy had it already. So why give up the JVM or platform libraries of which I am very familiar? Grails, the Groovy Web Framework, is still a relatively young technology, but is already showing signs of being one of the, if not the, best Java web frameworks out there. It is amazing how Grails is picking up speed right now. <sarcasm>Its like people want a better way to do Java Web applications and, get this, don't seem to be willing to dump all their previous experience with Java or their previous Java work in the trash. Isn't that just crazy??</sarcasm>

So therefore, I think Groovy/Grails is something that should be better supported, particularly with tooling. A better Groovy/Grails would help keep developers on the Java platform, how? Well remember there does not exist a Groovy/Grails platform outside the JVM and Java platform libraries.

Besides the fact that Groovy/Grails support should be far easier to achieve than Ruby/RoR support, there is the converse argument about JRuby and JRuby on Rails (JRoR?) bringing people to the Java platform. JRuby on Rails could also be viewed as a conduit for allowing development to leave the Java platform as well. Why? Well all new work could feasibly be run on native Ruby platforms if run on JRuby and, in fact, would probably run better on native Ruby platforms than inside the JVM. So unless you have lots of legacy with J2EE, there would be no hook to staying with the JVM or Java platform. Now I hate vendor lock-in, but Java has no vendor to speak of. I am all for allowing existing Ruby/RoR developers to try the Java world, but the question is where should your emphasis lie? I don't think that the Ruby world is anywhere near the size of the Java world, even on the Web.

So, in conclusion, the question is, is it more important to convert others to the Java platform or is it more important to keep and take care of the large Java developer base on the Java platform? My answer is yes. What do I mean? Well you can't just grow a community, you must also take care of what is already there, both aspects are important to a thriving community.

So please Sun, get past the NIH (Not Invented Here) syndrome and go hire a Groovy guy next to Mr. Nutter (no complaints for Mr. Nutter, he has been doing good stuff on the JVM for all dynamic languages). While you are at it, I am going to suggest (even though I am an Eclipse guy) putting better support in Netbeans for Groovy. I am getting a little tired of hearing how IntelliJ is by far the best environment for writing Groovy. I would also suggest improving the Eclipse plugin, but I don't think y'all will go for that(would you?). Any help to Groovy would be in your interests, you wont regret it.

For the rest of the Java community (especially the Groovy/Grails subset), I think I am going to start sounding like Public Broadcasting in the United States during sweeps. If you don't know what I talking about, they are officially called "Pledge Drives", unofficially they are called "Beg For Money Drives." So here goes in my PBS pledge drive voice**:

"Please pledge your support to Groovy Eclipse today. At the 1+ full-time developer level we'll get you an Eclipse mug and sticker. Show your Eclipse pride everywhere you drive or compute, your choice. At the 2+ full-time position level, in addition to the mug and sticker, we'll get a Groovy Eclipse shirt made up for you from somewhere. You know you have been enjoying Groovy/Grails for some time now and been looking for your opportunity to contribute, here is your opportunity. You wont regret it, I promise*."

Seriously, the Java developer world today is on Eclipse (not IntelliJ or Netbeans or whatever), so for Groovy/Grails to grow and be taken seriously by the vast majority of Java developers, Groovy Eclipse has to be first class. Like I overheard once while talking about this subject to a group of people, "People will change languages faster than they will change their IDE(s), so for me to introduce Groovy to my Java developers, I need it on Eclipse."

* If you do regret it anyway, just remember two things. First, I thank you for your support. Two, you may rant and rave at me, but limit it to emails, no 2am crank calls, please. :)

** I think I watched way way too much PBS as a child or something, but where else could I watch Dr. Who before the Sci-Fi network existed??

Monday, June 16, 2008

Versioning: My Happy Place

There has been alot of discussion about the JSR-277 and OSGi versioning standards. I wont revisit the arguments here since people far more intelligent than me have lots to say on that matter. If you want to dive in, go ahead and Google it, and I will talk to you later since you will have forgotten to go back to this blog entry once you are done. For the rest of you, I have to beg your indulgence, I am going to assume that I actually have the qualifications to pontificate on this matter. So here goes.

Defining Versioning
Why do you want to version something? There are alot of reasons for it, particularly when it comes to Source Control Management (SCM) or Version Control. You need to know the version of a particular class that you are working on in that case. Using version control when you are working on software is an idea that goes without saying. There are no debates on versioning or the formats of those versions, you get the one that comes with the SCM you are using, period end of story. No, the issue comes up when you are considering versioning a component, which for OSGi/Eclipse is a bundle and for JSR 277 is called a module. So what does a version stand for in this case?

I like the wikipedia definition of a version in this case. It is pretty generic, but it goes something like this, "Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software." The definition tries to cover all cases, so the point to focus in on is the unique identifier of the unique state of the software. So what kind of state are we trying uniquely identify? Well changes to the software you as a developer have made of course, but I think that they fall into two categories at least at the component level. One category are those changes that affect dependency management because the external API on which clients rely has been altered. The second category, I will term bookkeeping for this blog entry. I term it bookkeeping, because it denotes internal changes that should, notice I say should, not affect clients using the external API. "Bookkeeping" comes into play because Software developers are human, and even though a change should not impact clients adversely, they still do. "Bookkeeping" lets a system integrator/admin note that a version of the component X worked, but X+1 sure did not, which is exactly the information someone providing support wants to hear. It is really difficult to say one category matters more than the other. Changes in the first category will prevent a system from coming up correctly, whereas changes in the second category could help explain why the system later goes haywire.

I like to view a version as a shortcut, so that a client does not have to check the full external API at runtime to know if there are changes that it should concern itself with. In fact, ideally the "external API" version should be some sort of "hash", if you will, of the external API that could be automatically maintained. More on the ideal answer later. The "bookkeeping" component is in effect like a branch in version control, it lets the developer go back and retrieve the previous version when problems come in from the users.

I could go on about how many coordinates are needed for this or that or what have you, but there are many many people far more qualified to comment on this and, you know what? They have commented, so if you are interested, go Google for them and check them out. What I am going to do is describe what in my ideal world versioning would do for me.

Versioning: James Ervin's Happy Place
I am not a big Adam Sandler fan, but I am a guy, so I will say that in the movie "Happy Gillmore", I was moved by Happy's idea of his "Happy Place." So what I am going to describe is my "Happy Place" for Software Versioning, though I will say that the "Happy Place" described in the movie is far superior to the one I will go into.

First off, any versioning scheme on the component level has to take into account that all software changes fall into one of the two orthogonal categories that I defined above, they are either external API or, for lack of a better word, internal "bookkeeping" changes. Any tooling support should be able to distinguish.

Secondly, I would like the notion of backward compatibility to go away. You change the external API, you create incompatibilities period. Incompatibilities between versions are a two way street. I mean if you make so called "backward compatible changes", then you shouldn't break existing clients, well that's great right? The problem with this view is that it assumes that your new stuff will be automagically available everywhere, which really does not take a full lifecycle view of your component into account. What you do is allow for a set of clients to be written that will be unable to use your pre-existing components. I don't have a great answer for this, but I would like people to take a greater view into account, all external API changes could force incompatibilities, not just ones that break backward compatibility. Once external API is defined, you need to treat it like set cement. How to potentially better deal with set cement? I try and deal with it in the next point.

Thirdly, I would like better API tooling support. This comes from point two, I want better tooling to help with what is in effect an intractable problem. First I would like to mention I know about the new Eclipse API tooling push and I want to investigate it thoroughly later on. I think it is worth mentioning that I view tooling support here in two categories again, what I would call "static support" and "client feedback support".

Static Support analysis in my view is what the Eclipse API tooling effort is focused on. Give me warnings if I add things to the external API to change the "external API" component of the version and then provide an automatic way to update it. Give me an error/warning to update the "external API" component of the version if I change an existing method or other backward compatible breaking change. Tell me to update the "bookkeeping" component of the version when I make any significant changes to the component that does not impact the external API. In other words, give me some help to make it more automatic. I, as a human being, have and will continue to forget to update versions without warning/errors markers to guide my way.

Before I go into the second category, I want to emphasize again that this is my happy place, my ideal world. "Client Feedback" tools to me are a potential answer to the problem of external API being set concrete after released in the wild. The trouble is that most of the time a whole API is not in use, usually only a subset, but what subset? That information would be invaluable. It would allow a component developer to know what parts of the API could be eliminated or given better documentation so that more clients would use it. "Client Feedback" would provide the targets for refactoring and could prevent the kind of cruft that eventually dooms any software product. How do you best get this feedback? Some sort of tooling support of course and beyond that I dunno. Did I mention this was my "Happy Place"?

So what do I want in a versioning scheme or tooling support? Prevent me from making simple obvious mistakes that I have done again and again. I want support to make me take into account that when a component is released, people write clients to use it and I have to keep them in mind for any changes, period. I think what I really want is the Staples Easy Button, which if you know me, is a metaphor for an impossible to build tool. Still there is alot that can be done before we need an 'Easy Button' to make this problem less problematic.

Notes from Eclipse Democamp in Dallas, Texas

I am late writing this blog since the democamp actually occurred last monday and it is now a week later. I know my memory is a bit faulty, but I wanted to jot a few notes on things that stood out to me.

* Pulse is a cool tool that I really need to take the chance to learn and leverage. I think its ability to generate profiles is a killer app for a Eclipse developer like myself, since I need to switch between versions of Eclipse often. The stuff about being able to provision a workspace should be of great use on my next project. I mean talking to Mr.Williams about the feature convinces me that it is what you want Eclipse Teamsets and exported settings to be.

* You know you should really hold a democamp in a place that has an internet connection. I mean BJ's Brewhouse is a fine enough choice, but no wireless? I wonder how long it will be that any restaurant that has a meeting room will put in wireless internet, it is really starting to become necessary. Todd Williams from Genuitec had a devil of a time demoing what appears to be a really cool product, Pulse. The trouble is that Pulse is based on the Eclipse P2 provisioning platform, which is meant to attend to the Update Manager's legion of flaws. So without an internet connection, there aint alot to demo is there? I think Chris Aniszczyk must have thought of this since the Austin Democamp will be held at Nokia's offices near Stubb's BBQ. Btw, nice choice Chris, Stubb's is an Austin landmark. I would have chosen to do Chuy's or the Hula Hut somehow, but hey, Stubb's is pretty damn cool too.

* I need to come up with a set of cool example scripts so that people get why a monkey scripting tool is so cool. This is a problem of my own making, I see the advantage, particularly coming from the Eclipse plugin development side of the fence, but there aren't that many Eclipse plugin developers. Any help in this arena would be most appreciated. I don't want to see the blank stares again when I goto Eclipse Day at the Googleplex or do the Austin Democamp later on this month.

Wednesday, June 11, 2008

Beware GStrings and their IDE support!

Despite the lascivious implications of the title, this blog entry has a G rating, as in Groovy!! You know, before I continue, I would like to apologize to y'all out there. I realize that punnery is considered, in the eyes of many, to be the lowest form of humor. But you know, why oh why was the name GString chosen and permitted to persist? Even though I am a strong Groovy proponent (some accuse me of being a fanboy), I can't stop the little 12 year old pubescent child in me from snickering every time I read about Groovy 'GString(s)'.

I want to preface my comments by saying that I love Groovy Strings (aka. GString(s)). I love the multiline strings, I love the ability to create regular expressions without slashing yourself all up, I really love the templating or string interpolation that allows arbitrary groovy expressions to be embedded in a string expression and I even love the fact that the GString is lazily evaluated. So why the title? I will get to that next. Before I continue, for you nit-pickers out there, I know that a GString is strictly only a string expression that is double quoted and contains an unescaped dollar sign, so I suppose I should have titled the blog entry as 'Beware Groovy String Support from within IDE(s)!', but really what fun is that?

As I started using Groovy and learned about its support for strings, I grew to love single quoted strings. Single quoted strings are the closest thing to Java string literals, they are immutable and are never evaluated to GString(s). They appeal to my need for simplicity. The problem comes later, as I write code, especially Unit Testing code, when all of a sudden I want to use a GString.

What is the problem? Why don't I just switch the single quotes to a double quote and voila! You ever try it? I don't know if IntelliJ's allegedly miraculous Groovy support does the same thing, but my baby, the Groovy Eclipse plugin sure does annoy me on this one. I suppose I could do a find and replace, but often my first instinct is to use the cursor keys and use that backspace button baby! And when I do that I run smack dab into a little feature that wants to autocomplete the double quotes, you know take " and change it to "". That is fine, but my first instinct is to hit backspace to remove the second and unnecessary double quote, which causes both of the double quotes to vanish, not what I want! So usually I stop, mutter an obscenity under my breath to myself, move my cursor in-between the two double quotes and hit the delete button, which I almost never use except in this one case.

Maybe this is more of a commentary on my coding style and how I interact with the IDE, but it has forced me to reconsider how I use strings in Groovy. From now on, I will try and avoid single quotes like the plague and use them only in cases where they are explicitly called for. In other words, I will no longer use the '' (single quoted) strings in groovy by default and instead use "" (double quoted) strings.

You know there is one other reason for this switch. I have had on occasion the need to convert my Groovy code to Java code and, other than the missing semicolons, fixing single quoted strings to be double quoted is second most laborious/annoying/mind-numbing step I have had to take.

So it is double quoted strings from now on for this boy.

Sunday, June 08, 2008

Using Groovy for Unit Tests inside Eclipse

I have blogged before in the past about using Groovy to write Eclipse Plugins. In fact, I think I am the only person in the world to ever write about the subject ever. This lack of interest in the subject is unfortunate for many reasons, but one reason in particular is the fact that writing in Groovy as opposed to Java can make many plugin related tasks simpler, particularly a lot of the tasks that make writing plugins no fun. For this specific reason, I am considering giving giving Groovy EMF a hard look as part of my ongoing efforts to make sense out of the Eclipse EMF Project. In my opinion, EMF could be like Grails if the generated code were in Groovy instead of Java.

Still I wanted to focus the blog entry on the use of Groovy for Unit Tests inside of Eclipse. This is because, in my opinion, that writing Unit Tests in Groovy is one of the main entry points for a Java developer to get their feet wet with Groovy and to see its benefits (the other two cases, in my opinion once again, are XML document parsing/generation and scripting). So here goes.

Framing the problem
The trouble with using Groovy in your projects is the same for using it for Unit Tests as when using it in production code from within Eclipse. The problem is that you usually have a build process that is run from the command line, often referred to as headless mode that you use for continuous integration or releases, and then you have the incremental build process that runs from within Eclipse. For headless (or batch/command line) builds, there is support from Groovy to assist with this, first there is the groovyc command that is equivalent to javac and second there is the Groovyc Ant Task. To take advantage of Eclipse incremental builds you really need to have an Eclipse plugin supporting that for you. This is where Groovy Eclipse can really be helpful, it provides the needed plugin support for incremental builds for Groovy from within Eclipse. For the next sections we will focus on solutions for utilizing Groovy for Unit tests.

Solution 1: GroovyTestSuite
There is a short snippet on using GroovyTestSuite from within Eclipse. There is one strong advantage to this method, since the groovy code is compiled when the AllTests are run, ostensibly this method could be used in both the headless batch build and from within Eclipse without any changes. So why not just use this method? Well there are downsides:

1. You can't use Eclipse's nice 'Recreate Test Suite' operation to keep the AllTests suite in sync. Over time, this is one of those problems that will bite more than once and usually when you least expect it.
2. If you don't have unit test classes compiled to classfiles, it makes running individual test cases difficult. This is something you feel more when you are trying to get a particularly challenging testcase to pass, in addition to the added compilation time, you will have to run the suite again. Of course you could create a new JUnit Testsuite just for the testcase you are trying to run, but then don't forget to delete it when done and don't check it into your source repository.
3. You have to make an assumption as to the current working directory. If you notice in the example code for GroovyTestSuite you have to assume that the unit test runner is being run from the project source directory. This is fine for Eclipse, just remember to check if that assumption holds for your batch/headless build as well.
4. You have to make assumptions as to the testcase's package. Once again refer to the code example for GroovyTestSuite. In the example see that the source directory, the package path is hardcoded, and the groovy file name is hardcoded. This is fine as long as you never change the source directory or refactor your test code into other groovy files or java packages, (*sarcasm alert*) which will never happen right? Now admittedly if you run your unit tests early and often, you will see this and then you will go and fix them immediately. Still better to not have to make those assumptions right?
5. Be careful about making Groovy code dependent on Java code or vice versa from within the same Eclipse Java project. This is a problem shared with the second approach as well. It is something you must consider (I know that groovyc will now compile Java code as well and it should be evaluated for use from within Groovy Eclipse or from your external build processes). There are a couple of ways to deal with the issue as I currently understand it. First, if you write only Groovy or Java code in a test project, there is no problem. This is usually an ok solution for greenfield test writing, but will not hold long term. Secondly, since there are no generated classfiles from groovy code in your project, you cannot allow your Java code to rely on any groovy code in the same test project period.

Solution 2: Groovy Eclipse Plugin
There is another option from within Eclipse, install the Groovy Eclipse Plugin and then add the Groovy builder and nature to your JUnit test project. Why do this? Well Groovy Eclipse will compile your Groovy code to classfiles and place them in a class folder for Eclipse so that Eclipse sees the compiled code as just another set of compiled Java code. This means that GroovyTestSuite is unnecessary and that running tests will not incur the full costs of compilation at start time, a significant advantage for developers. Another advantage is that the unit tests are compiled, so it is possible to easily run one testcase at a time. If setup correctly, using the Groovy Eclipse plugin makes developing/using Unit Tests in Groovy as seamless and invisible as possible. "So", you may ask, "ok Groovy Eclipse fan boy, what are the tradeoffs?" First off, even though I am a Groovy Eclipse committer and supporter, I am very well aware of its shortcomings, so I am not a fan boy. Secondly, well here are the tradeoffs/issues with this approach.

1. You must include Groovy as part of your batch/headless build process to compile the Groovy Unit Tests first, before the Unit tests are run. This is the same trouble you have if you are using Groovy in your production code. I will refer you to the section above titled 'Framing the Problem', for approaches on dealing with this. Using GroovyTestSuite only requires access to the groovy libraries at runtime.
2. Be careful about making Groovy code dependent on Java code or vice versa from within the same Eclipse Java project. This is not a problem unique to Groovy Eclipse or to writing Unit Tests with Groovy, but it is something you must consider (I know that groovyc will now compile Java code as well and it should be evaluated for use from within Groovy Eclipse). There are a couple of ways to deal with the issue as I currently understand it. First, if you write only Groovy or Java code in a test project, there is no problem. This is usually an ok solution for greenfield test writing, but will not hold long term. Secondly, be careful and avoid the following circumstances, A.groovy depends on which depends on C.groovy or depends on B.groovy which depends on This is an issue that needs to be addressed in Groovy Eclipse generally, either by leveraging groovyc to compile Java code or do an analysis to provide an Error/Warning marker to the user about the above circumstances. A useful heuristic traditionally is to allow groovy code to depend on java code or java code to depend on groovy code but not vice versa in the same project. If you hold to that heuristic, just consider the issue raised by number 3.
3. The order of the builders in the .project file. First off if you have groovy code depending on java code or vice versa in the same project, make sure that the groovy builder is before or after the java builder in the .project file. This can be easily checked by right clicking the project and then bringing up the properties dialog. Just look for the Builders section, you can easily remove, add, or reorder the builders in your .project file. Secondly, there are other occasions to be careful about the build order. In particular, this one bit me yesterday when I was trying to write a couple of unit tests for Eclipse monkey in groovy. I was pulling my hair out and about to give up on groovy unit tests for monkey (I mentioned I am not a Groovy Eclipse fanboy didn't I?), when I remembered to check the builder order. Sure enough, the groovy builder came after the plugin and manifest builders. Reordering the groovy builder to come before the PDE builders then allowed the PDE JUnit to actually run (Note to self: add better PDE support for Groovy Eclipse).

There are advantages and disadvantages to both approaches to writing Unit Tests for your projects from within Eclipse. The first approach, at first, seems more straightforward and simple, in particular no integration with external builds, compilation of groovy code is reduced to a classpath resolution problem. The second approach, using Groovy Eclipse, leaves the developer with the need to integrate Groovy into their external build processes, but in the longer term provides a more seamless and productive experience. So if you are wanting to write Unit Tests in groovy, give Groovy Eclipse a try!