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.