Tag: java

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.

The problem with relying too heavily on one development toolset is that you become complacent and ignorant of other advances in the same problem space.

It has been argued that Java is the ‘new Cobol’. Everything around you is implemented in Java, therefore why should you consider any other alternative. The trouble is that you eventually stop seeing even the drawbacks and inherant problems with the tool, and carry on regardless.

Ruby, and in particular ‘Ruby on Rails’ has been getting a lot of press recently due to its ease of development, ease of use, and quick development times. The trouble when new technologies appear is that people tend to cast them aside as ‘not mature enough for primetime’.

The thing is, the Ruby on Rails (RoR) approach solves a lot of the complexity issues that are inherrent in the J2EE type development approach. What if this approach really is superior? What if I can realy develop an application in a tenth of the time I can with J2EE? What if a RoR solution is ready for implementing enterprise solutions?

Could it be possible that RoR or a similar technology could overtake Java and leave it in the dust? I think it’s time we started paying closer attention to other innovations out there, and either learn from them, or jump on the next train, because if the hype is real then Java could already be the next Cobol, and Java developers could be looking at the next 10 years of maintaining Java legacy systems.

This article gives an overview of Bruce Tate’s new book ‘Beyond Java’, which addresses these types of issues.

OnJava.com have a great article about where the web and webpages as we have known them up until this point are heading and how web technologies are evolving.

Web2.0 is not any one or a collection of technology standards, but rather an evolved (and evolving) way of thinking about how the web can be used to achieve goals. The changes are subtle but noticible. In most cases Web2.0 encompases how evolving web based technologies are being used to enhance the user experience on the web, with the trend towards collaboration, sharing and community driven sites and community interaction.

For example, mid-90s personal web sites were ‘the thing’ for self-promotion and telling the world about yourself, your hobbies and your cat. Mid-90s personal websites were typically static sites. Today, ‘the thing’ for publishing personal information is the weblog, or blog as it has come to be known. Blogs are now dynamic, growing and living sites, regularly updated with new information as the author updates it. The end goal is somewhat similar, but the use of the internet and web technologies to achieve it has evolved.

This section below is taken from the article “what it Web 2.0” on OnJava.com site:

Web 1.0  	   	Web 2.0
DoubleClick 	        --> 	Google AdSense
Ofoto 	                --> 	Flickr
Akamai 	                --> 	BitTorrent
mp3.com 	        --> 	Napster
Britannica Online 	--> 	Wikipedia
personal websites 	--> 	blogging
evite 	                --> 	upcoming.org and EVDB
domain name speculation --> 	search engine optimization
page views 	        --> 	cost per click
screen scraping         --> 	web services
publishing 	        --> 	participation
content management systems 	--> 	wikis
directories (taxonomy) 	--> 	tagging ("folksonomy")
stickiness 	        --> 	syndication

In most cases you see that the goal has remained the same, but the evolution of technology has allowed the goal to be achieved in a different way taking advantage of the new technology.

This is an excellent article and well worth a read.