Tuesday, January 18, 2011

Interesting article on Reloading Java Classes

Look at the code below. TAll the code is trying to achieve is get an instance of iExample. However, kind of complex code.

public class ExampleFactory {
public static IExample newInstance() {
URLClassLoader tmp =
new URLClassLoader(new URL[] {getClassPath()}) {
public Class loadClass(String name) {
if ('example.Example'.equals(name))
return findClass(name);
return super.loadClass(name);

return (IExample)

Monday, January 17, 2011

JDK 7: Support for dynamically-typed languages

JDK 7 is getting ready for GA. One of the very interesting feature of JDK 7 is invoke_dynamic which is about support for dynamically typed language at performance levels near to that of Java language. So far, following has been supported:

invoke_virtual :Interface related methods
invoke_special: private methods invocation
invoke_static: Static method invocation

Other enhancements are following:

Language enhancements such as following:
- Support for String in Switch-case
- Simplified varargs
- automatic resource management
- Multi-catch statement as part of improved exception handling

Upgraded class loader architecture to avoid deadlocks in case of non-hierarchy topologies

Method to close URLClassLoader

Enhanced Concurrency framework
-- A lightweight fork/join framework, flexible and reusable synchronization barriers, transfer queues, a concurrent-reference HashMap, and thread-local pseudo-random number generators

Internationalization related enhancements

I/O and networking related enhancements


Security & Cryptography

JDK 7 Features: "Support for dynamically-typed languages"

Sunday, January 16, 2011

Is this beginning for end of Java?

Not sure. But with following, I am thinking if developers should start learning newer JVM languages such as Groovy, Scala, JRuby.

1. Apache Software Foundation (ASF) resigned from Java community.
2. Google & Oracle battling over Java technology
3. Would Java remain open source after Oracle mis-adventures

Software development predictions for 2011 - JavaWorld

Friday, January 14, 2011

JMSAppenders COnfiguration for Various Servers

JBoss Server:

Properties env = new Properties( ); env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); env.put(Context.PROVIDER_URL, "jnp://hostname:1099"); env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces"); InitialContext jndiContext = new InitialContext(env);

WebLogic Server:

Properties env = new Properties( ); env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); env.put(Context.PROVIDER_URL, "t3://localhost:7001"); InitialContext jndiContext = new InitialContext(env);

Log4J Appenders Performance Analysis

This page would give a fair idea of how various log4j appenders perform at a very high load. Well, these are not my stress lab readings, and need to be tested. However, this should give a fair idea for understanding various appenders performance.


Also, question is whethar to use JMSAppender alone or use AsyncAppender and JMSAppender. The analysis of these are given in following page:


I have tried following scenario and TPS (transaction per second) came almost same in both the case in case of load of 100 threads in 60 sec.

AsyncAppender sending messages to Console and File Appender


Messages are sent directly to Console and File Appender

I need to do further analysis to come out with right set of observation.

JVM Language - Groovy, JRuby, Scala and Java

Well, this is definitely a news to me. I was looking at this webinar posted at InfoQ and all of a sudden realized that people have been really doing some good work in these other JVM languages such as groovy, Scala and Jruby.

Need to catch up on this... check out the seminar anyways..

Tuesday, December 19, 2006

Flyweight Design Pattern

I was wondering about Flyweight pattern for so many days. Let me present its definition and some detail.

Flyweight pattern: Flyweight is one of the structural patterns. The Flyweight Design Pattern is useful when there is the need for many, many objects to exist that share some information. Several thousand or even several hundred thousand objects might be needed, and this is usually very memory-consuming to keep track of. Given certain constraints, it is possible to reduce this problem greatly and make the presence of so many objects possible. If all of the objects share some intrinsic, invariant information that is constant among all of them, it can be removed from each object, and referenced. This eliminates the redundancy of having to repeat the same invariant, intrinsic information for each object, so instead of storing the same information n times for n objects, it is only stored once. This object that contains all of the intrinsic information is called a flyweight object.
It is possible for a flyweight to have extrinsic information as well. This information must be stateless and determined by context, having no stored values, but values that can be calculated on the spot.
The different components involved in the Flyweight Pattern are the Flyweight, the ConcreteFlyweight, the FlyweightFactory and the Client.

One classic example of a flyweight pattern is the characters stored in a word processor. Each character represents an object that has a font face, font size, and other formatting data. As you can imagine, a large document with this data structure would bloat the memory footprint of the word processor. Moreover, since much of this data is repeated, there must be a way to reduce the footprint - the Flyweight pattern. Each of the character objects would contain a reference to a separate formatting object which contains the required properties. This greatly reduces the memory footprint by combining all of the like-formatted characters into simpler objects that reference a single formatting object.

In Design Patterns, the Gang of Four (GOF) authors describe the Flyweight pattern like this:

Use sharing to support large numbers of fine-grained objects efficiently.

Memory Leak

Memory Leak: Unintentional object retention is sometimes called as "memory leaks". It could come about in several ways. One of the case is when an object is no longer needed is referenced through some path from the rootset.

Monday, December 18, 2006


OOP is object-oriented programming that modularizes software using basic oop concepts such as encapsulation, inheritance and polymorphism. OOP is not bound to any programming languages.

AOP is aspect-oriented programming. AOP modularizes software applications based on loosely coupled aspects. AOP is a concept and not bound to any programming language. Software vendors can provide implementation for AOP in any programming language and make it available for the entire software community. For example, AspectJ (http://www.aspectj.org/ ).
A concern is nothing but a function in a given system. Any system is typically composed of both core and non-core concerns. The non-core concerns such as logging and security are actually the supporting functionalities for the mainstay core functionalities. The core functionality is the one that the system is expected to do.
AOP helps separate the non-core concerns from the core concerns by implementing concerns as aspects. Each aspect is independent and loosely coupled with other aspects in the system. This provides the flexibility for developers to enhance or remove any aspect at a later point in time without affecting the design and current state of the system.

Examples of AOP are following:

1. Logging functionality which is non-core concern could be implemented as one of the aspect.
2. Benchmarking logic such as time stamps across a block of code could be senn as one of the aspect.

Using AOP prevents the utility codes to be tightly coupled from the main code.

For detail, go to http://www.developer.com/lang/article.php/3649681

Thursday, December 14, 2006

Visitor Pattern : Java

I was trying to understand Visitor design pattern when I got into Single-dispatch and double-dispatch terms. Well, understanding of visitor pattern is enhanced once you understand the dispatch terminology in OOPs.

Single dispatch is a mechanism where a function call on an object is rightly dispatched to correct method based on the type of the object. The arguments of function call do not really matters. However, in a double dispatch mechnism, a function call is dispatched to different concrete functions depending on the runtime types of multiple objects involved in the call. Java does support single dispatch mechsnism. However, there is MultiJava compiler written to take of double dispatch mechanism. Check out a nice simple reading on dispatch definition, http://ifacethoughts.net/2006/07/29/single-double-and-multiple-dispatch/

The link http://rileywhite.com/software/visitorpattern.html  presents nice explanation on the visitor pattern. One thing is sure. Visitor pattern is definitely hard to learn, unlike adapter, observer, factory patterns which are intuitive and widely used.

Another great reading on visitor pattern, which I really loved, is http://www.javaworld.com/javaworld/javatips/jw-javatip98.html .

Definition: The Visitor pattern lets us define a new operation on an object structure without changing the classes of the objects on which it operates. Rather than writing dedicated methods for each programming task and afterwards recompiling, the idea is to (1) insert a so-called accept method in each class, and (2) write the action code in so-called visitors.

One example code for visitor pattern is http://bobcat.webappcabaret.net/javachina/jc/ptn/Visitor.htm