There a lots of sites that talk about the Language Enhancements in JDK 1.5. To Summarizse the Enhancements :-

Generics
Enhanced for Loop
Autoboxing/Unboxing
Typesafe Enums
Varargs
Static Import
Metadata (Annotations)

Here's my code that demonstrates all these features :-

import static java.lang.Math.max;

import java.util.ArrayList;

public class NewFeatures
{
public static void main(String[] args)
{


NewFeatures.autoBoxing();
NewFeatures.forLoop();
NewFeatures.newEnums();
NewFeatures.staticImports();
NewFeatures.variableArguments("Hello","Sandeep","to","JDK 1.5");
NewFeatures.generics();
NewFeatures.annotations();


}

public static void autoBoxing()
{
int i = 1;
Integer objInteger = 1;

i = i + objInteger;

System.out.println(" NewFeatures.autoBoxing :: The Value of the Integer is :: "+i);
}

public static void forLoop()
{
int iArray[] = {0, 1, 2, 3, 4, 5, 6, 7, 8};

System.out.println();

for (int iArrayElement : iArray)
{
System.out.println(" NewFeatures.forLoop :: The Array Element is :: "+iArrayElement);
}

System.out.println();

}

public static void newEnums()
{
for (Names objNames : Names.values())
{
System.out.println(" NewFeatures.newEnums :: " + objNames);
}
}

public enum Names { Sandeep, Seshan };


public static void staticImports()
{
double a = 100.1, b = 103.25;

System.out.println(" NewFeatures.staticImports :: The Maximum value is :: "+ max(a,b));

}

public static void variableArguments(String... args)
{
System.out.println(" NewFeatures.variableArguments :: The Number of Arguments are :: " + args.length);
}

public static void generics()
{
ArrayList alStringArrayList = new ArrayList();

alStringArrayList.add("I");
alStringArrayList.add("am");
alStringArrayList.add("Sandeep");
alStringArrayList.add("Seshan");

for( String strElement : alStringArrayList )
{
System.out.println(" NewFeatures.generics :: " + strElement);
}
}

public static void annotations()
{
System.out.println(" NewFeatures.annotations :: " + new NewFeatures());
}

@Override
public String toString()
{
return "New Features in JDK1.5";
}
}

Here's the Batch File to compile & run this :-



REM ***** START TESTING FOR JDK 1.5 *****

del *.class

SET PATH=D:\JDeveloper\jdk\bin;%PATH%

SET CLASSPATH=.;%CLASSPATH%

java -fullversion

javac NewFeatures.java

java NewFeatures

REM ***** END TESTING FOR JDK 1.5 *****



Here's the output :-



NewFeatures.autoBoxing :: The Value of the Integer is :: 2

NewFeatures.forLoop :: The Array Element is :: 0
NewFeatures.forLoop :: The Array Element is :: 1
NewFeatures.forLoop :: The Array Element is :: 2
NewFeatures.forLoop :: The Array Element is :: 3
NewFeatures.forLoop :: The Array Element is :: 4
NewFeatures.forLoop :: The Array Element is :: 5
NewFeatures.forLoop :: The Array Element is :: 6
NewFeatures.forLoop :: The Array Element is :: 7
NewFeatures.forLoop :: The Array Element is :: 8

NewFeatures.newEnums :: Sandeep
NewFeatures.newEnums :: Seshan
NewFeatures.staticImports :: The Maximum value is :: 103.25
NewFeatures.variableArguments :: The Number of Arguments are :: 4
NewFeatures.generics :: I
NewFeatures.generics :: am
NewFeatures.generics :: Sandeep
NewFeatures.generics :: Seshan
NewFeatures.annotations :: New Features in JDK1.5



I apologize for the psychedellic colors :)

I had a requirement where I had to convert a XML String Message to a DOM Document Object. The DOM Document Object would later be traversed to retrieve important XMl Elements.

I spent a good deal of time brushing up on Core Java, JAXP, Java I/O, etc - & of course, a lot of Googling. Finally, I reached enlightnement - here's the code snippet that worked for me :-


DocumentBuilderFactory objDocumentBuilderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder objDocumentBuilder = objDocumentBuilderFactory.newDocumentBuilder();
Document objDocument = objDocumentBuilder.parse
(
new ByteArrayInputStream
(
( "< Person >" +
"< Name >Sandy< / Name >" +
"< FirstName >Sandeep< / FirstName >" +

"< / Person >" ).getBytes()
)
);

I had to feed the String to a ByteArrayInputStream & pass it to the DocumentBuilder to parse & spew out the Document Object.

I was trying to ue Google's Advanced Search to polugh through Oracle AS OC4J Documentation - to my dismay, I noticed that Google is explicity disallowed from Indexing Oracle's Documentation. I checked the infamous "robots.txt" & noticed the same :-

http://download-uk.oracle.com/robots.txt

Well, I am now confined to the Oracle Search provided on the same page.

Brian Goetz articles are at this link :-

http://www.briangoetz.com/pubs.html

I found a very good article on practical uses of Garbage Collection Optimization in J2EE Fine Tuning :-

How We Solved our Garbage Collection Pausing Problem:-

http://gregluck.com/blog/archives/2006/07/how_we_solved_o.html

A detailed explanation about the Garbage Collection can be found at this link :-

http://www-128.ibm.com/developerworks/java/library/j-jtp11253/

Well, you can expect to see problems when you move your code deployed in an Application Server on Windows vs. Application Server on Linux. I was thinking about documenting the experiences I recentlyhad, until I noticed that Owen had beautifully documented it here :-

http://forum.java.sun.com/thread.jspa?threadID=5131195

The moral of the story & the meat of the problem is :-


a) Unix file permissions eg. unable to read/write/create directories,
porting batch files to shell scripts, execute permission on scripts

b) Case sensitivities of files, directories, resources, property files

c) Any hard coded paths would need to be changed to use File.separator, for
their platform dependant equivalent

d) Potential file encoding problems on text files and property files, also
in carriage return & linefeeds

e) Potentially "headless" environments in Unix. Where they don't have an X-Server running, so most, if not all, your Awt & Swing calls would fail.

f) Any calls to native libraries would need to Unix system objects instead of the Windows DLL's. ( *.so )

Thanks Owen !

You can quickly test independent JSPs in OC4J using the application "default". You can just drop your JSP in the default-web-app folder of your OC4J ( $ORACLE_HOME/j2ee/home/default-web-app ) and access the JSPs using the URL :-

http://< host >:< port >/j2ee/< your_JSP >.jsp

A superb blog :-

http://idcmp.blogspot.com/2007/01/lack-of-decent-java-developers.html

The ejb-jar file must also contain, either by inclusion or by reference, the class files for all the classes and interfaces that each enterprise bean class and the home and component interfaces depend on, except J2EE and J2SE classes. This includes their superclasses and superinterfaces, dependent classes, and the classes and interfaces used as method parameters, results, and exceptions.

EJB 2.0 Specification 23.3

I have read & re-read the EJB Specification many times over in order to get a good insight, but I have now learnt that only experience can offer clear insights.

The blurb from the EJB 2.0 Specification - 23.3 mentions that the EJB JAR file must
contain the primary EJB Classes ( The Bean Class, Remote & Home Ineterfaces ), either by inclusion or by reference.

I did not pay much heed to the phrase "..inclusion or by reference". I just thought that it may not be really significant in the big scheme of things - I alaways assumed that such phrases are tossed between simple sentences to make them look more "legal".

However, that phrase "...inclusion or by reference" is very very important & I realized it only recently.

I got hold of an EJB EAR file that was packaged in a different manner :-














I always walked on the beaten track & was surprised to see that the classes & the Deployment Descriptrs ( DD ) don't share the same JAR File.

After discussions in Oracle Technology Forums & debates with some of my colleagues ( & of course, reading the EJB Specification late into the night ), I understood that it's perfectly normal to package it in different JAR Files. The WebLogic Application Server used a concept of APP-INF Folder in EAR files to dump some of the application's common libraries.

Well, the meat of the topic here is that at the time of deployment, the EJb classes should be available for the Container. The Container should be able to locate the classes in the application ClassPath. Hence, we can rewire the application classpath & informn the Container about the catucal location of the EJB Classes.

Again, reverting to the EJB Specification 2.0 ( 23.1 ) ,

The ejb-jar file format is the contract between the Bean Provider and the Application Assembler, and between the Application Assembler and the Deployer.

The same works for Servlets & web.xml.

I would defenitely request the authors of the EJB Speicification to keep the language simple ( as in the JavaMail or JMS Specifications ). It would help mid-level developers like myself to get more comfortable with EJBS. It would also motivate the newbies to step into the world of EJBs with more confidence.

Java's Garbage Collection is a very interesting topic & I have not yet explored the nuts & bolts. I am still reading articles by Bill Venners & co to understand the nuts & bolts.

Recently, I was asked by a newbie about Memory Leaks in Java. He had just stepped into the world of Java & wasn't sure about Garbage Collection & Memory Leaks in Java. He asked me if it was possible to show an instance of Memory Leak in Java.

The question has been adressed numerous time ever since the first Java Version rolled out. A lot of examples are availale on the net that show how to get a Memory Leak from Java.

I wrote this example on the fly & wanted to save it for posterity :-

import java.util.ArrayList;

public class MemoryLeakSimulator
{

public static void main(String[] args)

{
try

{

System.out.println(" MemoryLeakSimulator.main() :: Start :: Leak ");

ArrayList objHeapPigArrayList = new ArrayList();

ArrayList objHeapSinkArrayList = new ArrayList();

for(

long lCounter = 0;

lCounter <>

lCounter ++

)

{

objHeapSinkArrayList = new ArrayList();

objHeapPigArrayList.add(objHeapSinkArrayList);

}

System.out.println(" MemoryLeakSimulator.main() :: End :: Leak ");

}

catch (Throwable objThrowable)

{
objThrowable.printStackTrace(System.out);

}// end of the try block

}// end of main() method

}// end of MemoryLeakSimulator

There is nothing new or innovative in the code - Objects are created in the "Heap" memory of the JVM. The Garbage Collection tries to free the menmory used by "unreferencable" object. However, in this case, we are continously pumping objects to the ArrayList & at a critical time, you may notice this error :-

..................

...................

...................

[Full GC 60651K->60648K(65088K), 0.3803447 secs]

[Full GC 65087K->65086K(65088K), 0.4023478 secs]

[Full GC 65086K->65086K(65088K), 0.3938506 secs]

java.lang.OutOfMemoryError: Java heap space

That's the meat of it !

Also, every Memory Leak ( at least in 1.5 ) generates a hs_err_pid*.log file. It gives a lot of useful information.