Develop Reference

JPA Entity Manager why to use?

I've got involved in a project with entity manager in it. It's a bit unclear why should one use it. We have databases to store information in if we don't we can use classes to store informations in without the entity manager. The question is is it worth the effort to learn? Is it a widely used tool?
I know it's a bit opinion based but I'm interested in the facts mainly. But usually others experience shows how good a tool is.

Yes, JPA and Hibernate are widely used. Their benefits are the speed of the development (especially on the early stages of the project), but since it's a very complicated technology not everyone gets to use it effectively.
Ultimately knowing JDBC and databases is much more important than knowing ORMs. Mostly because everything else related to DBs in Java (including ORMs) is based on JDBC. But also if you need to write a very performant code - JDBC could be the right level of abstraction for you.
If you want to learn ORMs I'd advise to start with the book POJOs In Action - it explains the fundamental principles behind these frameworks. And after that check out Java Persistence with Hibernate - this one is more technically involved and describes all sorts of features in Hibernate.
Apart from the fully-featured ORMs there are lighter technologies that ease up the low-level JDBC burden: jOOQ, Spring JDBC, MyBatis.

How mature is Ebean or Siena? [closed]

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 9 years ago.
Improve this question
In the last time I heard a lot of complaining about Hibernate. And indeed I have some painful experiences with Hibernate too. So I read about Ebean and Siena.
Both have interesting approaches. Unfortunately, database access layers are very easy to write, but if your project grows and you have to handle great database-tables, you know if they are good or not. So it's really difficult to evaluate such a tool. Hibernate is well known and you could be sure that you can solve your problem with it. Sometime you need to learn a lot, but you can solve it.
How is it with Ebean? Are there any real world applications? Which databases are supported? Is it reliable?
After searching a little bit more I see that there are a lot more ORM-frameworks, so is there at least one reliable one?

Rob (Ebean Committer) here.
Ebean is about 4+ years old now. I would say it is fairly mature now. The supported DB's include Oracle, MySql, Postgres, H2 and SQL Server (and recently SQLite). Ebean is doing stuff that other ORM's are not such as Autofetch (automatic query tuning) so I'm not how that fit's into a 'maturity rating'. IMO the Ebean community is relatively small though so you probably need to hit the Ebean google group to engage them.
Any real world applications? Yes, but you are best to ask the Ebean community about that really. Certainly there is good support for batch processing (batch size, turn of cascading persist for a transaction etc) and large query support that I don't see in JPA etc (you might get something similar with Hibernate's Sessionless support).
Hopefully this might answer some small parts of your question anyway.
Cheers, Rob.

I'm currently a developer of Siena but not since very long. Let me explain why I became a developer on this project?
I went to Siena because I wanted to use Play+GAE and Siena appeared to be a good start for GAE DB and I really wanted to avoid JDO/JPA.
Then, I began to really appreciate Siena for its straightforward, light and easy approach and so simple APIs. It doesn't pretend to be the all-in-one abstraction layer like JDO and the greatest standard DB API like JPA. It really made me think of DB APIs from Python/Ruby and it really fits my point of view: I want a simple DB API which allows me to solve the great majority of my problems and when I have a more complex problem, I will use the lower layer APIs but certainly not an abstraction layer such as hibernate.
The possibility to make my code work on GAE DB or JDBC was also a good aspect. Once again, Siena doesn't pretend to provide exactly the same things in both worlds because SQL and NoSQL are not really compatible (but ORM is neither really compliant to SQL model :) ).
But once again, it is quite practical to be able to rely on the same APIs in several DBs.
Finally, the library is ONE jar and you don't have to retrieve the whole universe to use it.
So, I became progressively a committer on Siena because I wanted to take part of this nice little adventure.
Now siena team is working on a new version keeping the same simple APIs, bringing new interesting features and really improving all the backend code to make it even easier to extend for new DB support.
Siena is a pragmatic API driven by user experiences and that's why I like it ;)
Pascal

We've had really great experience with MyBatis, which is not an ORM per se, but another class of persistence manager, an SQL Mapper. Using it you start with SQL statements and direct it on how to map result rows into POJOs. It's conceptually easy to understand and tune with not much magic going on inside. It's ideal if you are comfortable with SQL or need to work with an established schema.

Besides Ebean and Siena:
You can try JIRM which is focused on CRUDing immutable objects (yes I'm the author).
There is also jOOQ and Joist.
I feel that JIRM minimizes the number of DTO's because the domain objects are immutable and do not inherit, implement and/or are not "enhanced/instrumented". Such is not the same with Siena and Ebean.
Also because the objects are Immutable there is more of a focus on per column updating instead of the whole object which makes more sense given today's AJAX interfaces (compared to the old POST the whole bean model).

What about using EB3, with for instance JBoss (www.jboss.org)?

How to design Java application? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
What are the general guidelines and best practices to keep in mind while designing Java application [Simple console apps to J2EE apps]?.
Hi
I recently completed Java programming tutorial from Sun
and practised core java (I have previous programming experience).
Now I understand the basics of Inheritance, Abstraction , Polymorphism,Encapsulation
Now i am writing Java code without much difficulty, but am not sure of application design.
This is my main problem: "DESIGNING" the application.
Say if i have given a task to create an application in Java,
What should I start up with? How to think about?
Any formal/informal guidelines I should follow while developing class hierarchies? I am really confused (abstract class or interface or sub class..?).
Should I start by model everything, before writing code?
It would be very useful for people like me to have a SET OF GENERAL GUIDELINES/BEST PRACTICES, which we can follow while start developing a new java application.
Please provide me some guidelines/thoughts/books/resources/tools I should read or Use
Thanks in advance
Scott

It is difficult to give really general advice as there are so many different Java apps on different domains. However, one absolutely recommended book is Domain Driven Design by Eric Evans. See also Wikipedia for a short intro on it.
General advice:
don't try to design everything up front - do a reasonably good design which enables you to start coding, then refactor as your understanding of the problem domain and the implementation deepens
try to divide difficult problems into smaller parts/steps/modules which you can tackle one by one
try to think in terms of objects with well defined responsibilities, which (more or less) model the problem domain and cooperate to solve a problem / handle a task
becoming good at design requires practice, first and foremost; don't be afraid to make mistakes. However, when you do, analyze them and learn from them as much as you can
learn design patterns, but don't be overzealous - use them only when they really solve a problem and make your code cleaner

In my opinion it all boils down to meeting the below
easy to understand
easy to maintain and evolve
multiple developers able to
contribute to the project (mostly in
parallel)
To achieve the above there are certain guidelines and principles that are suggested by experts based on experience which are
Follow layered architecture
Follow the SOLID principles within and across layers. All the design patterns are one way or the other help achieve these principles only. SRP: Single Responsibility Principle, OCP: Open Closed Principle, LSP: Liskov Substitution Principle, ISP: Interface Segregation Principle, DIP: Dependency Inversion Principle
DRY and KISS principles
These guidelines and principles are independent of any programming paradigm or language. However, OOP languages help implement these easier.

There are various paradigms (very often 3 letters acronyms) :
DDD : Domain Driven Design
SDD : Serviice Driven Design
MDA : Model Driven Architecture (code and architecture is extracted from the UML model)
TDD : Test Driven Development (validation tests are implemented before the application)
With theses key-words, you'll find a lot of informations on the web.
In J2EE, I would say that the SDD is the most used (it is now very "normalized", even if I'm not sure it is the best solution) : service (software "intelligence") > domain (bean objects used for persistance) > DAO (persistance).
Now DDD is becoming more and more used : the conception is refocused on domain objects, which are taking the "software intelligence" layer.

I really advice you to take a look at GRASP principles, it gives you a good design basis skills.

Welcome to stack overflow.
If you are good with Java, read Head First Design Patterns.
and
Head First Object-Oriented analysis and design - er, may be in reverse order :)

Start by looking up UML Class diagrams that will get the ball rolling in the right direction, then take a look at Gang of Four design patterns. That is an excellent first step.
http://en.wikipedia.org/wiki/Class_diagram
http://en.wikipedia.org/wiki/Design_Patterns
Lastly, I would pour over good open source code like the Spring Framework
http://www.springsource.org/

I'd recommend emergent design with TDD.
I think there is nothing specific to Java design : if you already know about Object Design, you're ready to go !

Do not start coding immediately without having any design. But this does not mean that you should design all before coding. Because from my previous experiences, I could not have any design which does not need corrections. Especially if you are new in a programming language your design will change according to the features of the language you are using and the libraries available. My advice is to have a general design which is based on the most important aspects of object oriented design such as inheritance, polymorphism, encapsulation etc. Starting from this general design and the needs you encounter while programming, revise your design accordingly.
As much as you get experienced in the language, your first general design will fit in a much more efficient way to your program.
Although most of the people say that one object oriented design should be able to be written in any object oriented language, it is not that easy to have a very good generic design like that. To be more realistic, disregarding the language that is used for implementing a particular design is not a good way as far as I am concerned.

Well odds are what you'll be doing has already been done before - at least something similar. Luckily, there's lots of open-source stuff nowadays. So if you really have no idea, one thing you can do is download several open-source applications that do the same thing and study them. It should give you a good start.

Is cayenne good choice for my requirement? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We are evaluating ORM solutions for my project that has tight coupling between business layer and datalayer(JDBC). I started doing a PoC with Cayenne. My requirement goes like this
a) Already there exists database schema
b) Schema is very granular level. I.e. real time java objects are only derived by combining tables.
c) At the moment I just want to perform read operation (to be precise filter and sort on a list by inputing criteria)
Till now, the observations I have made with Cayenne are
1) Table and Object are tightly coupled. Modeler is not allowing to create java object without associated table.
2) I could not find easy way to map output of a named query to a java object so that I get list in a way application needs.
3) Also I am not sure Expressions work with named queries.
I would like to know your inputs on best choice for my requirement?
Thank you in advance.

If I had to choose an ORM tool or a JPA provider, it wouldn't be Cayenne simply because it doesn't seem to be widely used so the community behind it isn't very large and this is a concern. There is thus no need to discuss technical points, things like Cayenne 2.0 is intrusive, you have to implement an interface or to extend a superclass (Cayenne 3.0 has POJO support but is still in beta, after more than 2 years...). No, really, I don't see any good reason to not pick Hibernate, the defacto standard, if you need an ORM tool.
But...
Given your requirements, an ORM might actually not be the best choice, mosty because of b) so I would consider using iBatis (which is not an O/R mapper, it's a data mapper) instead.

Cayenne has a lot of very good features, and on the plus side you have a number of open source tools to use in your project. Hibernate suits some people and Cayenne others. I know that for more own use, Cayenne was far superior to Hibernate due mainly to these factors:
a very helpful user community. Hibernate's can be a little abrasive.
a very robust code base with a large number of tests which provide large code coverage
ROP (three tier) support. This in itself is a huge feature if you need it.
good inheritance support
Cayenne modeler
Yes, the Cayenne approach is that Object Entities (the Java clients which map to the db) extend a superclass. That gives you some distinct advantages over Hibernate (Cayenne controls the entire object lifecycle) and introduces complexities for some people.
I also find the way Cayenne manages the Context (a group of objects and changes which will later be committed together) to be very intuitive.
As for your questions:
1) Cayenne definitely lets you create Object Entities without a one-to-one map to a table. We do it all the time, particularly when modelling inheritance.
2) SQLTemplate will let you get at named queries, but you'll find that most ORMs will steer you away from this approach since you are working against the natural way an ORM works to build queries directly in the database. The point is to abstract the database whenever possible.
3) SQLTemplate will let you do just about anything you want. But again, adopting an ORM is about a strategy for writing your application, not just a light wrapper for JDBC. I believe the benefits are huge and our projects have benefitted, but it depends on your goals.

Agreed, Cayenne has a lot of very good features. But if your project need some work done with inheritance(you didn't mention it), definitively Cayenne is not a option. It doesn't do a "good inheritance support":
Horizontal inheritance - https://issues.apache.org/jira/browse/CAY-795 -open since 30/May/07;
discussion Vertical-inheritance on http://cayenne.195.n3.nabble.com/Vertical-inheritance-td827636.html since 18/May/2010
I often use it on my personal projects and the gain in productivity is excellent.

Questions to Determine Spring / Spring Security, etc Knowledge

I requested Spring / Spring Security, etc training at work, and the bosses want to hire someone who knows Spring to come work with us as a consultant so that we'll learn Spring from a real-world perspective instead of a training perspective.
I've been tasked with coming up with questions of various difficulty to ask potential hires in order to ascertain their Spring ability. The problem is that I don't fully understand Spring yet (hence the training request).
What questions would you ask someone to determine their Spring ability, and what level of knowledge would someone have to have of Spring to answer them? (I need 2 "easy" questions, 2 "medium" questions and 2 "hard" questions, specifically, but I'll take anything you guys have).

I suggest to hire someone who is a 'SpringSource Certified Spring Professional' if you can do that or at least someone who has completed the 'Core Spring' course.
As for the questions, there are some easy/medium sample questions (with answers) on the certificate page.
During the interview I would ask the candidate to explain some real-world situations where, how and why he/she has used Spring before.

Easy: Spring originally arose as a reaction to what technology? How does its philosophy compare?
Easy: Describe a situation where you improved a project with Spring? Which parts of Spring did you use?
Medium: Describe the facets of an application for which Spring supplies a solution. (looking for: dependency injection, transactions, distributed computing, etc)

Here an easy one : What is Dependency Injection ?