Java 9 - Try with Resource enhancements

Try With Resource

Introduced with Java 7, a try-with-resource provided a cleaner way to perform cleanup operations on resources. This was a very useful feature where you need not explicitly do a cleanup of resources (which implements an AutoClosable interface) but it was done automatically for us. This is critical in applications where we are dealing with resources such as Database, I/O Streams where not cleaning up the resources will be costly.

One limitation of pre-Java 9 try-with-resource was that it can perform cleanup operations only if the Resource was instantiated inside the try block.

For example (pseudo code):

// This will cleanup Resource

try(Resource myResource = new Resource()) {

     resource.doSomething();

}

// The below will not work in pre-Java 9 but works in Java 9

Resource resource = new Resource();

try(resource) {

     resource.doSomething();

}

Will the above feature  be useful or complicate things depends on how this is used. Since the resource can be created elsewhere and passed on to this method or given via Dependency Injection, closing this can create more problems (as it lives outside the try block). So, this feature has to be used with Care.

Have a look at another interesting feature of Java 9 - Private methods in interfaces.

Java 9 - Private methods in Interface

Prior to Java 8, Java Interfaces can contain method signatures but without any implementation.

In Java 8, default methods were introduced where we can add new methods and a default implementation for the same. Though it was originally intended to allow people to add new interface methods without requiring all implementations to change (by providing a default implementation), we are using default methods in many different ways which may or may not be how it was originally intended to be used. If you have multiple default method implementations in an interface, we may end up having duplicate code due to lack of private methods.

Some options available to do this 

• Another default method with common logic.
• An external class containing Utility methods.

Both cases expose the implementation details to outside classes which otherwise supposed to be a private to default methods.

In Java 9, we can now create private methods in an interface which are to be used by default methods. 

So, if we have default methods in an interface and need to share a particular logic, a private interface method would allow us to do so without exposing that private method and all its implementation details via the interface (or a Utility class).

Have a look at an interesting enhancement in Java 9 - Try-with-resource enahancement

Journey from CORBA to GraphQL

During my initial days as Software Engineer, my first exposure to client-server application was with a Java based server and a DotNet based client which used CORBA for remote communication.

RMI which is kind of predecessor of CORBA provided Java Only interfaces where as our application needed DotNet  (and Java too) which CORBA provided (had implantation in multiple languages).

Problem statement : We wanted a client server application where client can be either in Java or DotNet and server being Java.

CORBA which could solve the above problem was used and it served well during its initial days.

CORBA had some benefits (multi language support) but it lacked in few areas such as performance, clear specification and lack of complete symmetry in some field mapping. This RMI vs CORBA article provides good information and comparison on this topic.

When looking for options to replace CORBA, two options looked really attractive - REST service with JSON or API’s provided using ProtoBuf (from Google). Both were relatively new during that period and was gaining traction for their own reasons. Though we could not do much using Protocol Buffers, it is still quite popular with implementations where performance is of higher prominence. This blog has nice information on ProtoBuf. 

One more area I had a brief exposure to was SOAP based services. Schema, WSDL, tools to generate clients, contract between server and client applications - it has all good things that are needed for a client-server application. But dealing with XML based data and strong contract between client and server were some factors which made SOAP less attractive. SOAP and REST is discussed in this blog.

RESTful it was then, a very simple, HTTP based, JSON for data transfer over network and a stateless system. Looked very interesting to build our system which both java and DotNet clients can use. Converting all our entities into resources and having relationships as links providing a smooth navigation looked easily achievable. From then, I started working with different systems (due change in companies and products I worked on) where REST based services were used in different forms - some tried to be purest form, some with diverting from REST principles to have some functionalities stuffed in. Nevertheless usage of REST grew very fast and with evolution of SOA and micro services, fueled its growth further. I have used and still using REST in the services being developed where it is serving its purpose quite well.

Then came OData.

REST was good, but we wanted something more. A query type API's which gives client flexibility to add various querying capability into their service calls. Though OData does not completely adhere to original REST principles, it tried to balance contract between client-server (by providing $metadata) and fluent API's as in REST (Entity Models). OData was originally developed by Microsoft (2007) and many big players started contributing to specifications and standards. When I started working with SDL, a Java implementation of OData framework was developed for the use of our services implementation which was later open sourced. 

All was well with REST & OData except that we started having a new problem.

Problem statement: REST or OData based services makes complex client application to become chatty and also results in underfetching or over fetching of data. We want some genric way of providing API which can reduce number of calls to service and clients can ask for what they want.

Then came GraphQL.

GraphQL was developed by Facebook for internal usage and later made publicly available (2015). On very first instance, it addressed two important problems we were facing - reduce chattiness and prevent under-fetching or over-fetching of data (get only what you need). GraphQL (often confused with Graph Databases but has nothing to do with it) is a query language for API's and also provides resolving layer or ways to provide data for the query. 

REST or OData provided few of the features of GraphQL already, but GraphQL provides more elegant way of doing this. GraphQL mostly moves towards developing API's giving importance to what client need without the need for having a contract. During our initial evaluation of GraphQL, we identified potential benefits it can provide our clients. Moreover the rapid growth on the community around GraphQL makes is really interesting.

GraphQL fits well in todays application development requirement of ability to provide API's regardless of the client being used - Browser, Mobile, Tablet, etc. As an API provider, we need not worry about the type of client calling our API, but just expose types (schema) which our API will provide. Its the client implementation which queries the server to provide the data which is required and the GraphQL service provides only the data being requested. There are many articles around getting started with GraphQL and for Java, we have How to GraphQL which is great place to start with.

Overall it was an interesting journey from CORBA to GraphQL, the later being the one which looks like has a long way to go.