Autogenerating META-INF/services

​If you've ever tried to use SPI, you're familiar with the hassle of maintaining the meta files necessary for the system to work.  Especially early on when a system is under heavy flux, keeping everything in sync can be a frustrating, error-fraught experience.  Many just plow through it.  Others turn to automated solutions and here is where the trouble begins.​

If you're smart you look for a library and if you're lucky you find one that fits your needs.​  For one reason or another, some choose to write their own library.  I know I've written one.  Kohsuke of hudson fame has written one.  If i were to use one today, I'd probably end up using this one.  I don't see it on the home page, but I seem to remember Reinier Zwitserloot suggesting that lombok had one in the works.  There are probably a dozen more out if one cared to dig deep enough (I don't).  But it shouldn't be this way.

So we have a situation where using a built-in feature to the java runtime is so awkward that we have all these competing, divergent solutions.  It's time for the JDK team to provide a native apt plugin to handle this natively.  Any feature that drives so many to build work arounds for it clearly is missing something.  In my opinion, this should be done by the JDK team and included in Java 8 at the latest.  If it takes filing a JSR to get it into Java 8, great.  I'd even lead​ ​it if necessary.  Build an amalgam of the solutions out.  Bundle an existing implement.  Build one from scratch.  Anything.  But please, give us something native so we can stop inventing the wheel over and over again.

To take it even a step further, I'd push for building a type database by default when building a jar.  Fantom has very nice way to tell the system, "Give me everything of type X."  This kind of "database" would be trivial to build during either the compilation or jar bundling phase.  But to be able to ask the JVM, give me references to all the classes implementing the interface FooBar​ would be an amazingly useful facility to have.  It would eliminate the need for jar/classpath scanning at start up for everything from simple plugin systems to full blown EE stacks.

So what do you think?  Is it too late for something like this in Java 8?  Or Java 7 update mumblemuble?  It'd be an amazing addition.

Meet Sofia

I've just released a pet project of mine on to maven central (provided the sync succeeds...) called sofia.  I won't go into too much detail here since there's a readme on the project page but I did want to share a few "meta" details about the whys and the wherefores.  As I mention in the readme, glassfish/grizzly use something similar and I found myself missing it in various different projects.  I also have other, larger projects I'm trying to get into a releasable state and this smaller project served as a nice dry run for those others.  It's small enough to manage and niche enough, probably, that I can get away with some churn as I figure out the maven release stuff.  

Which leads me to some meta-meta-details. The new(ish) policy for maven central publishing requires that you own the domain name for the coordinates you want to publish under.  For some large groups (apache.org, oracle.com, etc.) this makes a certain sense.  But for your average "garage" developer who just has a github repo and a great idea, requiring a registered domain name just creates a large burden on the part of developers/projects.  Finding a good project name is hard enough.  Finding a good project name that can be converted in to an available .com/.net/.org/.whatever can be unbelievably frustrating.  I find this policy to be incredibly short-sighted and, dare I say, lazy on the part of the managers of maven central.  Yes it avoids groupId conflicts and the need for arbitration should some domain owner come along.  But I'm not sure it's worth the headaches up front of finding available domain names before publishing artifacts.  Oh, well.  Done is done.

Please give sofia a spin and let me know what you think.  Fork it, patch it, file pull requests/issues.

Kindle Fire: First Impressions

My Fire finally arrived last night. Although I've been anxiously awaiting this day for a while now, I think my girls were even more excited during the unboxing than I was. The new machine is beautiful. I'll just say that right out of the gate. The screen is bright and the colors are sharp. The home screen is laid out fairly well. It's vaguely reminiscent of how I remember some screenshots of Apple's book reader software. (I've never used that so I could be way off.) The touch screen seems to be slightly less responsive than my Droid X. My droid will react to errant brushes of the screen where it seems like the Fire needs a slightly more intentional, insistent touch. This isn't entirely bad but takes a little getting used to.

As expected, Amazon's shopping services are tightly integrated. Anything you want from Amazon is just a few taps away. The apps I've bought for my android phone are there under "my apps" on the kindle, too, ready for download. I haven't done a full audit, but it would seem I can redownload any/all of them. I've already done so for a number of them but I can't guarantee 100% coverage on that front.

There is, however, one glaring failure on Amazon's part here. And, to be honest, I'm actively considering returning the Fire because of it. I knew that the Fire would be tightly integrated with Amazon's services. It was actually a mild selling point for me. I knew that Google's Android Marketplace would not be on the machine. That's a mild bummer but I'm sure that'll be rectified sooner or later. But what I find completely unacceptable is this: if I open the browser and go to market.android.com, it actually launches Amazon's app store. I understand they'd rather people buy apps from their store, but they have no right to intercept legitimate web traffic and reroute to their own sites. I should be free to browse whatever I want on the web without interference.

If Amazon doesn't fix this, I'm seriously considering returning this and paying the extra money for the Samsung Galaxy Tab 7.0 Plus.  I'll take a slightly less integrated experience if it means I'm free to read whatever web pages I want.  I don't need or want someone to hold my hand or dictate to me what I can or can not read on my devices.  If nothing else, I'll root this thing first chance I get and run stock Android on it.

So please, Amazon, fix this.  This goes well beyond allowing only your app store.  Even apple doesn't block websites on the ipad.  You have no right to either.