OnJava.com have an article by Bruce Tate looking into the future at technologies that may either replace or pave the way for upcoming new technologies that may replace the current ‘new Cobol’, which is Java.
Number one on the list and used throughout the article for examples, is, no surprise, Ruby, and the Ruby on Rails framework.
If this framework does not make it big in the next year or so then it will be interesting to look back to see what else changed as a direct result of the impact that RoR is making, because this technology is sure beginning to pick up some momentum.
News.com has an article about Ruby on Rails this morning, bringing RoR into the mainstream news, and possibly giving it the attention that I think it deserves in terms of simplifying web application development.
The article gives an overview of the deverloper, David Heinemeier Hansson, and a brief overview of what RoR is about. This should move RoR onto the radar of significantly more people, and may start up more interest in this relatively new framework.
There is a discussion on the JavaLobby site about an article written on the javadude.com site explaining how Java only uses ‘pass by value’, and never ‘pass by reference’.
I’ve know this for a long time and blogged about it here in my Java section with what I think is a clear explanation of the sematics of pass by value verses pass by reference.
The point is, although Java has references (everthing that is not a primitive is a reference), all parameters to methods are always passed by value. There is no pass by reference in java. The confusion is in the names being used here, because references are actually passed by value.
If you don’t understand this, look at how parameters are passed by reference in C, and write some code that swaps a parameter passed for another, and how it changes the value being pointed to by the orginal parameter before it was passed to the method. You cannot do this in Java. Java only passes by value.
This article on ‘Component Inheritance in EJB2.0’ on the java.net site attempts to give an explanation and make excuses for why the EJB2.0 spec is so fatally flawed. This is an interesting article because of the spin that the author takes – it almost sounds like he is making excuses for the flaws in the EJB2.0 spec and to justify why it is actually ok.
The author makes a statement that the reason why Entity Beans do not have inheritance is because they are misunderstood and are actually ‘componenents’ and not objects. Well a component can be different things to many people, but an Entity Bean as a component is a very fine grained component if you ask me. The author states that therefore it is ok that Entity Beans do not inheritance because a component does not represent state of an object.
This is nonsense. An EntityBean is intended to represent an Entity in a system. An Entity, as an Object, has State and Behavior. When I model my application, I identify types and subtypes and the relationships between these types and implement them as Classes. The reason why (one of the reasons why) EntityBeans are flawed is that I cannot implement EntiyBeans to represent the data model that I have jsut described – this type of data model is natural to implementing an Object Oriented system using an Object Oriented language such as Java. To have a persistence mechanism that does not support features which are core to the language I am using to implement my system is just nonsense. This is the main reason why the EntityBean part of the EJB2.x spec is flawed.
The POJO approach in Hibernate (and other ORM tools) is the correct approach in my opinion, and the reason why this approach has now been adopted for the EJB3.0 spec moving forward. Don’t make excuses for why EJB2.x is wrong; accept that it is wrong and move on – there are better solutions out there.