• I want to as much Scala development as possible. I really like that language and it offers tons of inspirations while still allowing me to build on my Java experience.
• I want to learn a little Clojure. Just because I like making knots in my brain.
• I will do some web development. My skills in that area are a little rusty and I don’t need much of them in my current main project, but I sure don’t want to do Swing development for ever.
• And of course I will continue to read as much as possible about a wide range of topics.

I’m doing this because I actually think it is time to say good bye to Java. The development of Java stagnated in the past and I don’t see any sign that its new owner is going to change that. So I need an alternative. For me that’s Scala.

On the other hand I’m kind of confident, that the JVM will survive for quite some time in a state that makes it a strong, interesting platform.

Of course I’m no prophet. Maybe Google buys Java and within two years it is the coolest language on the planet … if so, some Scala experience won’t hurt, because a cool Java will certainly contain lots of features from Scala.

Maybe Scala dies or something bad happens to the JVM. In that case  the broad range of programming concepts will make it easy to switch to any language of interest. So I’m feeling confident that my future as a software developer stays safe and interesting.

If I’d stayed with Java as my main language I still would feel safe … but I’d be not so sure about the ‘interesting’ part.

Scale

In a late blog post Stephan Schmidt vents his problems with hibernate and declares “ORMs are a thing of the past”

I agree to some extend:
- The SQL generated by Hibernate by default is horrible. Huge joins, with hundreds of columns, many unneeded.
- Annotations feel like dirt in your code, and maintaining XML mappings is just painful.
- LazyInitializationExceptions are a pain in the a.. neck.

But does that justify the conclusion, that ORMs will go away in the near future? I don’t think so. Of course my perspective is biased, but in the applications I build I deal typically with 200-500 tables. Just typing the basic CRUD Statement, and wrapping them into usable objects is a pain, and a lot of work, which I gladly will hand over to an ORM.

Tracking changes in objects is another task, I gladly handover to an ORM.

Even writing annotations, while being far from perfect is better then most alternatives I know.

Implementing my own caching logic? No thanx. The ORM can do that pretty well.

I think the crucial point lies in Stephans last paragraph, where he sketches some ideas for alternatives. ORMs aren’t bad in themselves. They are just difficult to get right. Hibernate did a great job. It is the first one to get wide spread usage. And most points mentioned above are a weakness in Hibernate (or JPA) or possibly Java. So my claim is: ORMs aren’t dead, they aren’t even grown up.

So what properties might a grown up ORM have?

• Usage of persistence independent annotations: The problem with annotations is: they don’t belong in the business domain, where your classes live. They are part of the persistence layer, and should stay there. But when you look at the JPA annotations you’ll find a lot that is pretty usefull in GUI context as well. For example the length of a field isn’t only important for the database but for the GUI as well. Same for validations. So I’d think, in a couple years from now we’ll have annotations (or other language features), that let us specify features of properties and references, which truely live in the domain world. And the ORMs will just utilize that information for 90% of their needs
• When the references will have more information attached to them. E.g. if it is just a association, or an aggregation, or if the M in an 1:M relation is ‘big’. And ORMs will use that to optimize there SQL.
• The management of Sessions will move toward a declarative style, just as transactions did in the last decade.
• RDBMS vendors will finally realize the power of ORMs, and will provide more efficient protocols for the ORMs to communicate with.
• ORMs will monitor how they are used for a certain application, and will use that information to improve the SQL used.

But as so often, the most important change will be a people change: People will finally let databases drop into the background where they belong, and manage the schema through the ORM. I always wonder “Why?” when I hear people describe how the build a database first, and then map classes to the tables. That is the wrong way around: Build a strong domain model first. Let the ORM create a database schema for you from that. And then get someone with strong database knowledge involved to tweak it where necessary. This is when you start seriously gaining something for your struggle with the ORM. Most importantly: you get strong support for database refactorings.

If you want to read more about the whole ORM discussion, you might be interested in this article by Debasish Ghosh.