Category Archives: Java

Nerd Kerfuffle: Hudson to Move to Eclipse! What is Jenkins to Do?

Breaking: Oracle Plans to Transfer Hudson IP to Eclipse | Javalobby.

Hudson was (is) a great continuous integration platform-  super easy to install and use with lots of plugins.  Then, big bad Oracle claimed that while the source was open, the name was not and Oracle owned a trademark on Hudson.  The original author of Hudson, Kohsuke Kawaguchi, said, “Fine, I’m taking my ball and going home,” meaning that he forked the project, called it “Jenkins” and said to Oracle, “There, now the whole thing is open.”  This all happened quite recently, so Jenkins and Hudson are still nearly the same product.

Everyone on both sides seems to agree that the tensions started because of miscommunication, but that wasn’t the whole thing.  The issue was the trademark.  Oracle claims that they just needed more time to resolve an issue and didn’t want to exercise any unusual control over the open source project.

This is another example of why I think Oracle is going to kill Java.  Don’t get me wrong: they don’t want to kill it.  They simply don’t know how to manage it without killing it.  Never assign malevolence to that which can be explained by incompetence.

Maybe Java isn’t dead after all!

Maybe Java isn’t dead after all! Twitter Engineering: Twitter Search is Now 3x Faster http://ow.ly/4yCLc

Still talking about Spring Roo sucking

Back in June 2010, I wrote a provocative (apparently) post called Spring Roo Sucks! It was a bit of a rant, so I backed off on the tone, but I’m still defending the overall point.

Somebody commented that I had unfair expectations of this young project. I started to reply in the comments, but it got a little long-winded for a comment, so I’m putting it here.

Joseph wrote:

It’s a great project, your expectations are unreasonable because Spring roo doesn’t have release 2 or 3, but 1 … It’s a quite new project. And you expect it to be something that exist 4+ years and that has been extremely refactored in time…

If I was programming as a hobby, I might agree. But I need my tools to increase my productivity, no matter what revision.

There are plenty of smaller, less ambitious open source projects in version 0.9 that I have found to be extremely helpful. The issue is not the revision (Spring can bring a lot of resources to bear and they are working closely with Google on the GWT stuff). To me, the issue is with the scope. This tool builds a lot of my application, but it builds it exactly the way it wants to and with sensible defaults. But almost all interesting applications have something besides a CRUD view on a bunch of entities and as soon as you starting looking in the corners, you get lost. I don’t think it’s Roo’s fault exactly. It’s just the way code generation stuff works.

To me, there are similar issues with GUI drawing tools. Those are great and deliver a lot of productivity. Just lay out your screen the way you want it and presto! That works until you say, “actually, for these 5 fields, I only want to show each of them if the database says they should be visible and I want to adjust the size of the dialog accordingly, so I don’t have overflow and I don’t have a bunch of blank space.” So then you go look at all that code that got generated for you and you can pretty much understand most of it (or even all of it) but you start modifying that code to do more precisely what you want. So far, it’s still a productivity saver, but then someone says, “I want to change the theme” or “I want to add this button” and you say, “OK, that’s a few hours,” thinking you’ll impress them with your speed. Then they come back with “A day?!? How could it possibly take that long. You just open up the GUI builder and add the button!” But that doesn’t work anymore because the code isn’t code that the GUI builder understands anymore.

So, you’ve got code now that you basically understand even if it’s not structured as modularly as you would like, making future changes more expensive. You’ve also got some code that your mouse-jockey tool doesn’t recognize anymore, so you’re productivity boost from that was brief. However, I will concede that it was also substantial. You got a nice bootstrap to your project, so who’s complaining?

Not me, if it’s limited to the GUI – the outermost layer of your application on which nothing else is dependent. I don’t think it’s necessarily wise, though, to treat the foundation of your application (the domain model) and the glue (your controller layer or servlet layer or dialog layer or whatever you want to call it) the same way.

One other way Roo’s strategy is not as good a fit as GUI builders is that building a user interface is inherently visual and so is the tool. Moving stuff around to get it just so is what it’s all about. It’s a very visual exercise so a visual builder is just a good fit, even if you only get to use it for the first draft. Your domain model, however, doesn’t work quite that way. While you are building it at first, it is going to change several times as you realize this dependency would create a cycle or that field name doesn’t fit the naming convention that you really want or whatever. I find the Roo command line to be very unfriendly to this kind of refactoring work. That kind of work calls for an editor, not a command line.

As I’m writing this, I’m wondering to myself if you took the Roo command line away if I would like the tool better. You have to learn all the annotations, sure, but then you’ve learned them so you understand what you’re doing and how to change it. And you really would save yourself a ton of typing if you got good at it. So maybe in the near future I’ll come around on the annotations. We’ll see.

Share my pain!

Here’s a painful puzzle I ran into using Jersey 1.4 with Spring.

I have two kinds of entities in my system. (Well, more than that, but for this example, we’ll just look at two.) First is RoleImpl:

@Entity(name = "Role")
@Table(name = "Role")
@XmlRootElement(name = "role")
@XmlType(name = "role")
public class RoleImpl implements HasLongId, HasName, HasZone, Role {
...
}

Second is PartyEntity:

@Entity(name = "Party")
@XmlType(name = "party")
@XmlRootElement(name = "party")
public abstract class PartyEntity implements Party {
...
}

I have a resource for each and a @GET method that returns a List<RoleImpl> and a List<PartyEntity> respectively. When they produce JSON, the parties are rendered as an array like this:
[{"id":45,"name":"","firstName":"","lastName":""},{"id":48,"name":"Winston Abbott","firstName":"Winston","lastName":"Abbott"}]

This is the “correct” behavior as far as I’m concerned. However, the roles are rendered as an object with an array in the “role” field like this:
{"role":[{"id":"1","name":"superuser","permissions":"*"},{"id":"2","name":"admin","permissions":["*:*:ownZone"]}]}

After much fiddling around, I found the solution. See if you can tell me the functional difference between these two classes:

package com.factorlab.ws.security;

import java.util.HashSet;
import java.util.Set;

import javax.ws.rs.ext.Provider;
import javax.xml.bind.JAXBException;

import com.factorlab.security.RoleImpl;
import com.factorlab.security.UserEntity;
import com.factorlab.ws.AbstractJAXBContextResolver;

public class SecurityJAXBContextResolver extends AbstractJAXBContextResolver {

	public SecurityJAXBContextResolver() throws JAXBException {
		super();
	}

	@Override
	protected Set<Class> getTypes() {
		Set<Class> classSet = new HashSet<Class>();
		classSet.add(UserEntity.class);
		classSet.add(RoleImpl.class);
		return classSet;
	}

}

and

package com.factorlab.ws.security;

import java.util.HashSet;
import java.util.Set;

import javax.ws.rs.ext.Provider;
import javax.xml.bind.JAXBException;

import com.factorlab.security.PartyEntity;
import com.factorlab.security.PersonEntity;
import com.factorlab.ws.AbstractJAXBContextResolver;

@Provider
public class SecurityJAXBContextResolver extends AbstractJAXBContextResolver {

	public SecurityJAXBContextResolver() throws JAXBException {
		super();
	}

	@Override
	protected Set<Class> getTypes() {
		Set<Class> classSet = new HashSet<Class>();
		classSet.add(PartyEntity.class);
		classSet.add(PersonEntity.class);
		return classSet;
	}

}

The answer came to me after variously staring at the code and stepping through a bunch of Jersey code in my debugger for only about 5 hours. Of course, the actual solution, once known, was trivial to implement (and I do mean trivial).

Mouse over me for the answer

Now the question is: Why did it even work as well as it did. I leave that as an exercise for the reader (because I don’t have an answer). I’d love to hear theories in the comments.

The Web on OSGi

Just watched this very interesting presentation: The Web on OSGi: Here’s How. It’s something I’ve been thinking about a lot working on my new application – how to build a platform rather than an application. This was both informative and a bit scary (sounds like OSGi is full of pitfalls still).

Another Look at Roo

OK, so I attended the Roo session today at JavaOne.  I got frustrated with it before and I’m more cynical than I started out, but that Ben Alex is just so darned earnest you can’t help but root for the guy.  Not to mention that it’s worth rooting for the tool to be successful just to make my life easier.

I was pretty harsh on Roo before.  I conceded that it still had promise, but I was very disappointed in the experience past the initial euphoria that comes with such a rapid development.  The great thing about the tool (and others like it) is that it basically builds an application for you with very little effort.  The problem can be right after that.  So far in my experience, it happens without fail.

The application that it builds for you is not quite the application you want – just most of it.  That’s great, right? If it builds 80% of the application you only need to build the other 20%.  Unfortunately, it doesn’t quite work that way.  The 80% that’s built is full of stuff you don’t understand (because it was auto-generated). When I say hard to understand, I don’t just mean that the code is hard to read (it often is) or that it uses a bunch of techniques that are unfamiliar to mortal developers (that’s usually true, too).  It’s also that it is unclear how to extend it.

So Roo generates all this persistence stuff that I like, and I like the controller scaffolding, but not the jspx files.  Can I delete them? Will the tool complain? If the tool doesn’t complain, will something else complain when try to start the server and they aren’t there? What files are safe to edit, what files should not be touched and what files can be edited with care? What about all those AspectJ files? It doesn’t look like the autogenerated test does anything, but I can see that it’s running 9 tests. What is it doing, exactly? I dunno – can’t see the code.

If you can’t figure that stuff out, you’re stuck with 80% of an application that can’t be finished so you’re pretty close to 0% of the way to a finished application.

I left with more hope than when I entered.  I got some clarification on some of those questions in my session today.  It is also perfectly valid to use Roo to build 80% of your application and then remove Roo.  Now you can edit whatever you like – it’s just Java.  You can’t remove Roo automatically, but you can do it manually without too much effort.  Now I’ve got a huge leg up on building my application.

It’s too late for my current project, but my next project will get going soon and I’m going to give Roo another day in court (the GWT stuff still might not be ready for prime time).  It’s cheap to try.

Groovy: To Infinity and Beyond

Attended a JavaOne session on Groovy today.  I was looking for an intro to Groovy but it was really more aimed at experienced Groovy developers – what’s new with 1.7, what’s coming in 1.8, etc.

Groovy is pretty cool, but it also has some of the same problems as all dynamic languages have.  It looks to me as if the whole point of Groovy is brevity.  This has great potential benefits to both efficiency and clarity.  However, the benefit to clarity is based on eliminating boilerplate stuff from Java that doesn’t actually add any clarity – removing clutter.  There are a lot of things in Groovy (it seems to me) that are really an enemy of clarity.

e.g.

def divide = {a, b -> a/b }
def halver = divide.rcurry(2)
assert halver(8) == 4

Clearly.


def plus2 = { it + 2 }
def times3 = { it * 3 }
def composed1 = plus2 << times3
assert composed1(3) == 11
assert composed1(4) = plus2(time3(4))

The result of these asserts should be intuitively obvious to the most casual observer.

Java in the Cloud

The first breakout session I attended at the JavaOne conference (or Unconference for this part) was a discussion on cloud computing.  Now this was just an interest group, not a speaker-led presentation.  The idea is that in the group of interested people, some would have experience in the topic and could learn from others with experience while those with little or no experience could benefit from the discussion by listening in or asking questions of the “experts”.

Unfortunately, there wasn’t much expertise on hand.  It seems that no one is doing much Java in the cloud – at least not among the 30 or so people dedicated enough to show up on Sunday for the discussion.  So was it fruitful anyway? Yes, and here’s why.

First was a discussion of what it even means.  We didn’t arrive at a formal consensus, but as the discussion went on, it was clear that we meant something like Amazon EC2 more than we meant something like SaaS.  There was a lot of talk on “private clouds.”  I have no problem with the concept of private clouds, but I think you are really talking about elastic virtual computing in general, and not necessarily some nebulous resources without boundaries out in the world.  It turns out the distinction is important to most people.  It may not be important whether you call it a “cloud” or not, but it matters a lot to people where these virtual computing resources live.  Curiously, our discussion of what constituted a cloud aligned very well with Ellison’s.  (This discussion was before Ellison’s welcome keynote and his sales pitch for the Exalogic “cloud in a box”.)

The main fruit of this fruitful conversation, though, was a discussion of why no one seemed to be doing the thing that everyone was talking about.  The answer was data.  There are two issues with data – performance and security/privacy.

Performance

Several people suggested that their DBA’s would never put their databases on a VM at all, no matter where it lived.  These guys want total control over which piece of such-and-such table lives on which disk to tweak performance.  That’s nonsense if you have a VM with a virtual disk.  What’s the point of putting temporary tables on their own disk when all the drive space is shared anyway?

Personally, I suspect that this is an overblown concern.  Not all storage arrays are the same, but if you are using a high performance SAN, you are already abstracting away the disk.  A large SAN (with more than just a few disks) is not a viable solution for most non-shared infrastructure folks because it’s very expensive.  However for a shared infrastructure (including a virtual one) the case for a SAN is obvious.  It provides great I/O and everything is, in a way, already on it’s own disk, so there’s no point in segmenting your data that way.

So, I suspect DBA’s can get crusty and cling to what they know just like everybody else, and they are saying a VM would never work because they won’t be able to sleep at night without that total tweaking control.  I suspect that, but I’m not a DBA, so I have to admit that they know a lot more about it than I do.  I can suspect prejudice, but I am not really qualified to prove it.

The other issue is that I’ve used a shared SAN before.  It worked great for us in terms of I/O, but it was also supposed to provide super high availability because it was so massively redundant.  However, the particular shared infrastructure vendor I was using had multiple outages of several hours of the whole SAN.  Again, I suspect incompetence, but I’m not qualified to say whether it was incompetence or SAN’s are inherently unstable.  Another possibility is that it was incompetence of a kind, but that it’s so complicated that only super geniuses can implement them correctly.  That would be a weakness of SAN closely related to “inherently unstable” in my book.

Security/Privacy

The other main concern was handling of sensitive data.  There seemed to be some specific concerns about things like Social Security Numbers – that you couldn’t really store it in the cloud and be SOX compliant.  I can’t speak to that, but I don’t know why that concern would be different if you used a non-virtual database but had it provisioned by RackSpace or some other data-center service provider.

Tying it all Together

So the VM issue is an issue whether it’s public or private and the security issue is an issue whether its virtual or not.  Whether the objections are valid or paranoid, these are the perceptions people have.  Well, if you can’t put your data in the cloud, what’s the point?  There are very few interesting applications that don’t require a database.  There are some (performance lab is a clear use case, a marketing web site without much “application” there, some super-processing that is done periodic batches) but until you can confidently put your data in the cloud, of course you’re not going to see a lot of serious applications in the cloud.

But somehow Amazon and Google do it.  There are a couple of important things that make them special.  EC2 can be thought of as a public cloud, but it’s private to Amazon.  Amazon can put it’s sensitive data somewhere else and no one but Amazon employees can put their hands on it.  Amazon and Google both have tons of data that is not the least bit sensitive.  (What would it even mean to “steal” Google’s data?)  However, they aren’t using RDBMS’s for that stuff.  They are using various flavors of NoSQL.  That proves that it can work, but it’s useful to remind yourself: You’re not Google.

Must Reads for a Software Developer

JavaLobby has a post up regarding Must Reads for Software Developers.  Although the title doesn’t mention Java, it’s a pretty Java-laden list.  (It’s JavaLobby after all).  Just my two cents:

Refactoring (Martin Fowler) and Design Patterns (GoF) are interesting because many of the things talked about are so ubiquitous now as to be almost invisible.  The Observer Pattern? That’s just pretty much how events work these days (but not at the time it was written).  Rename a variable? That’s so easy and cheap in most IDE’s that you forget that there’s any trick to it at all.  That being said, I don’t think they are only interesting as historical documents.  Just the intro to Design Patterns changed my whole way of thinking about OO design.  And the Refactoring book still has plenty that isn’t implemented in some IDE’s as well as vital discussion of the principles proper motivations behind refactoring in the first place.

One that I would add to the list is Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin. If you want some deliberate practice to make you a better professional, you can’t go wrong with this book.

No Java required for any of those three (although I would say that Refactoring would be pretty different in dynamic languages like Javascript).

Spring Roo Rocks!

OK, that overstates it a bit for me, but consider it kind of a make-up call for my overstating my previous objections.  However, a couple things I think are awesome:

  • After posting about Roo sucking, Ben Alex, founder and lead for the Roo project himself, got back to me to address some of my concerns.
  • I thought there were some “not ready for prime-time” problems and some fundamental problems.  Ben, who is way smarter than me, took the time to explain how some of my “fundamental” problems had potential solutions.  Now, these things aren’t solved yet, but they’re on the roadmap and they’re not insurmountable as I first thought.

I am very impressed that the project lead cares enough about gripes from unknown developers out here that he took the time to respond personally.  That bumps the whole project up in my book.  It’s still not in a state where I can use it for myself, so maybe this post should be “Ben Alex Rocks!”, but it had exciting potential to really increase productivity before I tried to use and it has exciting potential again.  I’ll be watching carefully.