Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I work to a project that it has installed Spring, Hibernate and JPA.
I have read tutorials about Hibernate and JPA and the big picture is that JPA is an interface, and Hibernate is the implementation of JPA.
But why to use JPA, with what it helps me? What are the differences between JPA and Hibernate. First, i thought that annotations in POJO classes are from JPA, but no, they are from Hibernate Annotations.
So, the big question is, for what is good JPA?
Thanks!
The root reason for JPA to exist lies within the larger Java Enterprise specification. There was a growing need for a standardised ORM API to be part of the JavaEE 5 specification for standardisation across Java enterprise containers. That's it - that is why JPA exists and why existing ORM packages such as Hibernate do their best to implement it to the letter.
The net gain is quite simple; any Java Enterprise container (JBoss Wildfly, Weblogic, etc.) will support the JPA specification and will have an implementation for it built-in. Thus if you build an application or library and use only the JPA API in your code, you don't even have to package Hibernate or any other ORM with your application - it will during runtime just use whatever ORM the container provides.
Historically this wasn't usually possible because you'd still end up needing to add ORM specific configuration properties, so you at least needed to be aware of what ORM would be available on deployment to cater towards it. But since JPA 2.0 and 2.1 most of the common and uncommon configuration options have been standardised.
Long story short: if you're deploying to a JavaEE (or Spring Boot) container then using JPA is simply a good idea because it is readily available and is the standard (for object relational mapping).
If you're not going to be deploying to a JavaEE container and are going to be packaging an ORM with your application - well then you're even more free to do what you want. Just be aware that you wouldn't be the first to kick themselves when they're at a later point in time porting over code or maintaining a code base with mixed API usage.
Java Persistence Architecture (JPA) is a standard for Java object-relational mapping solution like Hibernate, TopLink, etc. Hibernate is a particular implementation of JPA.
You should be using JPA annotations so you aren't locked into Hibernate.
Make sure you are using JPA for a good reason. You might not need it. JDBC might be enough for your needs.
Related
I would like to know what's the key difference between Apache Open JPA and Spring JPA.
Spring already has a mature JPA for dealing with all kinds of Java persistence but still saw few projects in my company where they uses Apache Open JPA.
Can we integrate Apache Open JPA with Spring. Also like to know what are key benefits of Open JPA.
for example ElasticPath uses Spring but for JPA they uses Apache Open JPA
First: There is no Spring JPA.
There is spring-orm which is one of the many artifacts published by the Spring Framework. It contains classes dealing with JPA and it's main implementations (Hibernate and EclipsLink) in order to integrate them into the rest of the framework. Most Spring users rarely deal with it directly.
You are probably thinking of Spring Data JPA which offers repositories implemented with JPA, which in turn offer many ways to declare queries: Query derivation from method names, named queries based on method names, annotated queries, query by example, specifications ... It is part of the Spring Data project, which offers similar features with many different persistence technologies (JPA, MongoDb, Couchbase, Elasticsearch, Jdbc, Redis, Ldap ...). Spring Data JPA uses spring-orm
Since it got mentioned a couple of times now it is time to explain JPA: JPA stands for Java Persistence API and is an API which can and is implemented by multiple vendors. Hibernate is the most popular implementation, EclipseLink is the reference implementation and Apache Open JPA is another one.
Spring Data JPA (and spring-orm) are (mostly) based on JPA and therefore you should be able to use Apache Open JPA with it. But development of Open JPA was so slow in recent years that the Spring Data Team dropped OpenJPA from the JPA implementations it tests against.
To get a feeling for the development speed, you might look at the releases from the last three years (2019-2021):
Hibernate: 32 (not counting alpha and beta releases)
EclipseLink: 12 (not counting Milestone and release candidates)
OpenJPA: 4
As for the benefits of Apache Open JPA, I consider that an opinion question and therefore off topic for SO. But since people in your company seem to use it, I suggest asking them why they chose Open JPA over the other implementations.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm confused why should i use Spring Boot for my next project? Is Spring Boot as powerful as Spring Boot-less? Or there is something you can't do with Spring Boot.
Spring Boot is opinionated Spring setup with batteries included. If you use it, you will waste less time on non-features because you will be getting quite a few things for free. List of advantages that I've observed compared to classical Spring setup (surely there are more, check the Spring Boot website):
dependency management - versions of commonly used libraries are pre-selected and grouped in different starter POMs that you can include in your project. By selecting one Spring Boot version you are implicitly selecting dozens of dependencies that you would have to otherwise select and harmonize yourself
auto-configuration - you do not have to manually configure dispatcher servlet, static resource mappings, property source loader, message converters etc.
advanced externalized configuration - there is a large list of bean properties that can be configured through application.properties file without touching java or xml config
"production ready" features - you get health checking, application and jvm metrics, jmx via http and a few more things for free
runnable jars - you can package your application as a runnable jar with embedded tomcat included so it presents a self-contained deployment unit
I haven't observed any disadvantages, it's just Spring after all. You can build anything that you could build with "vanilla" Spring, only faster.
Here is my simple explanation:
Without Spring Boot, one will have to put the correct versions of all the dependencies in the build configuration file (e.g. pom.xml) and configure all the beans manually.
This seems like a lot of non-functional task for normal projects. Hence, Spring Boot does these automatically, assuming some conventions. For example, if you just include spring-boot-starter-web dependency in your pom.xml, a web application will be automatically configured by assuming default conventions.
What makes it more interesting is that the pieces of the default configuration can be very easily overridden.
Going through a couple of official guides would give more insight on Spring Boot. In summary, unless an application is abnormal enough, people seem to be preferring Spring Boot nowadays.
Coming to power, Spring Boot could be seen as just a configuration layer. So, everything possible in Spring should also be possible using Spring Boot.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have been trying to understand Spring Boot and maybe migrate my project to it. However I do not get the real advantage of it except the embedded Tomcat. Would you kindly explain to me what is the real power of Spring Boot compared to regular Spring?
Quoting from the Spring Boot Page, it has following features:
Create stand-alone Spring applications
Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
Provide opinionated 'starter' POMs to simplify your Maven configuration
Automatically configure Spring whenever possible
Provide production-ready features such as metrics, health checks and externalized configuration
Absolutely no code generation and no requirement for XML configuration
The big advantage is out of the box configuration based on what it finds and server embedded (you can make a jar run it and go to localhost:8080 to see the result) beside that it has metrics, health checks, externalised configuration, etc.
In my opinion is the perfect tool for building cloud microservices.
Bootstrapping with defaults included in the configuration / jar-dependencies, is the real advantage of Spring boot! Get the things done quickly!
Its just another project from Spring framework, where things look simplified, with strong support for Security, Data, Social etc all features you want for your application.
If you prefer annotations over XML configuration like me you might use
#Configuration for configuration,
#ComponentScan for Dependency Injection,
and #EnableAutoConfiguration to tell spring to guess the defaults
and work along.
The #SpringBootApplication annotation is equivalent to using
#Configuration,
#EnableAutoConfiguration,
and #ComponentScan
with their default attributes.
So things further simplified, with a single annotation doing the work of 3.
It's real easy to get something going from nothing, with loads of useful defaults.
Not so easy if you want to migrate some existing project which will most likely have developed a lot of quirks that are going to be difficult to migrate.
Advantages of SpringBoot:
No need of creating boilerplate configuration
Plenty of SpringBoot Starter to quickly get up and running
DevTools to autorestart server on code/config updates
Embedded Tomcat/Jetty/Undertow support
Easier customization of application properties
Easy management of profile specific properties
Easier dependency management using platform-bom
Here are few of my articles on what are the advantages of SpringBoot and how SpringBoot works.
Why SpringBoot?
How SpringBoot AutoConfiguration magic works?
Biggest of all is that spring boot is aligned with the concept of microservices and can be run from a container anywhere e.g. cloud. This possible because the following nature of springboot
small footprint
standalone services
easier to launch from a container, each service can be in its own container (like docker)
easy to configure and deploy completely from a script. Good for auto-scaling and deploying in the cloud.
In active development,spring boot has the advantage of leave the complex xml file configure.
1.Embedded tomcat discard the web.xml configuration;
2.spring-boot security discard the applicationcontext-security.xml configuration;
3.spring-boot webservice discard the applicationcontext-ws.xml configuration;
4.spring-boot mvc discard the applicationcontext.xml configuration;
5.spring-boot datasource(both Relational Database and nosql Database) discard the applicationcontext.xml configuration,even if more than one datasource.
Discard this configuration file easy our development and improve the efficiency.
I am currently using Spring 2 + Hibernate 3.
Question 1: What is the good reason to use hibernate framework within Spring's IoC?
Question 2: Why not separate hibernate framework from Spring's IoC framework?
Question 3: For those who experienced using hibernate in Spring 3, is there any pain? (I noted that Spring 3 has much lesser configuration)
The reason why I ask this question is that I think using hibernate within Spring's IoC caused hibernate to be tightly coupled with Spring and caused the configuration file to be much complicated. Please enlighten me.
Thanks to #Wand Maker.
I have found the answer I need in the link provided: http://static.springsource.org/spring/docs/3.0.x/reference/orm.html at the 13.3 Hibernate portion which explains the different ways to implement DAO using spring hibernate.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am striving to know the difference between Java EE and Spring Framework. Could anyone please help me on this.
Java EE is an standard, official, specification for a full featured Enterprise Application Framework stack. Includes stuff like Object-Relational Mapping, Security, Web Applications, database connectivity, transactions...
On top of Java EE specifications there are JavaEE implementations/application servers like: JBoss, Glassfish, WebSphere, Weblogic.
Spring on the other hand, is a framework doing lots of the stuff on the Java EE specifications, but in its own form. They don't follow Java EE specifications and APIs for that. But they do include a Web Framework, transaction management, security and several other solutions Java EE offers.
Java EE:
Java EE industry approved standard API based framework
It is predominantly based on annotations and CDI
JFC MVC framework for web development
JPA specification to process DB operation
JTA API with implementation
EJB container and POJO based implementation
Oracle license
Spring:
Based on IOC and AOP
Based on XML configuration (now they are leveraging annotation)
Uses Spring DAO framework (based on Template design pattern) to connect to database
Provides abstraction layer to support various JTA implementation vendor
Integrates with various Java vendors to support different capabilities such as struts etc
Provides an end-to-end platform to build web application achieving loose coupling using DI and AOP
Open source license
Java EE:
A Sun/Oracle standard that app server vendors conform to
Based on Enterprise Java Beans
Implemented by many vendors: BEA/Oracle, WebSphere, JBOSS, Glassfish, etc.
Spring:
Not a standard; it's the brainchild of Rod Johnson and implemented by Spring/VMWare.
Not based on Enterprise Java Beans; it's a POJO model. Can manage EJBs if you wish to use them, but not required.
Not implemented by any vendor other than Spring.
EJB 3.1 has taken a great deal from Spring. Now it includes dependency injection, a form of aspects, and JPA. EJB 3.1 is much closer to Spring than EJB 2.0 was.
I provided an overview of Java EE here Frameworks for Layering reusable Architectures
This also contains a small comparison with Spring, which might be relevant for this question.