I think I’m one of the few people that likes Mercurial better than Git particularly for close-source projects.

Git = better branching, Hg = better merging

Git has easier to understand and more unified branching. However I think Mercurial merges better. I don’t have actual evidence but Mercurial rarely seems to screw up a merge and it seems to almost always do the right thing (hg resolve —all). Because of various rebasing or some other incorrect workflow I have had serious issues in the past merging with git. This is important to me because branching is not scary… merging is. And even scarier is rebasing.. more on that.

Hg = better for closesource, Git = better for opensource

I think Mercurial just works better for companies because rebasing + fast forwarding are something that are just not available OTB with Mercurial. Even with Hg’s various rebase extensions history editing is generally eschewed by Mercurial. So while this leaves less workflow options it means your junior developers is far less likely to completely screw up the master branch. Also other than making multiple heads its really hard to screw things up in Mercurial but when I first started using git I routinely screwed things up (mostly my fault because I sort of mixed workflows).

I also royally hate the staging area for companies because I have seen developers routinely forget to checkin files. You get the… “it works for me”…

That being said I think Git is superior for opensource projects because of its staging area, unified branching, generally more widespread understanding and far more mature subrepository support. Also with Git you don’t have to push all branches. So you can have a lone private feature branch. For companies I don’t see this is as good thing.

However my biggest problem with Git is that every time I seem to have to do something I have to google how to do it. I also seriously wonder if Git would be as popular as it is if it weren’t for the fact it was initially designed/developed by Linus Torvalds. Git is good today but it was pretty horrible to use compared to Hg years ago.

A boring release of bug fixes.

One notable feature added is the ability to do SELECT FOR UPDATE and SELECT FOR SHARE.

For fun a made a rather useful aspect for checking not null using JSR305 annotations. The weaving will only happen if you use a @CheckForNull on the top of the class or on a particular method. Then you can decide if you want to default that values can always be @Nonnull with @ParametersAreNonnullByDefault

If your concerned with performance later on you can remove the @CheckForNull and manually add Guava’s checkNotNulls.

I should note that I have sort taking my own interpretation of @CheckForNull. FindBugs may vomit and not like it. There is probably a better annotation to use so please comment for a better recommendation.

Here is the aspect in all its glory make sure you name it ending in “.aj”: Above is an example bean that will be validated.

Above is the maven depenency you will need for the JSR305 annotations its also a transitive dependency of Guava.

MyBatis SqlBuilder is one of the few SQL builders that allows you to generate pretty Pre-Processed SQL. That is SQL that has place holders. 

Now MyBatis SqlBuilder is sort of a joke in that it uses ThreadLocal… seriously ThreadLocal for an extremely simple DSL.  I would expect that from something like Hibernate but a tiny one class DSL. In fact when I first saw it I decided I would probably never use/need it because things like JOOQ and QueryDSL exist.

However I recently implemented my own Immutable ORM and need some simple SQL for Spring JDBC.

Consequently I ported MyBatis SqlBuilder to JATL style. In other words the better way to do this is to use Anonymous classes and/or Fluent style.

My Gist Here: The above Gist might not show because Tumblr sucks. https://gist.github.com/3650165

I have created a few classes that make appendable better: https://gist.github.com/3101471. Namely “BetterAppendable” which is an appendable decorator that will soften the IOException, handle nulls, and do collection joins.

I created BetterAppendable because Guava’s Joiner is rather limiting and Commons StrBuilder is to specific and is not threadsafe. 

An example of its usage:

Java has lots of ways of creating, encoding, and building strings. Most libraries are written so that they only accept java.lang.String when they should accept either Appendable or CharSequence. I’m tired of needing so many libraries to escape XML/HTML or encode a URL or just build a string especially since so many of them are not Appendable based. 

Consequently if people are interested I might make the classes into a project on Github and add various escaping options (like correct XML element and attribute escaping  as there is a difference). Of course if your really interested in creating proper XML/HTML strings look at JATL.

You have probably seen or read that URL’s are a subset of URI’s. In theory they are but in practice I have found that not to be the case. 

See my recent Stackoverflow Post on this. URL’s in the wild allow for characters in the Excluded US-ASCII Charset. URI’s do not!

I believe this is most likely because URL’s came before URI. User agents and web frameworks remain backward compatible with old URL’s so be wary of this.

Modern URL’s should be a subset of URI’s. So when constructing a URL its always best to use URI escaping rules when constructing a URL.