With the advent of Java 8, Closures and Lambdas have been added to the language. While this makes it (a lot) easier to create certain constructions (I won’t get into the details here), there are a number of downsides to it. ...
A model is a central component within any application. This model decides what your view is on the outside world. As such, it effectively makes or breaks your application (your business rules can change, but if your view on the outside world fundamentally changes, you're effectively caught with your pants down, and that's embarrassing! To be honest though, this is rarely where applications fail, because such models are often conceived with enough knowledge to do this properly. ...
Over the past 4 years, Spring took a step back and JEE got much of the spotlight in the world of Java. Something that I embraced for several reasons, but Spring wasn't actually gone, it just got slightly misplaced. ...
Lucene is the an embeddable search engine used in many (many...) Java applications. It's extremely powerful, flexible and configurable. Exactly this makes it perfect to embed. Although you have to watch closely how you use it. ...
A little background CDI has had a major influence in the Java community. It's inclusion into JEE6 has greatly improved the way of working with JEE in general, this itself caused a major leap in adoption of JEE. So far so, that it's being applied indiscriminately, something I'm not much of a fan of. For most of the web applications being built, CDI is a great tool to accelerate implementation. ...
One of the essential properties of object oriented programming is the encapsulation of an object state. The most important side effect of this encapsulation is that an objects' state is exposed through its methods. These methods allows for various guarantees, such as class invariants and method invariants. ...
Traditionally, a structure of a set of Maven projects is rather treelike. With a direct symmetrical module parent relation. Also, the parent POM then tends to hold many dependencies which are often only relevant to a subset of modules. This approach is outdated and tends to be a maintenance and development nightmare. Especially when more than one person develops on it. ...
In an earlier post about generics I described the limited impact of type erasure. Trying to describe that type erasure was more of a developer issue and less of a platform. Although I still agree with that statement, I want to show a case that adds some nuance to that statement. ...
There seem to be a significant amount of Java developers who have certain criticisms to the Java approach of implementing Generics. Though type information is sometimes well hidden, it's almost always available. This is because of the approach that Sun took when defining it. Sun decided that it was not appropriate to compile new types just because the type information itself changed. This approach differs from the C++ template approach which requires the original sources of the generic class you're using, this makes it very hard to provide a generic class in a library. ...
The Double-Checked Locking pattern used in the class loader testing example is used to lazily initialize the properties. Although there are some side notes with regard to the pattern. First and foremost, it only works for Java 1.5 and up, because of the Java memory model. Most developers shouldn't be worried with it. Quite frankly, the class loader testing example is not the most realistic example of an application for the pattern. Realistically, the best application for it is the lazy initialization of a true singleton instance, of which there are just very few. ...
