An incremental software development process requires an incremental database migration strategy.
I remember working on an enterprise application where the hibernate.hbm2ddl.auto was the default data migration tool.
Updating the production environment required intensive preparation and the migration scripts were only created on-the-spot. An unforeseen error could have led production data corruption.
This post covers some basics of JVM memory structure and quickly peeks into PermGen to find out where it has disappeared since advent of Java SE 8
The JVM is just another process running on your system and the magic begins with the java command. Like any OS process, it needs memory for its run time operations. Remember – the JVM itself is a software abstraction of a hardware on top of which Java programs run and boast of OS independence and WORA (write once run anywhere)
I once visited a team that had fifteen layers in their code. That is: If you wanted to display some data in the database in a web page, that data passed through 15 classes in the application. What did these layers do? Oh, nothing much. They just copied data from one object to the next. Or sometimes the “access object layer” would perform a check that objects were valid. Or perhaps the check would be done in the “boundary object layer”. It varied, depending on which part of the application you looked.
Java 8 comes with a new Optional type, similar to what is available in other languages. This post will go over how this new type is meant to be used, namely what is it’s main use case.
The terms “modularity” and “microservices architecture” pop up quite often these days in context of building scalable, reliable distributed systems. Java platform itself is known to be weak with regards to modularity (Java 9 is going to address that by delivering project Jigsaw), giving a chance to frameworks like OSGi and JBoss Modules to emerge.
When I first heard about OSGi back in 2007, I was truly excited about all those advantages Java applications might benefit of by being built on top of it. But very quickly the frustration took place instead of excitement: no tooling support, very limited set of compatible libraries and frameworks, quite unstable and hard to troubleshoot runtime. Clearly, it was not ready to be used by average Java developer and as such, I had to put it on the shelf. With years, OSGi has matured a lot and gained a widespread community support.
