Bad Blog Posts

Image courtesy of Master isolated images / FreeDigitalPhotos.net

I spent a lot of time on my On JPA blog post, so it's hard for me to admit this but after some time went by and I read it again I realized it's bad. The information in the post is valid and correct however the post itself is still bad. To understand why that post was bad you have to understand why I decided to write on a blog in the first place.

The Reason(s)
I have two reasons. Firstly I want to improve my communication skills, I want to be able to get my point across accurately and effectively. Secondly I want to make other peoples lives easier, now that I have started to grasp the basics of what it means to be a developer (although I still have a long way to go) I hope that in some way I can make this awesome journey easier for someone else.

The Bad
So why do I consider my On JPA post bad? JPA is a huge concept the entire JPA specification should not be explained in one blog post. Well at least not by someone who is not a master at it. I understand JPA, I've worked with it a lot I am not a master at it (yet). So I tried to cover a topic that entire books are dedicated to in a +- 800 word blog post. Perhaps if I had a few more years experience with JPA and with writting I would have been able to pull it off at my current level I did not do JPA enough justice. So instead of a high level overview of what JPA is about there was a somewhat chaotic post on JPA at some places on a high level and at other places focused on the details.

The Good
There was something good that came out of this, I learnt how not to do blog post (yet). I think for now, until my writing skills level up a bit I will stick to writing blog posts on more focused topics, so instead of doing a high level overview on JPA I will instead do multiple, detailed posts focusing on the different aspects of JPA with maybe a small high level section where I explain where this specific element fits into the big picture.

The Conclusion
I think the reason I attempted to do such an ambitious post is because that is the way I prefer to learn concepts, I try and first understand something on a high level; where does it fit in, what has it been designed to do, what specific problem does it solve well etc. and then I start to get into the details. It always frustrated me when blog posts focused on one or two specific details and didn't explain the high level ideas and concepts, but now I understand why, it is difficult to do this correctly/well and it takes years of practice.

Not Good Enough
I can hear what you are thinking, this is not good enough, we need to understand what the high level concepts are, otherwise we will get stuck at every small issue. Well I agree with you. One day I hope to be able to effectively and accurately write about ideas and concepts, when that day comes I will gladly re-write my On JPA post. For now I would suggest that you read books on the concepts. I can highly recommend EJB 3.0 in Action this book covers JPA very well. I see the 3.1 in Action is going to be released soon, the "In Action" books have always been great so maybe it's better to wait until that one is out, although Entity Beans are deprecated in EJB 3.1 so there might not be a section on JPA.

On Procrastination

I'll write this one some other time.

On JPA

Image NOT related :)

NOTE: Feel Free to read this post, however read this first

If you have ever done any amount of Java EE development you have probably come across JPA (The Java Persistance API) a few times. In this article I will write a high level overview on JPA and what tools the API provides.

JPA consists of three main areas of functionality: Object Relational Mapping (ORM), The Entitiy Manager and the Query Interface (JPQL and native queries). Each of these sections deserves an entire post on it's own, for now I will only be providing an overview and as I get time I will write the more detailed posts.

1. Object Relational Mapping (ORM)
On a high level ORM is a way of working with objects in your program that represent data inside your database. The beauty of this is that developers are abstracted from the database level and can work with what they know best, objects. The only difficulty is the initial work required to map your Java Entities to your database tables, columns and relationships between tables (This step is very difficult because doing this incorrectly can create massive performance issues, consider yourself warned). This mapping is done using annotations. There is a lot to ORM, in this post I will only cover the basics.

These are the most frequently used annotations in ORM, learn them well:

Class Level
@Entity - Marks this class as an Entity.

Field Level
@Id - Marks a specific column as the Identifier.
@Column - Marks a variable as a column in your database, most frequently used when your Java instance variable names don't match your column names, along with the
@Basic - Mostly

Field Level: Relationships
@OneToOne - Marks a typical One to One relationship.
@OneToMany - Marks a typical One to Many relationship.
@ManyToOne - Marks a typical Many to One relationship.
@ManyToMany - Marks a Many to Many relationship.


Using those annotations you should be able to map your classes to your tables pretty easily, doing this efficiently however takes some experience, don't get discouraged. There are other things I would like to talk about, like JPA Entity LifeCycle Listeners, mapping Compound Keys and Inheritance, but that will have to wait for another time.

One final thing on ORM, I would highly recommend you read up on Domain Modeling. This knowledge will make you a better/more rounded developer, not only when working with JPA but overall.

2. The Entitiy Manager (EM)
This is the workhorse of JPA, on a high level the entity manager is used for the CRUD operations in your application. The EM also manages your entities at long as those enties are within scope of the EM. Management of entities and the two persistance contexts (Transaction-scoped Persistence context and Extended Persistence context) will be covered in the detailed article but if you really can't wait feel free to read up on them. :)

JPA can be used outside of a container, because of this there are two ways for an EM to be created and managed. The EM can be container managed or application managed. If you really can't use a container then you can create a EnityManager using an EntityFactory. I won't be covering application managed EMs but it's useful to know you can use JPA when a container is not available.

Using a container you can inject an EM into your bean with the @PersistenceContext annotation once you have access to the EM the following methods should interest you most:

EntityManager methods:
find: look up provided entity by pk
merge: updates an entity to the database (almost like a database UPDATE statement)
persist: saves a new entity to the database (almost like a database INSERT statement)
remove: deletes provided entity from the database

The EM has other interesting methods like clear and flush but I encourage you to look them up yourself. I am going to cover some more EM methods in the next section.

3. Query Interface
I covered the find method in the entity manager but that method is pretty one dimensional, it's not often that you lookup data only on the primary key. JPA therefore provides us with another useful object, Query. You create a Query object using your EM and since I'm sure that you read the Java docs on EM I provided earlier you'll know that I am talking about createNamedQuery, createNativeQuery and createQuery methods.

Let me speak about Dynamic Queries and Named Queries quickly. A Dynamic Query is created as part of your createQuery method you type the JPQL or native SQL as part of the method invocation so for example em.createQuery("Select c from Customer"); or em.createNativeQuery("Select * from Customer"); Named Queries on the other hand are defined in the Enity class itself (using the @NamedQuery annotation) and are available everywhere that has access to that Entity. Good candidates for Named Queries are queries that will be used by different parts of your application.

Now for Native Queries and JPQL Queries (Java Persistence Query Language), JPA allows you to create a Query object by writing the native SQL of your DBMS provider. This is discouraged as one of the big benefits of JPA is that is allows you to swap out DBMS providers with little to no code changes, using native SQL in your application will greatly limit this ability. Rather write JPQL, this is a more generic Query Language that your persistence provider then translates to native sql.

Using the Query Interface you can retrieve data from your database based on a multitude of different conditions. If you are going to be working in JPA for a significant amount of time I suggest you learn JPQL well.

Final Word Before The Conclusion
There is a bit of confusion about the difference between JPA, Hibernate and Persistence Providers so let me see if I can clear it up a bit. JPA is the specification that has been defined by the Java EE guys, this is basically a document that tells application servers (or in this case Persistence Providers) what they have to do to be considered compliant. Application Servers use what is termed as Persistence Providers that implement the JPA specification, although persistence providers can and do exist outside of the container. Finally what is Hibernate, well in the beginning the JPA was pretty cumbersome to use (or so I've heard I was lucky that I only started developing when EJB 3.0 and JPA 2.0 was available) and the smart people at Hibernate saw an opportunity to do a better job than the JPA was doing and that's when Hibernate came into existence. I hope that clears things up a bit.

Conclusion
This article got a lot bigger than I expected, and there are lots of interesting topics that I did not cover, but I have taken note of them and will do so when I have the time. Overall JPA is a really cool API and it provides lots of powerful tools for the developer to use, if you are looking to write an application with database interactions I would highly recommend JPA, but be a word of warning JPA can cause performance issues if you don't know how to use it correctly so my suggestion would be to first research the topic and maybe even read a few chapters on a good JPA book.

On Technology Choices

The Trees of Choice

In the Information world there are lot of different ways of dealing with obstacles, choice is a good thing... well mostly. The issue with lots of choices is that you get lots of different opinions from lots of different people. The best piece of advice I can give is to remember that _almost_ all technologies have their place, however their implementations depend on The Situation. Be wary of people who advise one technology or approach across all or even most, situations. Their intentions might be good but they are _probably_ wrong more often than they think.

No Silver bullets
There are no silver bullets in technology. There is no single unifying technology or software or approach that will make your development three times faster and completely bug free, if someone claims that this I suggest you read about snake oil salesmen. There are technologies and approaches that are more appropriate in different circumstances for example if you are writing an application that allows other companies servers to connect to your servers and request data or do bank account validations, I would strongly recommend using web services for that. Also depending on your situation you might want to go with SOAP web services or use the RESTful style. That however does not mean that web services are automatically the best choice when it comes to servers speaking to each other, depending on your situation you might want to use FTP file drops or socket connections.

Solving Technology Choice Problems
Often the solution to a technology choice problem is clear, there is an approach or technology that is superior, you have done something similar a bunch of times and you know where the hidden traps are. You know the strengths and weaknesses of your approach and you know that for this problem they fit perfectly. That's great I would still recommend a minute or two of quiet contemplation to figure out if you are not missing something and if you are happy then get it done.

What happens when you encounter a new type of problem? As a side note, with technology and approaches changing so frequently I would suggest that you do this occasionally with problems you have solved dozens of times, this will just keep you on your toes and make sure your approach is _still_ the best one.

Four Step Choice Program
Step 1
Make sure you truly understand the problem, this seems like an obvious step but generally people tend to skip over it because they are excited to get their hands dirty. Trust me I know the feeling. I would still suggest that you spend some time just thinking about the problem, understanding what's at your problems core. What are you required to do so that the problem goes away? Do you need security? High availability? A database?

Step 2
Make sure you understand your constraints. There is a saying I have heard often, "Everything is possible given enough time and money". Unfortunately we rarely have enough time and _never_ enough money. In the real world we work with constraints, all the time. Only have java skills? This needed to be done two weeks ago? The servers will only arrive in three weeks? I tend to like constraints and that's why I think about them second. Understanding your constraints will save you a significant amount of time, because if I know that we only have java skills available for this task I won't bother looking at approaches that require C++. Why I like constraints is a topic for another time.

Step 3
With your problem well defined and your constraints taken into account your next step is to do research. Even though your problem might feel unique I would suggest researching ways that other people have solved similar problems (and you should not have any issues finding similar problems since you did NOT skip step 1 and you truly understand the core of your problem).

Step 4
After you have researched similar solutions to your problems I would suggest that you start planning how you are going to solve your problem. What approaches are you going to take? what technology stack does your problem need? How much coffee will be needed to implement? What infrastructure do you need?

After word
Working in technology is awesome, there are so many problems to fix, so many different ways to do things you should never be bored, keep your ear to the ground pay attention to what people around you say and do. Most importantly keep learning, keep growing. There are still things I would like to write about on technology choices, I would also like to explore the steps above in greater details. However that will have to wait for another day.