Is Java dying? Dependency injection and other Java necessary evils

My friend Jorge Manrubia have published a very interesting post about the necessary evils in Java

This post helps me to thing about this: Is Java as alanguage dying?

I agree with Jorge, a huge movement from Java to dynamic typing languages has started (including here in Spain), and this is normal as Java is a 15 years old language, the new languages are combining dynamic typing, metaprograming and another awesome features and (very important) the JVM/J2EE platform is executing these languages.

I also believe Java is not dead at all, the strong typing has its advantages and with hard work people have achieved some of the goals he is talking about.

Dependency injection is a language agnostic concept that was implemented first with a container (Spring has almost six years, Plexus or Avalon even more), then in a lighter way (Guice) and also without a container in Spring ROO, but yes, it's a natural feature via metaprogramming in Ruby and other languages.

I would like to test Spring Roo in a real environment, because it lets you do something that years ago I found impossible in Java platform, Domain Driven development that in the end translates the concepts to classes, I mean, real object oriented programming and no anemic classes and a lot of procedural artifacts (managers, daos,...) Spring Roo achieves this with a massive use of Aspect J (not java at all).

The question is, is it enough using this kind of tools in Java, or is better migrate to Ruby/Groovy/Scala? And I don't think is an easy question, maybe it depends on the developer profile and experience, but it's very important to know these tools do exist and there are patterns and practices that are global to all languages.

About Strong Typing, I would change the GWT examples by others. Not because I do like this technology, but because GWT is not really Java, it has the Java syntax but is a tool that compiles Java to JavaScript, and uses a series of tricks (like JSNI) to communicate the original Java (then Javascript) code with the native one. In this case, the GWT advantages have got a syntactic overhead when you want to use native Javascript (usually to do REST) in your code.

Actually GWT could be a good example of the advantages of strong typing. It would be awesome if the Google guys have built a tool that let you write Ruby, Groovy, Scala and compile it to JavaScript, but probably this is not possible without the Strong Typing stuff.

And about Object disorientation, I haven't nothing to say, when Java drives you to this type of non-oriented programing, it sucks!


Update [June 29, 2010] Thanks Tako for the grammatical corrections!

Presupuestando: User stories

Presupuestando (budgeting in Spanish) is the name of my little project. It's aim be a site in which a user can request a budget (for example, reparations in the customer house, car or maybe travels), and the companies can interact presenting its budgets to the user.

At the beginning of the project i have compelled (from my mind) the following user stories:

Customer stories

• A customer request for a budget in its own words
• There is only a filter of budget type (Travelling, Housekeeping...) 
• The user can add a new type but the Prespuestando admin have to approve it (and find vendors to do it), so in this case the interactions finish at this point.
• The customer can be an existing customer or a new one, but the form would be the same for the two types
• The customer can fill an expected range of money for the budget or not
• The customer's location is detected and shown in the form. The user can edit this location (or drop it), the customer also can restrict the budget request to vendors in a specified perimeter from this point.
• The customer is notified when a vendor applies for a budget,  at this moment can request a change in the budget, approve the budget or discard it.

Vendor stories

• A vendor is notified when a customer request for a budget in one of his areas of interest 
• A vendor is registered and assigned to one or more budget types, one of the vendor's data will be its location
• The registration of a vendor is approved by the site admin.
• A budget is described in general and in lines, in a flexible and UX based interface (this story will be detailed prior its development)
• A vendor can request intervention details to the customer
• Vendor can save a budget in database
• Vendor can send a budget to the customer or discard it
• Vendor can change a applied budget if customer request it.

Admin stories 

• An admin fills the types of budgets
• And admin approves the registration of a vendor

Additional notes:

• At this moment is not determined the channel selected to the communication vendor-customer. The easy solution would be the email, but a twitter solution will be studied
• The admin stories has a very low priority to the web application. The admin can introduce the types by hand in database and vendor approves can be automatically approves (and disabled via Database if case of problems)

Backend for my project, choosing a NoSQL database

One of the goals of this projects is to have the possibility to work with a NoSQL approach. There are a lot of NoSQL documentation in the Internet, so I only gonna do a brief comments about its philosofity and principes:

• It's not a clear definition about the features of a NoSQL database, there are a lot of tools with differents approaches (document or object oriented, big hashes, ACID and no ACID), 
• A NoSQL database can provide you a huge scalability and high performance. Twitter, Google, Facebook does need this, and your application. Well, about performance, why not?.
• Typically object-oriented applications are builded around the SQL databases, letting the business logic reside in the database and working as simple CRUD interfaces. This is not necessary bad, SQL has its optimizations, performance, specialized teams,... but NoSQL gives you more options to have in mind.

After a short investigation, and following recomendations, I decide to use MongoDB as my first approach to NoSQL databases. My first option was Cassandra, with has a lot of hype around because is used by Twitter and Facebook. Its main features are a descentralized approach, Cassandra is never designed to run as single node but in a bunch of them, and is not ACID compliant.

In the other hand, MongoDB is ACID compliant and is an document oriented database, you can use JSON to manipulate data, is scalable depending on your needs but valid in a single node. It also seems well documented and supported.

A would like to combine with some sort of business DSL (in my next post i'm gonna talk about business oriented development and DSLs) and test two things.

The first one, If my front-end is build in GWT, my business logic in the DSL and  I don't want to use traditional CRUD generation, does I really need Grails building plugins or It's better that i develop another command system around my DSL?

The second is as follows, in many projects there are a considerable amount of repetitive code to access to certain tables (master tables), to display combos, completers, sometimes i18n... Most of this times, this data has no associated business logic, only data retrieval from Database.

Well, if MongoDB can be queried using JSON, and my GWT Front-End understands JSON, is it viable access this tables directly from the front-end? Can this method be productive dropping the repetitive backend code? Would I be acting against layer encapsulation?

I'll let you know my conclusions, give me some time!

Front-end stack for the new project: GWT

I'm going to start the project talking about the technologies I want to use. Obviously this technological election isn't the result of a reasoned study to fix the architecture to both client and functional environment. There are no client, there are no functional study, (neither name for the project!).


Today I'm gonna talk about Front End Stack. I would like to implement the UX of the project using Google Web Toolkit, GWT, and GWT are going to comunicate the server side via REST calls to a Grais Backend.


The main difference of this election is that I already know GWT. I worked in a pretty serious GWT project for 9 months, also I'm the responsible of GWT workshops in my company, and, the most important part, I do like GWT!

One reason is that I think I'm the perfect user profile of this technology, I have a knowledge of front end techonologies such a HTML, JavaScript, CSS, but I'm far from be a good front-end programmer. I am not confortable writing jQuery (although I feel is a great technology), and with these capabilities, GWT fixed pretty well as Java tool to build Rich Client Interfaces.

As GWT is a Java tool based on a Java->HTML/Javascript compiler it main benefits are that you write the code in Java, with a strong typing, easy unit testing (i'm talking about UNIT testing), quite productive APIs (from Google, vendors and J2SE) optimization process, and component oriented programming model.

I also think GWT can be a perfect tool to embrace HTML5, using its Java-Component based encapsulation, you can easilly migrate the implementation of a component to a HTML5 one, or add new advanced components to your toolset.

But probably my favorite feature of GWT is not a feature. GWT is a tool, it's not a framework. There are a lot of frameworks in Java. Struts2, Wicket, Spring MVC, JSF,.. but you can view GWT as a tool to translate Java into Javascript. And from this tool you can build your infraestructure (your framework if you want), and this infraestructure can be quite productive.

In my nine months project with GWT, we only reach the surface of this capability using code generations tools and I have the feeling that there are not a lot people talking about building GWT tools. I would like to do some research on this field.

Another feature I wanna test is the REST integration. In our project we use GWT RPC API, with an excellent result. This API seems a bit unfashioned, its name reminds you college times, it's simillar to RMI (at least without RMIException), but it's very productive. With this API you can have tested and compiled calls, it's very simple to integrate the calls with Spring IoC container, and the problems with proxied objets can be avoided. I recommend this sollution:



But this calls are no REST-complain. In other environments you may require to do this REST calls, for example, in my project. I want to use Grails as rapid web development framework, because i also want to test it (I worked with Groovy to do some scripts a time ago), also the dynamic capabilities of the language to build something not far from business oriented language (but this is another post), and is tool and command oriented development style as a via to implement my own code-generation tools.

To do this the best option seems to be GWT Overlay types, and combine it with Model View Presenter (MVP) pattern. This pattern is also a pending task for me, In our project we use a quite rudimentary MVC that got us trouble when the project growed.


To finish the post, a great presentation on GWT, Grails, REST and MVP from Matt Raible.

Building SOFEA Applications with GWT and Grails

View more presentations from Matt Raible.

New project, old blog

Fortunately Google guys have a lot of disk space and my old blog hasn't been dropped yet!

I started this blog two years ago without a clear purpose to share some general thoughts, tricks, and to try to improve my writing level in English (typical Spanish!) and as many blogs, the blog was abandoned.

Today, I reopen the blog to write about a new personal project. What project? I'm not sure at this moment, but is for sure that the project exists.



The blog's name source, via Microsiervos

For the last years I've been having the pleasure to work in interesting projects, with state of art technologies, sometimes with the responsibility of evaluate and choose them as Software Architect. In my free time I have read several books, blogs, articles, workshops, worked in small conferences and thinks like that, important stuff but no "real" development work.

Nowadays the situation is different, I'm working in a static phase of an old project, most of the time in maintenance tasks and, although I think you can learn and become a better professional in all situations, I have the feeling that I must start something and evaluate new technologies and paradigms.

So this is the motivation of the new era of the blog, share the steps and thoughts of the new project, wish me luck!