Java 8 for late-adopters - Venkat's 5 cents

Some time ago I wrote a short post regarding some Java 8 features that may be interesting for current pre-8 developers and may motivate them to switch to the latest version. It was really basic, more like teaser than tutorial.

As one of the projects I'm in is currently moving to Java 8, I recently did a presentation on the topic. During research I found out a number of great tutorials - ranging from simple introductions to deep-in-details encyclopedias. One, however, caught my eye.

Venkat's "Java 8 programming idioms" series, published here: http://blog.agiledeveloper.com/2017/09/java-8-programming-idioms-series-at-ibm.html Touches mainly functional side of the Java 8. It can particularly handy, as I see that some developers that up to date lived in an object-oriented programming world have a hard time switching to functional style of thinking. Enjoy!

[memo] hibernate's import.sql

There is a neat, heavily undocumented feature oh Hibernate - import.sql.

If Hibernate creates DB schema from scratch - "hibernate.hbm2ddl.auto" is set to either "create" or "create-drop", it will load "import.sql" file located in the root classpath. If Spring Boot is used, the property controlling the behaviour is "spring.jpa.hibernate.ddl-auto".

But why would anyone like to import some static data in a webapp? Well, for prototyping purposes for example. Or for "static" webapp mocking some external resources for integration testing. 

Continuous Integration for (non)hipsters

Continuous Integration? Soooo ooold, so ninetees. Not hot anymore, not trendy. Currently even Continuous Delivery sounds like something regular, typical, borig. Everybody does CI... or do they?

In order to answer this question, let's refer to the excellent article, published by Martin Fowler here. Headline states:

Continuous Integration is a software development practice where members of a team integrate their work frequently (...). Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

That's it.
Code (yes, this includes tests!)
Commit.
Pull/push (integrate).
Let something (a CI server for instance) run tests and confirm that everything is in order

Four easy steps. However, the devil is in the detail.

First of all, the steps should be executed at least once a day, preferably multiple times a day by each team member. This way, any integration issues will be discovered on the spot. If your team has a habit of keeping private branches for a long time, without source integration and pushes (triggering a full CI build), well, you're not doing CI! If you use feature branches, which are a good thing, keep them public, so that CI server can watch them during development time.

Second of all, tests are the cornerstone of CI. Usually not all tests are run during build - in order to make it faster, only quick, small unit ones. If project build isn't fast, developers won't build before pushing changes (we're all always super busy, aren't we?). Therefore all expensive tests - especially integration ones - should be left for CI server. It's a general rule for a bigger builds. This way if an issue fits into this 1% not covered by unit tests, it should be found by the end of the day. By the way it's really a good habit to have a blame mails enabled in the CI server. The name is a bit misleading - it's not about the blame, it's all about fixing broken build (or bad tests!) as soon as possible.

All of what was above can be found in the aforementioned Martin Fowler's article - in a more elaborate way. Yes, it's a quite old one, but still very, very relevant.

[memo] purging broken JARs from Maven repository

Ever encountered dreaded "java.util.zip.ZipException: invalid LOC header (bad signature)" while building a Maven project? If yes, it means that Maven (somehow) downloaded a broken JAR into your repository. There is not much that can be done besides purging all of the "broken" JARs from the repository.

Two options are possible:

• delete whole Maven repository - which means downloading all of the JARs, of all projects (possibly few gigs) again (!!)
• delete only offending JARs - list can be obtained for example by issuing following command:

find  /home/me/.m2/repository/ -name "*jar" | xargs -L 1 zip -T | grep error | grep invalid

 Both options, well, suck :-) Fortunately there is a way to purge all of the JARs from local repository that pertain to only one project. It's provided by the dependency Maven plugin. Just issue

mvn dependency:purge-local-repository

and it's done. NEAT!

Hazelcast - CLI access

Ever wondered how to quickly take a peek into your Hazelcast structures, for example on a UAT / CIT environment? Look no further! :-) I've recently had a similar task. Debugging an issue on a test environment I reckoned it might be caused by a faulty data in the Hazelcast cluster. Fortunately we can use what comes with a Java application using Hazelcast (in a client mode) - class ClientTestApp.

First of all we're going to need two Hazelcast JARs (here - version 3.2.5):

• hazelcast-client-3.2.5.jar
• hazelcast-3.2.5.jar

Both JARs should be copied into empty directory, let's call it "lib" for this demo purposes. Next, a shell script used to run the test app needs to be created:


In order to have the client connect with your cluster, a configuration needs to be provided as well. The file needs to be named hazelcast-client.xml and reside in the same directory as the run.sh script. Sample content looks as follows:

After running the client, you should get a Hazelcast console able to query / manage the cluster. Full manual of the CLI is here: http://docs.hazelcast.org/docs/2.3/manual/html/ch17s09.html

Enjoy querying your data!