Some time ago, we had a look at the mocking framework Mockito. Today I want to introduce the competitor JMockit and try to answer the question why and when to use one framework over the other.
Java, Web and Mobile
Author: Andreas Günzel
Java EE7 introduced JSON-P, which is supposed to standardize processing and parsing of JSON. This year, EE8 now brings ‘Java API for JSON Binding’ (JSON-B). Time for a closer look.
Using an object-relational mapping framework like Hibernate disburdens developers from creating complex DDL scripts to setup an application’s database schema. However, in real life such scripts are still needed – at least for the DBA who forbids applications to alter database objects. This post shows how to easily generate the database schema DDL script without typing an SQL commands.
Unit testing is essential to produce good software. As a unit test is intended to cover only a very small piece of code we need to mock out other components. This post provides an introduction into the widely used mocking framework Mockito.
Long running transactions might be killed by the App Server’s Transaction Reaper. I have implemented a litte helper to programmatic handle such kinds of exceptions.
For long running transactions sometimes we wish to commit a kind of intermediate result to the database. This sounds pretty simple – however, if we do not want to commit the current transaction, you may run into deadlock situations. In my current project I implemented a nice solution using JPA and EJB.
Altering a MongoDB index cannot be done out-of-the-box. If you are tired of dropping and creating indices by hand, have a look at this little hack.
Recently I used hazelcast in several projects. Especially in an Application Server environment using the hazelcast JCA connector it is pretty easy to use hazelcast with only a few lines of code. Unfortunately, Hazelcast.getAllHazelcastInstances() returns an empty set in unit tests. So, what we need to do is to mock our HazelcastFactory somehow.
When using Hibernate as JPA provider you need to tell the application which database vendor you are using. The classic approach is to set the property “hibernate.dialect”. This works in most cases. However, I often have to cope with different database vendors serving the same datasource – depending on the current environment. A solution to this problem is to use a DialectResolver that dynamically detects the needed Hibernate dialect to talk to the database.