How can I make Java back-end development faster? Or can I?

Question

Hi,

I started web programming with raw PHP, gradually moving on to its various frameworks, then to Django and Rails. In every framework I've used, pretty much everything I need to do with a database (even involving relatively complex things like many-to-many relationships) could be taken care of by the automatically generated database API without much work. Those few operations that were more complex could be done with straight SQL or by tying together multiple API calls.

Now I'm starting to learn Java, and it's confusing me that the language celebrated for being so robust for back-end infrastructure requires so much more code (doesn't that mean harder to maintain?) to do simple things. Example from a tutorial: say you want to search by last name. You write the method in the DAO using Hibernate query language, then you write a method in the Service to call it (couldn't that be automated?), then you call the Service method from the controller. Whereas in any other framework I've worked with, you could call something to the effect of

Person.find_by_last_name(request.POST['last_name'])

Straight out of the controller - you don't have to write anything custom to do something like that.

Is there some kind of code generation I haven't found yet? Something in Eclipse? Just doesn't seem right to me that the language regraded as one of the best choices for complex back-ends is so much harder to work with. Is there something I'm missing?

Answer 1

I would suggest that you look at the Spring framework for Java.

I haven't personally used it, but I've heard good things about it. From what I understand it provides the same sort of functionality that you would get Django and Rails.

Answer 2

Get iBatis for Java. It isn't as robust as Django's ORM (nothing is), but it's a big, big step above JDBC.

Answer 3

Grails for the win. Groovy is very similar to Java but with a lot of nice dynamic language additions/simplifications. Grails has GORM, which is exactly what you're looking for.

Answer 4

In the example you mention, it looks like they are using more of a tiered architecture than you are used to.

Controller -> Service -> DAO

This provides for separation within the app. This is also completely dependent on the architecture of your application, not really Java as a language. Technically there is nothing in Java that would stop you from calling a Hibernate query in your controller. It just wouldn't constitute good design.

Another thing to consider is that the 'Service' could be something like an EJB, which may have the role of Transaction management, so that multiple calls to the DAO/Hibernate can be wrappered in a single transaction that will automatically commit or rollback on success / exception.

Again though, this is all in the architecture / framework that you are using, not Java as a language.

Answer 5

Well yeah, but it's not separation that's the concern for me. With these other database APIs, concerns are separated - it's not that custom DB logic is written in the controller (which I know is bad form) but that it's automatically generated. The call looks exactly the same from the controller, the difference is that with Java/Hibernate I had to write it myself and with Django/Rails/Symfony/Cake it was already there for me.

Grails looks very interesting. The main reason I'm learning Java, though, is because I want to at least be able to work with something I can use professionally. I'm not sure Grails fits that bill, though because it is Java perhaps the Enterprise will warm up to it moreso than Rails.

Django is the most beautiful piece of code I have ever worked with, but it's not trusted by the kind of businesses who can afford custom web apps, which is the market I think I want to be in.

iBATIS looks very promising - looking through the JPetStore code it appears it does a bit more automatically. But did all that SQL have to be hand-coded? Because then I'd be back where I started.

Spring has a great and reasonably easy to work with interface layer (MVC), and it ties components together pretty nicely. Though it can be used to integrate an ORM into an app, as far as I know it's not one.

Answer 6

Part of the the reason that you don't get automatically generated database APIs in Java is that as a compiled language without macros (like Lisp) it cannot do runtime code generation. Dynamically typed script languages like Ruby have that capability.

Another part of the reason is cultural: the J2EE world has tended to prefer configuration over convention for the last decade. The major reason for this preference is that enterprisey apps often have to work with lots of crufty assumptions that bring with it all sorts of "weird" edge cases. It is what it is. These assumptions stand in stark contrast to what the newer frameworks like Rails assume.

That said, I don't think there's anything to prevent a Java ORM API from generating database APIs at compile time. My guess is that Naked Objects is more up your alley.

Answer 7

I'd suggest you use Seam. It is a very good controller, that does not force you to have fully multitiered ap. It is fully integrated with JPA (Java Persistence Api) that does ORM.

Features

1. Has very nice scoping - you can have objects scoped to Session, pageload, conversation (conversation is an unit of work from user perispective).
2. Does not require much XML.
3. Does not require much boilerplate code!
4. Is easy to learn (you may even generate framework project from entity classes or db schema; it will still require much of work, but it will at least cut down boilerplate code)
5. Very nice security (you may either use role based security, or use rules framework)

When writing webpage you use beans (normal java objects).

You may write:

 #{PersonHome.instance.name}

which will evaluate to the value of name of a person. If in request parameter there was person id it will be passed to PersonHome component (if it was annotated properly), and person bean will be loaded transparently from the db.

And you may even write:

<h:commandLink action="#{PersonHome.delete(person}">

Where controllerBean is java bean, and delete takes person object. It will be transparently translated to link that will have person id parameter, that will transparently be translated to bean before action method will be fired.

The only caveat for now is that it somewhat limits your choice of view framework: it works only with RichFaces, GWT, and something else that I cant remember now ;).

PS.

Yes I'm a huge fan of seam :).

Answer 8

Just doesn't seem right to me that the language regraded as one of the best choices for complex back-ends is so much harder to work with. Is there something I'm missing?

The reason for this is the amount of time Java has been deployed in the Enterprise.

It's not that Java is more mature than, say, Ruby, it's just that Java has been used for longer and has been proven by risk averse IT departments.

One recommended way in is therefore via JRuby (+Rails), as that runs on the Java VM, and the IT department don't need to install or reconfigure anything...