The Great Indian Developer Summit 2012, Few Interesting Things

19 th April 2012, the day started with a fresh knowledge sharing, I stepped into the IISC for The Great Indian Developer Summit, 2012. I generally sleep in seminars, but this one was little different. I got my first boost when this came from Venkat,

Yes I started taking the seminar seriously.

Refactor your Language Knowledge Portfolio – Venkat S

Refactoring again? What is there to learn more? That was my first expression. But, the presentation by Venkat changed my mind. It is not about what you learn, it is about how you learn. Programing is much like writing poems, if you are not enjoying it, nobody will enjoy it. He wrote some code (i don’t have the original code here, hence taking example of something).

public Object getInstance(String s) throws FooException {
   try {
      Class c = Class.forName(s);
      Class[] argTypes = { Integer.TYPE };
      Constructor constr = c.getConstructor(argTypes);
      Object[] args = { new Integer(0) };
      return constr.newInstance(args);
   } catch (ClassNotFoundException ex) {
      throw new FooException("class not found", ex);
   } catch (NoSuchMethodException ex) {
      throw new FooException("no such constructor", ex);
   } catch (InvocationTargetException ex) {
      throw new FooException("exception in constructor", ex);
   } catch (IllegalAccessException ex) {
      throw new FooException("can't access constructor", ex);
   } catch (InstantiationException ex) {
      throw new FooException("something bad", ex);
   }
}

How do you feel after writing this code? Venkat asked.

Audiences were like, “Umm, hmm, okkkk !!!”.

He himself replied, “I felt like having a shower after this (it was so dirty).”

What can we do to refactor the code?

In the example above, I consider the five catch statements in a row to be bad code, as they’re essentially useless, they take up a lot of space, and if I ever change FooException I might have to modify them. Instead, I recommend putting them in a method by themselves, like this:

public Object newGetInstance(String s) throws FooException {
try {
Class c = Class.forName(s);
Class[] argTypes = { Integer.TYPE };
Constructor constr = c.getConstructor(argTypes);
Object[] args = { new Integer(0) };
return constr.newInstance(args);
} catch (Exception ex) {
throwFooException(ex, "constructing new " + s);
return null;
}
}
private void throwFooException(Throwable ex1, String explain)
throws FooException {
explain = toString() + ": " + explain;
try {
throw ex1;
} catch (ClassNotFoundException ex) {
throw new FooException(explain, ex);
} catch (NoSuchMethodException ex) {
throw new FooException(explain, ex);
} catch (InvocationTargetException ex) {
ex = ex1.getTargetException();
throw new FooException(explain, ex);
} catch (IllegalAccessException ex) {
throw new FooException(explain, ex);
} catch (InstantiationException ex) {
throw new FooException(explain, ex);
} catch (Exception ex) {
throw new FooException(explain, ex);
}
}

Again for above code, I am not quoting Venkat. The session was attractive and interactive, and the Rs 10 change joke was awesome, to describe the difference between the requirement and delivery (want to know more about it? ask @venkat_s).

Java 7 : What’s in it for you?

In this seminar Venkat described the new features of JDK 7, including my favorite Garbage First Collector. Most of the features he discussed are already available on net, so I am not discussing more here.

Read about JDK 7: few links | multiple catch block

A Tale about Caching (JSR 107) and Data Grid (JSR 347) – Manik Surtani

The JSR 107 tells

Distributed caching is the tip of the spear for performance and scalability, yet Java does not have a completed standard caching mechanism yet. JSR-107, the JCache API, is being actively worked on and will be included in Java EE 7. JSR-107 has gained some notoriety over the years because it is one of the older JSRs yet has never been completed, but given the increased demand for caching, JSR-107 will finally see the light of day.

And the below directly comes from Manik (yes I am quoting here),

What’s in JSR-107?
A quick summary:

Primary interface – javax.cache.Cache – extending j.u.c.ConcurrentMap
Adds ability to register, de-register and list event listeners
Defines a CacheLoader interface for loading/storing cached data
Defines an evict(K) method, as well as the support for different eviction algorithms
Defines a ServiceLocator approach to loading the appropriate implementation at runtime
Defines a CacheManager interface to construct and retrieve Cache instances

What JSR-107 does not cover – but should be included in a Data Grid JSR
Over and above what JSR-107 proposed, I believe the following features are crucial to a useful data grid standard:

JTA interoperability.  The ability to participate in transactions is necessary, both as an XA resource and as a simple cache to front a RDBMS, via JPA
Define behaviour at certain stages of a tx’s lifecycle, particularly with regards to recovery
Should play nice with JPA’s second level cache SPI
Define and mandate REPLICATION and DISTRIBUTION, as well as SYNCHRONOUS and ASYNCHRONOUS versions of network communications

These could be useful in the JSR, but needs more thought and discussion

An asynchronous, Future-based API (See Infinispan’s Async API)
XML-based config file standardisation (including an XSD)
Standardise programmatic config bean interfaces

Further interesting thoughts
These additional, NoSQL-like features would also be very interesting, but probably more sense in a later revision of this JSR – both for the sake of manageability as well as to allow more community adoption/feedback on such APIs.

The JSR 347, Data Grid

has been proposed to standardise a set of APIs, a programming model, and expected behavior of distributed, fault-tolerant in-memory key value stores. It differs from JSR 107 (Temporary Caching for the Java Platform) in a number of ways:

Permanence of data. JSR 347 attempts to be a record of store, using its inherently distributed nature to provide durability. JSR 107 makes an assumption that data stored is temporary and transient.
Distribution. JSR 107 allows that implementations may be distributed, while JSR 347 mandates that implementations are distributed. As such, the standard can offer users richer APIs to make better use of the data store. For example, exposing APIs to control where data is stored in the grid, asynchronous and non-blocking APIs, and APIs to support eventually consistent implementations only make sense when you know the implementation is distributed.
Map/reduce and distributed code execution. When data is distributed/partitioned across a grid, it sometimes makes sense to move code execution to the data rather than the other way around. JSR 347 will offer standard APIs for such features as well.

Java SE-8 a Sneak Peek by Venkat S

You have a A.jar in your class path which has dependencies on B.jar and C1.1.jar, so you put B.jar and C1.1.jar to the class path as well. On the other hand B.jar has dependency on C2.0.jar, so you put this also into your class path. So your class loader has to load all the classes from C1.1.jar and C2.0.jar (90% are equal), when there is call to a particular class, how the class loader will decide which version of the class needs to call?

To solve this issue, JDk 8 is going to introduce Jigsaw, which is nothing but the jar file version system. The requirement of Jigsaw is given below,

A tool must be provided that will transform a “plain old” JAR file into a modular JAR file by adding specified metadata or, possibly, inferring it from the JAR file’s name and legacy manifest information.

OSGI support: It must be demonstrated by prototype to be feasible to modify an OSGi micro-kernel such that OSGi bundles running in that kernel can depend upon Java modules. The kernel must be able to load Java modules directly and resolve them using its own resolver, except for core system modules. Core system modules can only be loaded using the module system’s reflection API.

JSR 335 (Lambda Expressions for the Java Programming Language) aims to support programming in a multicore environment by adding closures and related features to the Java language.

JSR 335 is part of JSR 337 (Java SE 8). The Early Draft Review #1 of JSR 335 has been published.

The goal of OpenJDK Project Lambda is to host a prototype implementation of JSR 335 suitable for inclusion in JDK 8, the Reference Implementation of Java SE 8.

Other rumors on JDK 8 features:  JavaFX 3.0, New devices support, Single Abstract Method (will discuss more on those later).

Scala for the intrigued

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application.

I found Venkat’s old training video, so I don’t think I need to write down anything more. 🙂

You can follow me on Twitter, add me to your circle on Google+ or like our Facebook page to keep yourself updated on all the latest from Photography, Technology, Microsoft, Google, Apple and the web.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s