Java Lobby Announcements

Subscribe to Java Lobby Announcements feed
Recent posts in Java on
Updated: 5 hours 14 min ago

Titanium Armor: Recovering From Various Disasters

Tue, 2017-03-07 10:01

Git is an advanced tool. It features a philosophy that is dear to my heart: to treat developers as smart and responsible folks. This means that a lot of power is at your fingertips. The power to also shoot yourself in the foot — arguably with a titanium vest on — but shoot yourself nonetheless.

The topic of this post is to confirm what my colleague Charles O'Farrell said very well in the ever popular "Why Git?" article some time ago:

Categories: Java

Clean Architecture Is Screaming

Tue, 2017-03-07 07:01

Welcome to the fifth installment of little architecture series! So far we have covered layers, hexagons, onions, and features. Today, we’ll look at a close friend of all four – Uncle Bob’s Clean Architecture, initially introduced here.

What Is Clean Architecture?

Clean Architecture builds upon the previously introduced four concepts and aligns the project with best practices like the Dependency Inversion Principle or Use Cases. It also aims for a maximum independence of any frameworks or tools that might stay in the way of application’s testability or their replacement.

Categories: Java

Ratpacked: Using Spring Cloud Contract as Client

Mon, 2017-03-06 23:01

In a previous post, we learned about Spring Cloud Contract. We saw how we can use contracts to implement the server side of the contract. But Spring Cloud Contract also creates a stub based on the contract. The stub server is implemented with Wiremock and Spring Boot. The server can match incoming requests with the contracts and send back the response as defined in the contract. Let's write an application that invokes HTTP requests on the server application we wrote before. In the tests that we write for this client application, we use the stub that is generated by Spring Cloud Contract. We know the stub is following the contract of the actual server.

First, we create the stub in our server project with the Gradle task verifierStubsJar. The tests in the client application need this stub and will fetch it as a dependency from a Maven repository or the local Maven repository. For our example, we use the local Maven repository. We add the maven-publish plugin to the server project and run the task publishToMavenLocal.

Categories: Java

Application Modernization/Migration: What, Why, When, and How?

Mon, 2017-03-06 19:01

I have been working on modernizing and migrating several different types of Java/JEE applications (yes, I mean ‘different’ types) over the last few years and wanted to share my experiences in the hopes that it might help someone out there trying to do the same. I plan to write a series of articles, so please watch this space for more.

The technology landscape is ever-changing, and business applications almost always have a hard time keeping up with it due to various limitations. Application modernization is an area of technology consulting that is catching up so fast that several large consulting organizations have realized the need to create a separate consulting practice with qualified staff to be able to meet the growing demand to migrate applications to newer technology platforms.

Categories: Java

Using sun.misc.Unsafe in Java 9

Mon, 2017-03-06 13:01

The Java 9 EA version is out and we can now see how to use sun.misc.Unsafe. I led the public campaign to retain access to it in Java 9, which was ultimately successful, leading to the amendments to JEP 260.

So, how did things end up?

Categories: Java

Spring Boot: Building Restful Web Services With Jersey

Mon, 2017-03-06 10:01

In the previous posts, we have created a Spring Boot Quick Startcustomized our embedded server and properties, and run specific code after a Spring Boot application starts.

Now, in this post, we will create Restful web services with Jersey, and deployed on Undertow, as a Spring Boot Application.

Categories: Java

Java's Finalizer Is Still There

Mon, 2017-03-06 07:01

When I was first transitioning from C++ to Java, I remember being told repeatedly and frequently reading that one should not treat the Java finalizer like C++ destructors and should not count on them. The frequency and insistent nature of this advice had such an effect on me that I cannot recall the last time I wrote a finalize() method, and I cannot recall ever having written one in all the years I've written, read, reviewed, maintained, modified, and debugged Java code. Until recently, however, the effects of finalize() were not something I thought much about, probably because I have not used finalize(). But a recent experience with finalize() has moved the effects of Java finalizers from an "academic exercise" to a real issue "in the wild."

The method-level Javadoc document comment for Object.finalize() provides some interesting details on the Java finalizer. It begins by providing an overall description of the method, "Called by the garbage collector on an object when garbage collection determines that there are no more references to the object. A subclass overrides the finalize method to dispose of system resources or to perform other cleanup." Another portion of this Javadoc comment warns of a couple issues commonly associated with use of Java finalizers: "The Java programming language does not guarantee which thread will invoke the finalize method for any given object. It is guaranteed, however, that the thread that invokes finalize will not be holding any user-visible synchronization locks when finalize is invoked. If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates."

Categories: Java