We Keep Coding

How Spring and Hibernate with JPA enabled enterprise applications can be helpful to the business?

I was asked this question in an interview. My answer was as follows.
Spring makes Java/J2EE development easier, more efficient and more productive. Hibernate helps to get rid of complex and tedious data access code and reap the benefits of object oriented principles.
By blending spring with hibernate we can create scalable, robust, maintainable and database independent enterprise applications at lightning speed thus reduce time to market.
I am not satisfied with my answer as interviewer was expecting answer in business perspective and my answer was far away and has technical details.

Some of the key points I'd say is cost (it's open source, which means no licensing fees), speed of application development (turnaround time from getting an idea to having a deliverable is much shorter compared to other frameworks), portability (you can move the application to any server and it will more likely than not just work out of the box), flexibility (making changes to business logic is quick and easy), maintainability (java has been around for a long time and probably will be around for much longer, finding developers to work on the project in the future won't be that difficult as it is when using legacy code), stability (since the architecture is build upon a stable platform, downtime should not be an issue), scalability (if the userbase grows rapidly, moving to a cloud environment is straight forward, no extra cost changing the application)

If you agruee with Business Guyes you must use the terms:
cost (total cost of owner ship)
time to market
productivity
All what you said was right, but you missed the business related conclution:
"Spring, Hibernate, ... help to develop applications faster and in a very porductive style, so the time to market is reduced. On the other hand Spring and Hibernate tend the programmer to produce more maintainable and tested code. This will reduce the cost to maintain the software and provide the posibility to enhance the application at realative low cost."

spring + hibernate framework with jpa is provided a productive application. Because the framework is divided in to the layer that's why the new programmer can easily understand and can change easily in to the enterprises project. spring framework provides the dependency injection that means no need for the manually creation of object through the new key word. while spring provide the object and only programmer focus on the used of object. And hibernate is a orm framework which is fully rich in relation database. It used save/update/delete the data into the table by taking the java object only. It reduce the java code for the database connectivity and writing the sql query and much more . hibernate provide the methods for dml(data manipulation language) operations.

the Spring is the ultimate framework, and the hibernate supoort of it is just amazing,
it help a lot,
security features, helpful in TDD programing,
unit test, integration testing etc.
it is very helpful in maintaining very bulky project very easily.
today most of the heavy projects managers prefer spring with hibernate
hope it is helpful to you
thanks

What's the "low risk" choice between JDO or JPA?

Do not close this as a duplicate of other questions because I'm not asking the same thing. They're also about a year old. That said, see these links:
http://db.apache.org/jdo/jdo_v_jpa.html
http://www.datanucleus.org/products/accessplatform/jdo_jpa_faq.html
http://www.datanucleus.org/products/accessplatform/persistence_api.html
It seems JPA is the "popular" choice backed by the big vendors (who love to screw you over if they can).
It seems JDO is the more mature, seemingly superior choice which should enjoy more OSS community backing. (But does it?)
So what's a low-risk tolerance organization supposed to do? Is the difficulty of going from one to the other about the same? Has one started to emerge above the other at this point? Also, only because we currently use it, does Hibernate limit you to JPA-only? If so what is the most popular JDO implementation?

#Crusader - what makes you think that anyone on SO has a better crystal ball than you do?
So what's a low-risk tolerance organization supposed to do?
Pick the alternative that it determines to be the low risk solution. How it determines what solution has the least risk is ... unclear ... but I don't think that asking SO is a valid risk assessment procedure.
The other point is that choosing JDO when JPA is the "winner" (or vice versa) probably won't kill your project in the short or long term. The consequences of making the wrong choice are most likely limited to greater staff training costs, and being stuck with base ORM platform where development has stagnated and support is increasingly expensive. [I'd protect myself against the latter by picking an open source ORM platform ... either way.]
Is the difficulty of going from one to the other about the same?
Probably yes. Especially when you consider data migration issues.
Has one started to emerge above the other at this point?
JPA seems to dominate these days. The JDO folks would say that their way is technically superior, but that's not the point.
Also, only because we currently use it, does Hibernate limit you to JPA-only?
JPA plus Hibernate-specific extensions. Certainly Hibernate does nor support JDO and it probably never could.
If so what is the most popular JDO implementation?
Pass.

If you use a lightweight dependency injection and ORM wrapping framework like the open source exPOJO it allows you to bypass that question altogether. Your main code base remains completely agnostic of the underlying persistence interface/technology (JDO, Hibernate implementations currently supported, JPA on the way - like to lend a hand?).
All persistence technology specific code is encapsulated within Repository and Service classes as per Chris Richardson's excellent book "POJOs in Action" and exposed using the "exposed domain model" pattern he discusses in the book - which turns out to be pretty awesome and the most productive approach I've ever used.
Using exPOJO 99% of your code remains gloriously and instantly portable between JDO, JPA, Hibernate plus you get extremely lightweight and very simple dependency injection (no annotations or XML required) as an added bonus.
It comes with it's own extremely lightweight and easy to use servlet filter that can provide "open session/persistence manager/entity manager in view" without the XML hell. Each HTTP request is automatically attached to a ModelExposer object that provides convenient access to the repository and service components that allow generic access to your objects.
exPOJO is at http://www.expojo.com - yeah ok, I wrote it so I am biased slightly =]

Choose 'better' or more familiar technologies for a new project?

I am looking to start work on a brand-new project, something I've been thinking about for a while as my first independent sellable project.
It's broadly speaking a web-based service application, and my first choice, server-language is quite easy... I know Java pretty well from working on Java web-apps in the past.
However my experience doing web-apps involved JSP, Servlets and JSTL... I know the ideas behind newer technologies like Hibernate/Spring but have never used them. So we wrote our own DAOs, handled AJAX by writing special mini-JSP pages that generated XML/JSON pages, etc.
I'm not hugely into the idea that Spring/Hibernate are the 'only' or 'right' way to do any Java web-project, but they are widely used. On the other hand, not only would trying to learn these increase initial development time, but I'd be using my learning attempts to build a production system.
I remember one of Joel's early articles said (I'll paraphrase since I can't find it)
"regardless what's cool, always use
the technologies that the lead
developer (or dev team?) knows best"
I wondered what people thought about that?
ps: should this be CW?

I work as a consultant, and I've seen a lot of projects where the devs started out with servlets+JSP because that's what they knew, and it's pretty simple to get started with. However, it gives the team an opportunity/excuse to write a platform of their own, which is more fun than using someone else's and just writing an application.
As the project grows, the team reinvents more and more wheels, quite a few of which end up square. That's where I enter the picture - adding new stuff to this semi-flexible platform has become so complicated that the devs can't keep up adding features and fixing bugs without calling in reinforcements. Just to add insult to injury, the internal devs are usually the ones who get assigned to do the boring bug fixes because bug fixes require more knowledge of the gory entrails of what has become the team's proprietary persistence-and-web framework, and so those gosh-danged consultants get to do the new, fun stuff.
Now, you shouldn't use a framework just because people have been regurgitating each other's blog posts about the awesomeness of it, but you should also realize that there are very good reasons why those frameworks exist (and why they're used). If you haven't used any web frameworks at all, I'd recommend you to take Spring MVC, Wicket or whatever for a test drive. They don't solve all problems, and they do cause some of their own, but the grand total is usually a productivity increase, especially if you're making advanced user interfaces.
I have been on projects where plain JDBC has been quite sufficient for persistence, and where no more advanced web frameworks than servlets+JSP have been needed, but those projects are a minority. Without having used a framework or two, you'll never whether your project is part of that minority that doesn't need one, or if it is part of the grand majority that does.

Don't try everything all at once - take on one new technology at a time.

Beware the lure of cool new frameworks! I'm currently hacking on a tiny little web app that just has a login, a few mostly static pages, and a few forms to request some information by email. It would have taken me maybe two days to do as traditional Servlet/JSP in MVC style. Instead, since there was slack in the schedule, I decided to use this project to get up to speed in Spring, Spring MVC, and Spring WebFlow. While it's quite possible that I'm just dense, it took me several weeks to get my head around the right way of doing things, I'm still not totally confident that I'm doing everything correctly, and the application is still not done. Fortunately, due to slack, I'm not in danger of the overall project schedule slipping, but I'm always asking myself if I'm going to have to scrap it and start over.
I have learned my lesson, though: next time, I won't be the one pushing a new framework unless its one I've used for production projects before. That said, I'm glad I now understand Spring (or at least I think I do) and will not hesitate to use it again next time.
So how would I learn a new framework next time? If there's a project lead (in this case I'm a project lead of a team of one, no help there) I'd use the framework that they put in place. If there isn't, or if I want to learn a framework that the project lead isn't using, I'd use it for a side project on my own time. Learning is good. Putting company work at risk by throwing untested technology at it is not so good.

I can say for sure that Spring is worth considering. It gives you as much as you can take, but it doesn't bother you with things you don't need.
For example, at the very beginning you probably need dependency injection only. Then you'll need help with database interactions and transaction management. Then you'll decide to apply MVC patter to your web-application. After that may be you'll realize that components of your system are to send JMS to each other. And so on and so forth.
For all this cases Spring has it's own simple, intuitive, light-weight solution.

When starting a new project limit the number of unfamiliar technologies / frameworks to use. Every framework takes time to learn and every framework has issues especially if not implemented correctly.
If you can I would recommend you look into the Play framework. It is a web framework for Java that focuses on developer productivity. You can choose to use Spring / Hibernate if you want but you are not bound by that. It has a very easy to learn implementation and you should be able to get a good idea within a day of playing around with it if it is what you are looking for.

It depends what the customer wants (in the world of consultancy).
You have to learn new technologies. Does the customer wants to pay for that?
Not all the caveats of the new ones are known, whereas the older ones are proven a lot more.
Of course, if everybody thought like this we would all be stuck with VB these days. You have to look for the right balance, and learn a lot yourself too so you can get an objective view on the technologies available, their up and downsides.

i personally would definitely recommend looking into spring, i've found it's saved me countless hours. hibernate is also useful if you need an ORM layer (and spring has nice integrations with hibernate too). they're certainly not the 'only' or even the 'right' way to do things (that's quite subjective) but they have both saved me time and effort, especially spring.

There is one major trap with any unknown technology. You do not know where the dragons are, and you do not know how to rub the new technology "with the hairs".
Learning that will take time, and you need to have that in your estimates. Also your estimates will most likely be too low...

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

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?

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.

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.

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.

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
Has very nice scoping - you can have objects scoped to Session, pageload, conversation (conversation is an unit of work from user perispective).
Does not require much XML.
Does not require much boilerplate code!
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)
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 :).

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

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.

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.

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...

Does it make sense to use a framework for a simple java web app?

I've done lots of java web development using jsps and servlets, and I have found this approach to be straightforward and flexible. Some of the groundwork involved though - such as managing database connections - is rather tedious, and it takes a fair amount of work just to get a new web app off the ground.
I'm therefore considering using a framework for the first time, but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration. What I'm looking for is something simple that (after the initial learning curve) will enable me to get up and running with a new web app as quickly as possible.
So my question is - does it make sense to use a framework for a simple java web app?
Note that I'm not asking which framework to use (if indeed a framework is recommended), as it has already been asked here.

If you don't use a web framework you'll usually end up writing one - poorly.

It makes a lot of sense. My team has spent the better part of five years with our open source stack and no matter and we have a "seed" project (works like appfuse) that we use to create all new web apps. Even the simple two pagers from the pov of maintaining the app, it looks like every other app, just smaller.
The short is you won't get any return on the investment right now, but you will as the project evolves and you maintain it.

Yes, I would use a web framework for the following reasons:
Increased navigation capabilities and controls. Even though you may not need them, they are there for you to use should you require them at any time
As others have indicated, apps grow over time and you will feel the need for the framework at some point in time in the future. When you need to add additional pages and navigation
Features that allow you to plug into other frameworks such as security and DB access frameworks. Spring is a prime example in the Java world. You never have to use Spring but it plugs in so well with Struts, Spring MVC, Hibernate, Acegi etc. It ends up saving you the hassle of doing all of the plumbing on your own.
Support!!! Good frameworks almost always have a vibrant community to support them and ask and answer questions.
It may seem like too much hassle initially but definitely saves you much time in the future

I'd say it actually matters quite a lot which framework you go for. Something like Spring MVC is fairly unobtrusive in your code and allows you existing stuff to run quite a lot as-is. Other frameworks have much more specific ideas about how you should do things.

Yes it does make sense. Apps can grow and change and might require something a framework can provide easily in the future.
For example at my workplace we have simple jsp / servlet app. It needs to be rewritten just because of what I explained above. If someone would have taken the time to just get the framework setup we would be in better shape today.

Yes it makes sense. However implicit in your question is that the wrong (for you) framework can be more pain than it's worth - and that's true. There is a world of difference between some heavy J2EE framework and something light and cheerful like grails.

What's the alternative? Rolling your own? Embedding all the navigation and logic in the JSPs?
I agree with those who say that a web framework is worth it. There are literally hundreds now (e.g., Struts, JSF, Spring, Wicket, etc.). Pick one that suits you.

There are two kinds of applications:
1) the kind that you throw away and never use again, and therefore should not worry about modularity, maintainability and clarity.
2) the real kind.
It may sometimes seem that your app may never have to grow, scale, or service a larger feature set / user base than you currently are planning for....I assure you, that perception is always wrong.
Frameworks, specifically things like Struts for MVC in Java, Spring for MVC and Dependency Injection, Hibernate for Object-Relational Modeling are all extremely valuable tools that lead to modularity, maintainability and clarity in your code. So, to answer your original question.... Yes, emphatically.

No it doesn't unless:
you don't have any java experience
in your team
you are doing just a prototype that
must be ready in hours
you don't trust your developers
enough to let them write your
application
you don't plan to let your
developers learn and improve
Danger in using frameworks include but not limited to:
you'll get all framework defects on
top on your own
you'll be unable to do realistic estimates until you
know perfectly the framework
your team won't learn how to program a
web server
you'll find your team passing more
and more time on google instead that
solving problems by writing code.
The only thing that is worst that choosing a open source framework is having a separate R&D team in the company who should create the "big complete ultimate company framework".

but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration
Not necessarily true. The good frameworks are built to scale well so that they will take you from small apps to very large apps. Many of the frameworks today are moving towards zero configuration so you will find them easier and easier to use.
You are right that it does take an initial effort to learn the framework itself but that investment pays for itself in the very first application you build. And meta frameworks like AppFuse makes it even easier to get started since it pre-configures the frameworks for you.

Frameworks make sense for most applications. It may be necessary for you to build your own or adopt some other framework. The most important questions is the granularity of your data structures. What I mean by this is do you need to just enter data or do you need to parse, compile and execute dynamic code?
If you think of a frame works as a gauge and to the left is an all ready existing frame work open source or closed and to the right is all custom framework then super impose your code on top of that frame work where the level of complexity increases to the right. The farther right you go the more of a stuggle you will have with the frame work (IMO).
However, you can also slowly migrate from existing to custom framework.
There is also the question about your business. If you work for a business that does not look at software as it's core compentency such as a bank or hospital then you need to way that into how much of a frame work you want to build.
Bottom line a framework of some type will always be useful.

Using a framework may add some overhead to your web-app development due to the learning curve. However, depending on the framework you choose, you may be able to realize the following benefits:
Scalability
Maintainability
Clear Division of your model (e.g. MVC)
Out-of-the-box components(SessionManagement,authentication,etc )
Third party plugins
Modularity inherited from the framework
Many others.
Besides, the learning curve is a variable factor. Some frameworks may be easier to learn than others depending on your skills.

It definitely makes sense to look into using a framework even if for no other reason than it'll give you a new area of knowledge. If you've got the time to invest in learning a framework then you may well find in time that it's easier and faster to use that for new projects no matter how simple they are.
Also, if I could vote for SamBeran's post then I would. Getting started with a framework will involve several moments of "oh great! I don't need to write all that boilerplate again!".

I'd say use one - like you said, it's rather tedious to get stuff up and running for even a simple java web app. If the framework helps you get the job done faster and provides the services you need, I'd say it makes sense.