Sunday, August 20, 2006

The Heavyweight Champions are... Springframework and Hibernate?

There are a lot of argumentations exist trying to proof whether a combination of Springframework and Hibernate is still a "lightweight" or already a "heavyweight" champion. Please see following discussions in TSS for some of arguments:

My conclusions after working with Springframework and Hibernate in some of my projects are: yes, Springframework and Hibernate are already our heavyweight champions! Why?

  1. It's getting on my nerves as I have to create SpringBeans by editing those Spring XML files. This is the same with Hibernate hbml files. I know there are some tools available (e. g. Spring and Hibernate plugins) to help me finish these annoying works. But still... at the end this is just the same as working with EJB 2.x with those deployment descriptors. You might say, I can use annotations. The problem is I still have to deploy in JDK 1.4.x. So annotations just won't work. I also know that Springframework 2.0 uses XML schema so the XML files are easier and shorter to create, but again, I hate creating XML files by hand and you?

  2. Special for Springframework XML files and this is often the case: you need one XML file for remote client context, one XML file for local client context and one XML file for test? Gee, how many XML files should I write or copy and paste plus edit?

  3. Hibernate should protect us from the database behind it. Is this true? Until a certain level yes, but if you try to work with Oracle and at the same time with MySQL you will still need to understand the differences between those databases! Do you know that Oracle always saves "" (empty string) as a null value? And this is not the case with MySQL! So welcome back to the relational database!

  4. Do you know how many methods do we have in Hibernate just to persist or create a new object? What are these methods actually for: save, saveOrUpdate, persist, merge? Man, in SQL we just have one command: insert! Do we really need those different kind of methods just for a simple thing? Why can't we just say "save" and everything will be taken care by Hibernate?

  5. I think you already heard a lot about architecture discussion to DTO or not. If not you can check out some interesting discussion in Springframework forum: Transfer Objects. You also can find the same discussion in TSS: Protecting the Domain Model. So, what's the hell why we use POJO if we still have to use DTO? You don't need to use DTO at all - many of us would loudly say, but what if we need to physically separate the tiers? In this case you will meet the most hated exception in Hibernate: Lazy Loading error if you are not carefully design your POJO! So sometimes we need DTO and sometimes not?

  6. If you are by fall putting something wrong in the XML files - both Springframework and Hibernate - (not syntactically because your schema will help you in this case) and you get some errors because of these things. Good luck and have fun trying to find them!

So what are your options?

  1. Accept those points above and be sure to know them best. Why not? You think, the combination of Springframework and Hibernate is still easier to use than EJB 2.x? More flexible than EJB 3.x? Yes, you are right. So, better to have a bad solution than no solution at all. Wow, you are what I call a pragmatic Java programmer.

  2. Use AndroMDAwith the Springframework and Hibernate cartridges. Oh my, I don't want to have something to do with MDA and UML. But what are the advantages of AndroMDA? No need to create those damn XML files - both for Springframework and Hibernate - by hand. You have a standard architecture which will be strongly followed by everyone in your team (if you have one) all the time. Nothing like sometimes with DTO, sometimes without DTO. But still you need to implement those DTOs! Yes, but at least you have the skeletons created for you.

  3. Build your own Dependency Injection and your OR mapper framework which are far better than Springframework plus Hibernate and don't forget at the end you should put them as Open Source products and release them through TSS news :-) So we all can admire your new products: oooh a new very easy framework but also it can support any complex situations (= all you can eat framework - and yes, Springframework is probably getting in this direction too. Of course you don't need to use everything but... we have that, we have this, ... You know what I mean).

It seems that using the option number 2 you will get back those "lightweight" Springframework with Hibernate (no XML files - they will be generated and we always use the same architecture everywhere)? It could be. With the price of using UML? Is this still "lightweight" or we just move our weight somewhere else? At the moment I prefer to use the option number 2 as I feel that I have lot more advantages in comparison of using the option number 1 or 3. But this should not be a general case and should be proven case by case!

Allright, at the end I admit that there are actually no "heavyweight" or "lightweight" frameworks, everything are relative to what exist and to what you know. In any case just take one of your options above and try to solve the problems you need to solve for your customers.

Happy coding and greets,

The most interesting discussion in year 2005 I've followed and joined sofar about MDA and the future of Java is this one at Beyond Java. More than 760 threads... with many interesting and great ideas...

Thursday, August 17, 2006

Happy Anniversary Indonesia!
p.f. 17 August 2006 - 61 years

FYI: Java island is located in Indonesia... so if you want to learn Java language you need to know Indonesian language first :-)

This should be your first exercise...

Selamat Ulang Tahun Kemerdekaan Indonesia yang ke 61! Semoga selalu panjang umur! Untuk membaca pidato Presiden RI, silahkan untuk melihat artikel ini di KOMPAS: Pidato Presiden 17 Agustus 2006.
Jorn Bettin has written this comment on the "Standardisation of Model Driven Approach":

Also, beyond the realm of MDA, in relation to model driven approaches and the use of domain-specific languages in general, there is the question of when and to what degree will standardisation occur. Usually the more domain-specific a language can be made, the more value it adds. Yet, the closer a domain-specific language gets to capturing part of the competitive edge of an organisation, the less incentive for industry wide "standardisation".

From my point of view standardisation will only happen if we could get a direct positive impact from it. So, this is actually very pragmatic. A very good example is the use of AndroMDA. I could imagine that there are a lot of organisations out there - which are all the user of AndroMDA - which have standardised their "DSL" based on AndroMDA DSL elements like Entity, Service, tagged values, etc. Why? Because you get directly benefits from it. You can generate your codes easily when you use AndroMDA DSL.

So, just a specification will not help to standardise anything (or at least it will take very long = OMG). I always take the example of JCP (Java Community Process). You need 3 components to be able to standardise APIs:
- Specification
- Reference Implementation
- Test Compatibility Kit

... and this is not the case with OMG. No reference implementation, no test compatibility kit. IMO, Open Source project like AndroMDA could bring the standardisation a step further. Just like succesful Open Source projects Hibernate, Spring, Struts, etc. which are de-facto standard and not de-jure standard.