I am working on medium sized web application 4-5 tabs, user login for about 100k users. We are completing redesigning the application from scratch and using spring and hibernate, connected to MySQL.
Did you experience major issues and what where did Spring benefit your application.
No major issues. Spring was particularly of benefit for:
Making all the configuration plumbing consistent and straightforward
Dependency Injection to support better factoring of code
Declarative "Open Session In View" functionality for Hibernate
Declarative Transaction Demarcation
The Acegi (now Spring Security) project made it easy to integrate a custom security model
The Spring data access support removes the need for a lot of boilerplate from any JDBC access - maybe not such a boost for Hibernate usage, but we had a mix of both. It also allows you to use JDBC & Hibernate together fairly seamlessly
In addition to what has been said so far, I would focus on newer style annotations for both Spring (e.g. #Controller) and Hibernate (e.g. #Entity). It will further reduce your codebase leaving you with less code to maintain. On the downside, there is a pretty significant learning curve, but ultimately the lesson I learn time and again is that the benefits of Spring + Hibernate far outweigh the (learning curve) costs. You simply have to write a lot less code letting you focus on the business.
+1 Spring+hibernate......
100k users is not mid-size....that is huge.
With spring, you can force coder to code to interfaces and this increase testability. This is the benefit i don't hear people talk a lot about.
take a look memcached to cached data memcached.....
techincally speaking I have, I've deployed commercial applications with numbers from the thousands to a few hundreds of thousands using spring, hibernate and both.
From the management perspective in one case, I had a team that were good technologists, so they managed to rewrite an app with spring and hibernate but... they went crazy with the interfaces (each new object to the model needed 16 interfaces), abused the AOP so transactions and logging were almost impossible to follow and stack traces were meaningless, used tools to map the hibernate files without fully understanding what was being done (in some cases joining 4 tables for what could've been a simple entity, and a variety of issues that made the resulting application much harder to enhance, debug, fix, even setup the developer's environment....)
my 2c
As Julien Chastang said, you need to factor in the learning curve in your estimations if this is your first project. We failed to do that on our first try and ended up having to adjust a lot of our planning because several aspects of Hibernate were "hard" (eg. took some time) to figure out.
One specific piece of advice I can give based on an issue we came across is: if you need to write complex SQL, and you don't want to spend the time figuring out how to get such queries working within HQL or other offerings within Hibernate, get it working first in vanilla SQL and then go back later and patch it back into Hibernate.
Obviously there are a million ways to build an application like this, both in the java frameworks world and with things like Rails or Django.
A big selling point for me is that both spring and hibernate have become defacto standards in the java world, so they definitely qualify as "things you ought to know" ( I get asked on every job interview). Spring more so than Hibernate.
Getting the value of spring took a few spring-enabled apps before it made sense for me. It enforces independant code modules and a certain style of component design that facilitates testing. I'd suggest you just go with it and get the sense of the value of it from use.
I have mixed feelings about Hibernate, though it's important to use some kind of db layer, so you may as well.
Also see this question.
There are some situations with Hibernate where creating a particular object to relational mapping, or writing a particular HQL query, is very difficult. However, you're going to run into 1 thing like that out of 10, and the more normalized your database the better off you will be. It's worth it.
Any new Java web project should use Spring MVC (2.5+ with Annotations) and Hibernate.
There is a large understanding overhead to hibernate and spring. I'd only suggest it if you have plenty of time or an experienced java/spring/hibernate developer to call on. With a spring project once you get it going you can basically ignore the spring parts of it and concentrate on page and logic design. Hibernate is not that difficult. HQL is a harder ask. Most of my time is spent at the bean and JSF level. Comparing that layer of my project to some mates who are messing about in JSP, I'm glad to be in the ease of JSF. I easily swapped to Oracle from the initial implementation in MySQL, so that proves that Hibernate handles abstraction nicely.
in addition to what has been said so far, i strongly suggest the book: Spring Recipes - Problem Solution Approach (Amazon), in combination with the very good online documentation you should be ready to conquer the world ;-)
Related
May be this question broad and hard to answer at current moment
But,when i went through different frameworks emerging by one after another like
Hadoop Distributed File System
HBase,
Hive,
Cassandra,
Hypertable,
Amazon S3,
BigTable,
DynamoDB,
MongoDB,
Redis,
Riak,
Neo4J,
Stripes,
Wicket,
Compojure,
Conjure,
Grails,
JRoR,
JSF,
Lift,
Netty,
Noir,
Play,
Scalatra,
Seam,
Sitemesh,
Spark,
Spring MVC,
Stripes,
Struts,
Tapestry,
VRaptor,
Vert.x,
Stripes,
Tapestry
OpenXava
It is always buzzing me.
Each framework has some unique features.Each one promises to solve some particular testing,development and production need with respect to increasing no of users ,data expansion,distributed computing and security ,performance and many more .
But,many functionality is common on them .Striving for unique some functionality we have to shift from one framework to another As,a java developer i would like to have following features included in one framework
like
Out of box support for testing for unit and integration testing
Fast prototyping
Distributed multithreading,caching,logging ,session management ,moduaralization
Security extension
Framework extension
Easily integration with big data .
Distributed data computation
Asychronous operation
High performance
I would like to know what other features others really want to have in one framework ?What others developer really want to have features included in one framework .What are the necessary and essential featues that every framework must include .Please share yours idea.
The reason they differ is because there is no consensus on these matters. Depending on your background and expertise the answer will be different. Every project was started knowing full well what the alternatives were and not being content with them.
This question is useless I'm afraid.
I think XKCD describes it well (replace standard with framework):
There is simply no way given an enough complex problem to solve it for all use cases and users.
The key to understanding is not in how much common is there about all those frameworks but in that most of them cover only part of needs. For instance, Hadoop and Stripes do nothing in common. Only few frameworks claim they cover everything (Java EE and Spring in fact) but in reality they just try to collect several unrelated technologies under one brand name.
The real domains are: presentation layer, data access layer and (arguably) something else.
I have an application that is undergoing massive rework, and I've been exploring different options - chug along 'as is', redo the project in a different framework or platform, etc.
When I really think about it, here are 3 major things I really dislike about java:
Server start/stops when modifying controllers or other classes. Dynamic languages are a huge win over Java here.
Hibernate, Lazyloading exceptions (especially those that occur in asynchronous service calls or during Jackson JSON marshalling) and ORM bloat in general. Hibernate, all by itself, is responsible for slow integration start up times and insanely slow application start up times.
Java stupidity - inconsistent class-loading problems when running your app inside of your IDE compared to Tomcat. Granted once you iron out these issues, you most likely won't see them again. Even still, most of these are actually caused by Hibernate since it insists on a specific Antlr version and so on.
After thinking about the problem... I could solve or at least improve the situation in all 3 of these areas if I just got rid of Hibernate.
Have any of you reworked a 50+ entity java application to use mongo or couch or similar database? What was the experience like? Do you recommend it? How long did it take you assuming you have some pretty great unit/integration tests? Does the idea sound better than it really is?
My application would actually benefit in many areas if I could store documents. It would actually open up some very cool and interesting features for this application. However, I do like being able to create dynamic queries for complex searches... and I'm told that Couch can't do those.
I'm really green when it comes to NoSQL databases, so any advice on migrating (or not migrating) a big java/spring project would be really helpful. Also, if this is a good idea, what books would you recommend I pick up to get me up to speed and really make use of them for this application in the best way possible?
Thanks
In any way, your rant doesn't just cover problems with the previously made (legacy) decision for Hibernate but also with your development as a programmer in general.
This is how I would do it, should a similar project be dropped in my lap and in dire need of refactoring or improvement.
It depends on the stage in your software's lifetime and the time pressure involved if you should make big changes or stick with smaller ones. Nevertheless, migrating in increments seems to be your best option in the long term.
Keeping the application written in Java for the short term seems wise, a major rewrite in another language will definitely break acceptance and integration tests.
Like suggested by Joseph, make the step from Hibernate to JPA. It shouldn't cost too much time. And from there you can switch the back-end to some other way of storage. Work towards a way of seperating concerns. Pick whatever concept seems best, some prefer MVC while others might opt for CQRS and still others adore another style of segmentation/seperation.
Since the JVM supports many languages, you can always switch to any of those or at least partially implement functionality in more dynamic languages. This will solve part of the problem where you keep bumping into the "stupidity" of Java, while still retaining the excellent optimizations of current JVMs at runtime.
In addition, you might want to set up automatic integration tests... since the application will hopefully never be run from your IDE, these tests will give you honest results.
Side note: I never trust my IDE to get dependencies right if the IDE has capabilities to inject its own libraries into my build or runtime path.
So to recap in short: small steps; lose Hibernate and go more abstract to JPA; if Java becomes stupid, then gradually switch to a clever language. Your primary concern should be to restructure the code base without losing functionality, keeping in mind to have an open design which will make adding interesting and cool features easier later on.
Well, much depends on things like "what exactly are the pain points with Hibernate?" (I know, you gave three examples...)
But those aren't core issues over the long haul. What you're running into is the nature of a compiled language vs. a dynamic one; at runtime, it works out better for you (as Java is faster and more scalable than the dynamic languages, based on my not-quite-exhaustive tests), but at development time, it's less amenable to just hacking crap together and hoping it works.
NoSQL isn't going to fix things, although document stores could, but there's a migration step you're going to have to go through.
Important: I work for a vendor in this space, which explains my experience in the area, as well as the bias in the next paragraph:
You're focusing on open source projects, I suppose, although what I would suggest is using a commercial product: GigaSpaces (http://gigaspaces.com). There's a community edition, that would allow you to migrate JPA-based java objects to a document model (via the SpaceDynamicProperties annotation); you could use JPA for the code you've written and slowly migrate to a fully document-oriented model at your convenience, plus complex queries aren't an issue.
All of those points are usually causing problems due to incompetence, rather than hibernate or java being problematic:
apart from structural modifications (adding fields or methods), all changes in the java code are hot-swapped in debug mode, so that you can save & test (without any redeploy).
the LazyInitializationException is a problem for hibernate-beginners only. There are many and clear solutions to it, and you'll find them with a simple google or SO search. And you can always set your collections to fetch=FetchType.EAGER. Or you can use Hibernate.initialize(..) to initialize lazy collections.
It is entirely normal for a library to require a specific version of another library (the opposite would be suspicious and wrong). If you keep your classpath clean (for example by using maven or ivy), you won't have any classloading issues. I have never had.
Now, I will provide an alternative. spring-data is a new portfolio project by springsource, that allows you to use your entities for a bunch of NoSQL stores.
A legacy web application written using PHP and utilizing MySql database needs to be rewritten completely. However, the existing database structure must not be changed at all.
I'm looking for suggestions on which framework would be most suitable for this task? Language candidates are Python, PHP, Ruby and Java.
According to many sources it might be challenging to utilize rails effectively with existing database. Also I have not found a way to automatically generate models out of the database.
With Django it's very easy to generate models automatically. However I'd appreciate first hand experience on its suitability to work with legacy DBs. The database in question contains all kinds of primary keys, including lots of composite keys.
Also I appreciate suggestions of other frameworks worth considering.
Use sqlalchemy. On any framework you choose. It can reflect your database as ORM.
I’m currently rebuilding a legacy PHP web application with a MySQL database my self.
The PHP code was kind of spaghetti and is now rewritten in Java as it type safe, promotes well-structured code, has excellent tooling and has superior unit testing capabilities. For database to Java mapping I use Hibernate/JPA.
The web application is incrementally delivered to production. Meaning we run both Java and large parts of the old PHP code together until the application is fully converted.
But in order to use hibernate effectively we needs the database to be logical correct (something MySQL MyIsam does not enforce). So with each production release I run an refactoring scripts for the database (also used to build the development environment and do unit testing) and update the PHP code with a new version that works with the schema changes.
As a web framework I use Stripes as it’s simple, elegant and easy to learn.
I have very good experience with Django. Every time I needed it was up to the task for interfacing with existing database.
Autogenerated models are the start, as MySQL is not the strictest with its schema. Not that it will not work only that usually some of the db restrictions are held in app itself.
My first thought would be to use Hibernate and Java, but I may be biased because that is what my experience is in. You generally map your Model classes via Hibernate after you create the database anyway, so it might not be a bad choice.
I'll let it explain itself to you: Hibernate's website
I suppose that any PHP Framework (I'm a PHP guy, so I will only talk about PHP) could be OK for you ; but you should use one that's well-supported, has a large community, ...
To make things short, I'm thinking about one off this list :
Symfony
Zend Framework
CakePHP
Kohana
Code Igniter
Now, if you're asking "which framework is the best", it's a question that doesn't really have an answer : it's mainly a matter of personnal preferences...
Still, here's a couple of questions+answers that could bring you some interesting informations :
Best PHP framework for an experienced PHP developer?
What PHP framework would you choose for a new application and why?
To use a PHP framework or not?
PHP Framework Decision - Analysis paralysis!
PHP - MVC framework?
Which PHP Framework is right for this project?
Also, note that choosing a Framework is an important decision -- which means you should take some time to evaluate each framework and how it'll answer your specific need.
Really : you should definitely not rush that decision.
You know, there's a whole Ruby web dev world away from Rails, e.g.:
Sinatra
Ramaze
Webby
With such a general question it's always a bit hard to help...
Try web2py, extremely easy to prototype any webapp, and IMO a bit easier to grasp (overall) than other similar web frameworks, HTH
There are no clear cut winners when picking a web framework. Each platform you mentioned has its benefits and drawbacks (cost of hardware, professional support, community support, etc.). Depending on your time table, project requirements, and available hardware resources you are probably going to need some different answers.Personally, I would start your investigation with a platform where you and your team are most experienced.
Like many of the other posters I can only speak to what I'm actively using now, and in my case it is Java. If Java seems to match your projects requirements, you probably want to go with one of the newer frameworks with an active community. Currently Spring Web MVC, Struts2, and Stripes seem to be fairly popular. These frameworks are mostly, if not totally, independent of the persistence layer, but all integrate well with technologies like hibernate and jpa; although you have to do most, if not all, of the wiring yourself.
If you want to take the Java road there are also pre-built application stacks that take care of most of wiring issues for you. For an example you might want to look at Matt Raible's AppFuse. He has built an extensible starter application with many permutations of popular java technologies.
If you are interested in the JVM as a platform, you may also want to look at complete stack solutions like Grails, or tools that help you build your stack quickly like Spring Roo.
Almost all of the full stack solutions I've seen allow for integration with a legacy database schema. As long as your database is well designed, you should be able to map your tables. The mention of composite keys kind of scares me, but depending on your persistence technology this may or may not be an issue. Hibernate in Java/.NET supports mapping to composite keys, as does GORM in grails (built on hibernate). In almost all cases these mappings are discouraged, but people who build persistence frameworks know you can't always scorch earth and completely recreate your model.
I'm new to Flex development, and RIAs in general. I've got a CRUD-style Java + Spring + Hibernate service on top of which I'm writing a Flex UI. Currently I'm using BlazeDS. This is an internal application running on a local network.
It's become apparent to me that the way RIAs work is more similar to a desktop application than a web application in that we load up the entire model and work with it directly on the client (or at least the portion that we're interested in). This doesn't really jive well with BlazeDS because really it only supports remoting and not data management, thus it can become a lot of extra work to make sure that clients are in sync and to avoid reloading the model which can be large (especially since lazy loading is not possible).
So it feels like what I'm left with is a situation where I have to treat my Flex application more like a regular old web application where I do a lot of fine grained loading of data.
LiveCycle is too expensive. The free version of WebOrb for Java really only does remoting.
Enter GraniteDS. As far as I can determine, it's the only free solution out there that has many of the data management features of LiveCycle. I've started to go through its documentation a bit and suddenly feel like it's yet another quagmire of framework that I'll have to learn just to get an application running.
So my question(s) to the StackOverflow audience is:
1) do you recommend GraniteDS,
especially if my current Java stack
is Spring + Hibernate?
2) at what point do you feel like it starts to
pay off? That is, at what level of
application complexity do you feel
that using GraniteDS really starts
to make development that much
better? In what ways?
If you're committed to Spring and don't want to introduce Seam then I don't think that Granite DS will give you much beyond Blaze DS. There is a useful utility that ensures only a single instance of any one entity exists in the client at any one time but it's actually pretty easy to do that with a few instances of Dictionary with weak references and some post-processing applied to the server calls. A lot of the other features are Seam-specific as alluded to here in the docs:
http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework
Generally, the Tide approach is to minimize the amount of code needed to make things work between the client and the server. Its principles are very similar to the ones of JBoss Seam, which is the main reason why the first integration of Tide has been done with this framework. Integrations with Spring and EJB 3 are also available but are a little more limited.
I do however think that Granite's approach to data management is a big improvement over Livecycle's because they are indeed quite different. From the Granite docs:
All client/server interactions are done exclusively by method calls on services exposed by the server, and thus respect transaction boundaries and security defined by the remote services.
This is different to how Livecycle DS uses "managed collections" where you invoke fill() to grab large swathes of data and then invoke commit() methods to persist changes en-mass. This treats the backend like a raw data access API and starts to get complicated (or simply fall apart entirely) when you have fine-grained security requirements. Therefore I think Granite's approach is far more workable.
All data management features (serialization of JPA detached entities, client entity caching, data paging...) work with Spring.
GraniteDS does not mandate anything, you only need Seam if you want to use Seam on the server.
Actually, the free version of WebORB for Java does do data management. I've recently posted a comparison between WebORB for Java, LiveCycle DS, BlazeDS and GraniteDS. You can view this comparison chart here: http://bit.ly/d7RVnJ I'd be interested in your comments and feedback as we want this to be the most comprehensive feature comparison on the web.
Cheers,
Kathleen
Have you looked at the spring-blazeDS integration project?
GraniteDS with Seam Framework, Hibernate and MySql is a very nice combination. What I do is create the database, use seamgen to generate hibernate entities then work from there.
My developers are waging a civil war. In one camp, they've embraced Hibernate and Spring. In the other camp, they've denounced frameworks - they're considering Hibernate though.
The question is: Are there any nasty surprises, weaknesses or pit-falls that newbie Hibernate-Spring converts are likely to stumble on?
PS: We've a DAO library that's not very sophisticated. I doubt that it has Hibernate's richness, but it's reaching some sort of maturity (i.e. it's not been changed in the last few projects it's included).
They've denounced frameworks?
That's nuts. If you don't use an off-the-shelf framework, then you create your own. It's still a framework.
I've used Hibernate a number of times in the past. Each time I've run into edge cases where determining the syntax devolved into a scavenger hunt through the documentation, Google, and old versions. It is a powerful tool but poorly documented (last I looked).
As for Spring, just about every job I've interviewed for or looked at in the past few years involved Spring, it's really become the de-facto standard for Java/web. Using it will help your developers be more marketable in the future, and it'll help you as you'll have a large pool of people who'll understand your application.
Writing your own framework is tempting, educational, and fun. Not so great on results.
Hibernate has quirks to be sure but that is because the problem it is trying to solve is complex. Every time someone complains about Hibernate I remind them of all of the boring DAO code that they would have to maintain if they weren't using it.
A few tips:
Hibernate is no substitute for a good database design. Hibernate schemas are OK but you will have to tweak them occasionally
Eventually you are going to have to understand how Hibernate lazy loads classes and how that affects things. Hibernate modifies the Java bytecode and you will need to delve into the depths sooner or later if only to explain why object links are null.
Use annotations if you can.
Take the time to learn the Hibernate performance tuning techniques, it will save you in the long run.
If you have a fairly complex database, Hibernate may not be for you. At work we have a fairly complex database with lots of data, and Hibernate doesn't really work for us. We've started using iBATIS instead. However, I know a lot of development shops who use Hibernate successfully - and it does do a lot of grunt work for you - so it's worth considering.
Spring is a good tool if you know how to use it properly.
I would say that frameworks are definitely a good thing - like others have pointed out, you don't want to reinvent the wheel. Spring contains a lot of modules which will mean you won't have to write so much code. Don't succumb to the "Not Invented Here" syndrome!
Lazy loading is the big gotcha in MVC applications that use Hibernate for their persistence framework. You load the object in the controller and pass it to the JSP view. Some or all of the members of the class are proxied and everything blows up because you Hibernate session was closed when the controller completed.
You will need to read the Open Session in View article to understand the problem and get a solution. If you are using Spring the this blog article describes the Spring solution to the open session in view issue.
This is one thing (I could remember) that I fell into when I was in my Hibernate days.
When you delete (several) child objects from a collection (in a parent entity) and then add new entities to the same collection in one transaction without flushing in the middle, Hibernate will do "insert" before "delete". If the child table has a unique constraint in one of its columns, and you are expecting that you would not violate it since you have already deleted some data before (just like I was), then get ready to be frustrated.
Hibernate forum suggests:
It was a DB design flaw, redesign;
flush (or commit if you will) in between the deletes and inserts;
I couldn't do both, and end up tweaking the Hibernate source and recompiling. It was only 1 line of code. But the effort to find that one line was equal to approximately 27 cups of coffee and 3 sleepless nights.
This is just one example of problems and quirks you might end up when using Hibernate with no real expert on your team (expert: someone with adequate knowledge about the philosophy and internal working of Hibernate). Your problem, solution, litre of coffee, and sleepless night count may vary. But you get the idea.
I haven't worked much with Java but I did work in large groups of Java developers. The impression I've got was that Spring is OK. But everybody was upset at Hibernate. Half the team if asked "If you could change one thing, what would you change?" and they'd say "Get rid of Hibernate.". When I started to learn Hibernate it struck me at amazingly complex, but I didn't learn enough (thankfully I've moved along) to know if the complexity was justified or not (maybe it was require to solve some complex problems).
The team got rid of Spring in favor of Guice, but that was more like a political change, at least from my point of view and other developers I've talked to.
I have always found Hibernate to be a bit complex and hard to learn. But as JPA (Java Persistence API) and EJB (Enterprise Java Beans) 3.0 has existed for a while things have gotten a lot easier, I much prefer annotating my classes to create mappings via JavaDoc or XML. Check out the support in Hibernate. The added bonus is that it is possible (but not effortless) to change the database framework later on if needed. I have used OpenJPA with great results.
Lately I have been using JCR (Java Content Repository) more and more. I love the way that my modules can share a single data storage and that I can let the structure and properties evolve. I find it a lot easier working with nodes and properties rather that mapping my objects to a database. A good implementation is Jackrabbit.
As for Spring, it has a lot of features I like, but the amount of XML needed to configure means I will never use it. Instead I utilize Guice and absolutely love it.
To roundup, I would show your doubting developers how Hibernate will make their life easier. As for Spring I would seriously check if Guice is a viable alternative and then try to show how Spring/Guice makes development better and easier.
I've done a lot of Spring/Hibernate development. Over time the way people used both in combination has changed a bit. The original HibernateTemplate approach has proved to be difficult to debug since it swallows and wraps otherwise useful exceptions; talk to the Hiberante API directly!
Please keep looking at the generated SQL (configure your development logging to show SQL). Having an abstraction layer to the database doesn't mean you don't have to think in SQL anymore; you won't get good performance if you otherwise.
Consider the project. I've choosen iBatis over Hibernate on several occasions where we had stringent performance requirements, complex legacy schemas or good DBa's capable of writing excellent SQL.
As for Hibernate: a very good tool for application which deals with a rapidly changing database schema, a large amount of tables, do lots of simple CRUD operations. Reports with complex queries involved are rather less well handled. But in these case I prefer mixing in JDBC or native queries. So, for a short answer: I do think time spent learning Hibernate is a good investment (they say it is compliant with EJB3.0 and JPA standards, also, but that didn't come into the equation when I evaluated it for my personal use).
As for Spring... see The Bile Blog :)
Remember: frameworks are not silver bullets, but you should not reinvent the wheel either.
I find it really helps to use well-known frameworks such as Hibernate because it fits your code into a specific mold, or a way of thinking. Meaning, since you're using Hibernate, you write code a certain way, and most if not all developers who know Hibernate will be able to follow your line of thinking quite easily.
There's a downside to this, of course. Before you become a hot shot Hibernate developer, you're going to find that you're trying to fit a square into a circular hole. You KNOW what you want to do, and how you were supposed to do it before Hibernate came into the picture, but finding the Hibernate way of doing it may take... quite a bit of time.
Still, for companies that frequently hire consultants (who need to understand a lot of source code in a short amount of time) or where the developers sign on and quit frequently, or where you just don't want to bet that your key developers will stay forever and never change jobs -- Hibernate and other standard frameworks are a pretty good idea I think.
/Ace
Spring and Hibernate are frameworks that are tricky to master. It may not be a good idea to use them in projects with tight deadlines while you're still trying to figure out the frameworks.
The benefits of the frameworks is basically to try to provide a platform to allow for consistent codes to be products. From experience, you'd be well advised to have developers experienced with the frameworks setting in place best practices.
Depending on the design of your application and/or database, there are also quirks that you'll need to circumvent to ensure that the frameworks do not hinder performance.
In my opinion, the biggest advantage of Spring is that it encourages and enables better development practices, in particular loose coupling, testing, and more interfaces. Hibernate without Spring can be really painful, but the two together are very useful.
Retrofitting an existing project to any framework is going to be painful, but the refactoring process often has serious benefits for long-term maintainability.
I have to agree with many posts on this one. I've used both, extensively, in a variety of settings. If I could undo a design decision it would be to have used Hibernate. We actually budgeted a release in one of our products to swap Hibernate for iBatis and Spring-JDBC for a best-of-all-worlds approach. I can have a new developer get up to speed using Spring-JDBC, Spring-MVC, Spring-Ioc, and iBatis faster than if I just tasked them with Hibernate.
Hibernate is just too complicated for this KISS developer. And heaven help you with hibernate if your DBA sees the generated SQL the database sees and sends you back with optimized versions.
The top answer mentions that Hibernate is poorly documented. I agree that the online reference manual could be more complete. However, a book written by Hibernate's authors, 'Java persistence with Hibernate' is a must-read for every Hibernate user and very complete.
#slim - I am with you again this morning.
It sounds like a classic case of Not Invented Here Syndrome. If they aren't keen on spring, they should consider other options rather than rolling their own framework (whether they acknowledge doing it or not). Guice comes to mind as an possibility. Also picocontainer. There are others out there, depending on what you need.
Spring and Hibernate definitely make life easier.
Getting started with them might be a little time-consuming at the beginning, but you'll certainly benefit from it later. Now the XML is being replaced by annotations, you don't need to type hundreds of lines of XML either.
You may want to consider AppFuse to reduce your learning-curve: generate an application, study and adapt it, and off you go.
Frameworks are not evil. even the Java SDK is a framework.
What they probably fight is framework proliferation. You shouldn't bring a framework to a project just for the kick of it, it should bring consistent value in a reasonable time. Every framework requires a learning curve, but should reward you with increased productivity and features later on.
If you struggle with code that is hard to debug because of inconsistent database usage, complicated cache mechanisms, or a myriad of other reasons. Hibernate will add great value.
apart from the learning curve (which took about 1 month of practical work for me) there weren't any pitfalls, provided you have someone around to explain the basics for you.