Javatech » Java

Sun to be bought by Oracle for $7.4 Billion

Darren Hicks — Sun, 14 Jun 2009 17:45:09 +0000

I’m a little late on this to really consider it news in the sense that news is usually new. And I must admit I was sceptical when I first heard it, but it’s true. Sun themselves admit it : http://www.sun.com/aboutsun/pr/2009-04/sunflash.20090420.1.xml.

The mighty behemoth, proprietary squelchor of innovation, and extremely expensive Oracle is about to acquire the open-source, free, and always innovative Sun ( and with that Java!). Anyway I look at this it sucks – for Java, at least. This will, in my humble opinion, accelerate Java’s path to Cobol – which it is destined to become as more agile languages come to maturity and continue to grow in popularity ( ruby, python, erlang ).

Rod Johnson, with Spring, is singing an optimistic tune ( Spring Keynote Address on Future of Java ) . One that talks about Java having reached maturity and that it doesn’t really need to evolve anymore. C doesn’t really evolve – it does what it does and does it very well. As Rod says, “It doesn’t pretend to be C#.” Point taken. He goes on to say that in many ways the innovation in the Java community has already moved outside of the Java core. Language improvements include Groovy and Scala. Framework improvements come in the form of Grails ( and, he doesn’t mention this, Seam ).

Rod’s address is largely true, but it is also to drum up excitement for their new application generation project ROO. This gives alot of the functionality one would get from Rails or Seam, but does things within a shell rather than all command line. This is actually kind of nice because the shell can keep track of the context each subsequent command is running in and also allows for some pretty snazzy auto-completion features.

Should we Javaheads run around screaming the sky is falling? Probably not. But if we don’t get up to snuff with Grails and new projects like Seam and Roo which look to make things a whole lot RAD-der, then we’d better accept our role as stewards to the next generation of Cobol applications.

One more thing – Ruby, for example, is still missing a lot of enterprise tooling which we take for granted in the Java world. Applications like JConsole and JProfiler don’t yet exists – so another way to look at this is on the larger programming stage, where what we’ve learned with Java should be created for Ruby, Python, and Erlang to ease the passing of the torch when the time comes.

Java 101: building your java classpath from a lib folder

Darren Hicks — Mon, 23 Feb 2009 05:43:37 +0000

OK – I admit it – my IDE and tools make me weak in many ways. I was just having the hardest time getting my maven-managed project to run from a basic “java my.class.ClassName” command line invocation. Why? Because the freaking classpath is a million miles away from being a concern to me anymore. So, jog the memory and immediately remember the -cp ( or -classpath ) option. Also remember that I cannot specify a directory if I want to include all of the jars in that directory ( specifying a directory in the classpath will only load exploded .class files! ).

What I’ve got before me is a target/lib directory full of all of my maven2-managed dependencies. I need to add each jar file explicitly into the classpath – barf!

Well, here’s a handy little shell script which will build that string for you:

for file in `ls lib`; do echo -n ‘lib/’ >> classpath.txt;echo -n $file >> classpath.txt;echo -n ‘:’ >> classpath.txt;done

Awesome – so just open the classpath.txt file and use that big ‘ol path however you want to. Windows users would use a semi-colon instead of a colon above. Also, remember that you need to specify the classpath option prior to the name of the class to run – otherwise the classpath is ignored ( as it is assumed to be an argument to the program and not a jvm option ).

A Conventionally Annotated Configuration – Spring, Hibernate, Eclipse

Darren Hicks — Wed, 18 Feb 2009 07:31:29 +0000

I’m starting on a personal project and decided I was going to take the time to do things right. This means different things to different folks, but to me it basically entails:

Using the latest and greatest versions of everything. Eclipse 3.4. Hibernate 3.3.1. Spring 2.5.6. Tomcat 6. Maven 2.0.9. Java 6 ( 7? ), DWR 3.0.
Using Eclipse plugins to do as much as possible without causing headaches
Using as little XML configuration as possible – conventions, conventions, conventions!!!
Using JPA annotations for ORM classes.
Using Annotations for IOC dependencies.
Using Annotations for Transactional demarcation.
Using Annotations for MVC mappings.
Using very basic JSTL-based JSP’s for views.
Using Sitemesh to present a uniform look and feel across all pages.
For icing on the cake I’d like to also include GWT components.

Using the latest and greatest versions of everything
If you install Eclipse 3.4 first, and then install the Maven Integration plugin, it will greatly simplify things. Just add Maven Integration to your project and then use “Add Dependency” option to quickly scour the entire repository and find the exact groupIds, artifactIds, and versions you want. It also has a great view of the dependency hierarchy! Getting all of these bleeding-edge versions to play nice together has its fair share of challenges.

Using as little XML configuration as possible

Using Eclipse plugins to do as much as possible without causing headaches

I already mentioned Maven Integration above to help with getting the LAGV of all the technologies being used. Also of great value and import are SysDeo and Subclipse. Sysdeo is great for deploying and debugging your webapp in Tomcat. Subclipse is great for seamless integration with an SVN repostiory. Yes – use SCM on personal projects, you never know when you’ll need to revert or bring the code down onto a new machine.

But where do we draw the line here? When do we have so much annotation cruft that an externalized xml configuration will seem like the ideal solution ( from whence we currently come in search of clarity! ).

Using very basic JSTL-based JSP’s for views
OK – well, tonight I was getting ready to put together the first couple of jsp’s now that the @Controller mappings are working and the pages are being served correctly. I’ve got the method mapped correctly with @RequestMapping and I’ve got the model being put into pagescope with @ModelAttribute. I’m ready to loop through a List using JSTL forEach. But wait, can this possibly be true? Tomcat6 has no implementation of JSTL. JSTL 1.2 is the LAGV and the JSTL 1.1 is abandoned. Only *Glassfish* ships with the reference implementation of JSTL 1.2?!? Oh brother. Thanks to Peter Mularien for writing a nice post informing me of this.

As if needing to download and install glassfish in order to get the JSTL 1.2 implementation jars for Tomcat6 wasn’t bad enough, well I hit a couple more snags after that. First of all, I want to know who decided on the namespaces for JSTL 1.1 vs 1.2. Here they are:

1.0 == <%@taglib prefix=”c” uri=”http://java.sun.com/jsp/core” %>

1.1 & 1.2 ==<%@taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core” %>

I mean all they did was add the “jstl” into the path?!? I’m supposed to remember this? OK – I’ll try harder to remember for next time.

Then, I learned that Maven2 doesn’t copy “system” provided jars into WEB-INF/lib by default and they need to be placed there manually as part of the project. So, the appserv-jstl.jar I copied from glassfish wasn’t being included because I linked Maven to it as a system ( vs provided, or compile, or test, etc… ) dependency.

ArrayList vs Vector

Darren Hicks — Tue, 18 Mar 2008 15:15:06 +0000

I’ve done some more work on the ArrayList vs Vector performance issue. The post below originally stated that Vector would/could outperform ArrayList even though it is synchronized while ArrayList is not. Well, in digging deeper into the issue, I”ve determined that there is a problem with the benchmarking framework being used. I ran a very simple test with ArrayList and Vector to look at performance of add() and contains() methods and have determined that:

ArrayList.add() is 13% faster than Vector.add()

ArrayList.contains() is 3% faster than Vector.contains()

Now I need to identify the problem with the benchmark framework.

I’ve been surprised of late in my Unique Collection Building benchmarks that TreeSet was outperformed by ArrayList. One reason this could happen would be due to the nature of the dataset being processed and the data set I had contained many items with the first 20 characters or so being the same. You know, lots of entries starting with “/WEB-INF/javascript” perhaps. This would have made the TreeSets comparisons in deciding ordering more costly.

So, now I run the test again but with Vector thrown into the mix and the Strings are all 40 characters long and very, very random. The odds of differing after 2 or 3 characters are now very high.

TreeSet should do much better.

But how will Vector fair?

You probably know as well as I do that ArrayList is the faster, unsynchronized option to Vector ( much like using StringBuilder instead of StringBuffer ). But how much faster is ArrayList? Here are the results:

The cost of Autoboxing

Darren Hicks — Sat, 15 Mar 2008 07:36:52 +0000

Simple question: How expensive is autoboxing of int/Integer types?
Simple answer: 15 nanoseconds per boxing.

No autoboxing ( ints only )
[source:java]
public void runInternalTrial() throws Exception {
int i = getRandomWithoutAutobox();
}

public int getRandomWithoutAutobox() {
return rnd.nextInt(1000);
}
[/source]
Autoboxing
[source:java]
public void runInternalTrial() throws Exception {
int i = getRandom();
}

// Will Autobox an int to an Integer…
public Integer getRandom() {
return rnd.nextInt(1000);
}
[/source]
Note that the Autoboxing example has to Autobox the value returned by getRandom to an Integer and then the caller has to then unbox this back to an int primitive. The two examples for HalfBoxing are simply Autoboxing and then not unboxing back to an int. Here are the results:

JVM Comparison and Java Optimization Myths

Darren Hicks — Sat, 15 Mar 2008 05:18:19 +0000

Here’s a fairly comprehensive overview of 6 performance related myths as they relate to 7 different JVMs. I now feel safer running with try/catch blocks and with synchronization. We’ll be running our own benchmarks on these and the results will be up pretty soon. Here’s the link to the paper.

JBoss Seam Presentation

Darren Hicks — Fri, 16 Nov 2007 00:08:41 +0000

Seam is a must learn technology – check it out.

clipped from www.theserverside.com

In this presentation, recorded at the recent Grails Exchange event in London, organized by Skills Matter, Christian Bauer discusses how JBoss Seam simplifies the handling of stateful conversations, multi-window operations and concurrent, fine-grained Ajax requests. He also shows how Seam unifies and integrates popular open source technologies like Facelets, Hibernate, jBPM, Drools, Groovy, iText and Lucene.

Using Patterns to Suppliment your Spring Configuration

Darren Hicks — Thu, 15 Nov 2007 18:24:58 +0000

Your Spring configuration probably consists of one or more well know XML files which are loaded by name. Have you ever wanted to override something without having to touch your base configuration? Here’s what we do. After we load our base configuration we use a pattern to load any XML files which exist in a specific “configuration-override” directory. In most cases the directory is empty and just the base configuration is loaded. When we want to override a particular bean we just place a file in the override directory.Here’s a clip from the Spring API docs:

clipped from static.springframework.org

4.7.2.1. Ant-style Patterns

When the path location contains an Ant-style pattern, for example:

     /WEB-INF/*-context.xml
     com/mycompany/**/applicationContext.xml
     file:C:/some/path/*-context.xml
     classpath:com/mycompany/**/applicationContext.xml

Integrating Google Earth with a Java webapp

Darren Hicks — Sun, 11 Nov 2007 08:51:17 +0000

I did this at work the other day and thought I’d give the broad sweeping overview here should else want to do it. It’s not too bad after all’s said and done ( and sifted through… ). Here’s the quick and easy:

1) Add these mimetypes in web.xml:
application/vnd.google-earth.kml+xml kml application/vnd.google-earth.kmz kmz
2) You’ll want to write back KML ( a flavor of XML ) with a content-type of “application/vnd.google-earth.kml+xml”:

response.setContentType(“application/vnd.google-earth.kml+xml”);

3) Make sure you give the stream a default filename that ends in .kml or else GoogleEarth won’t actually process the file.

response.setHeader(“Content-Disposition”, “attachment; filename=” + filename + “.kml”);

That’s really a 40,000 foot view of the process. Here’s Google’s KML Tutorial so you can learn more.

C3P0 ConnectionPool Configuration Rules of Thumb

Darren Hicks — Sun, 04 Nov 2007 06:14:23 +0000

C3P0 is a fantastic open source ConnectionPool that is feature rich, stable, and positively production ready. I personally like it more than DBCP because there is too much blocking encountered when checking in/out connections with DBCP. C3P0 dodges that problem with an asynchronous return to the pool, but you might end up using a lot more connections than you need to if you’re not careful. Here’s a list of the most important C3P0 settings and good production settings to use – along with some words of wisdom as to why the change from default is a good thing.

acquireIncrement=5 default(3) Batching the retrieval of Connections is wise because the process of opening a Connection is expensive. Why do it 5 times instead of once? The downside to this is that you may only need the one connection. Read on to maxIdleTime settings to make sure idle connections make their way back into the pool.

maxIdleTime=3600 default(0) Setting the maxIdleTime to a non-zero value permits C3P0 to remove Connections from the pool and freeing up database resources. This will never happen when maxIdleTime is set to 0. Setting to a small value might have Connections being retrieved and returned on too frequent a basis to be practical, so I’ve picked 3600 seconds ( 1 hour ) as a nice happy medium. Once the peak traffic is over, then the connections can be returned.

maxIdleTimeExcessConnections=300 default(0) You need to set this in addition to maxIdleTime to have the Connections removed from the pool and returned to the DB.

maxPoolSize=100 default(15) You’ll have to fine tune this setting base on your own individual situation, but it’s important to keep this on the largish side for the simple reason that C3P0 doesn’t synchronously return connections to the pool. The implication of this is that the pool should actually be sized slightly larger than what you think the maximum number of Connections needed at peak time would be. For more on this, see numHelperThreads.

minPoolSize=20 default(3) This one too can be fine tuned based on your individual needs, but let’s just say that you don’t always want to be returning all your Connections and having to reacquire new ones. 20 is a good size to allow for handling of new bursts of sporadic traffic w/o having to reacquire them.

numHelperThreads=6 default(3) This is a very important property if you’re going to have large bursts of traffic on your site. C3P0 ( as was alluded to previously ) doesn’t return connections to the pool synchronously and as a result doesn’t have the same issues with blocking that DBCP has. However, as a result, Connections are not made available until some arbitrary time after they are returned to the pool. C3P0 has helperThreads which are responsible for doing the actual return work and making them available. Under large load I’ve experienced times where these spikes could require 400 Connections using the default setting of 3. Using 6 HelperThreads will keep this spike under 100 connections. If you can afford the connections or won’t have huge loads on the system, then the default of 3 will probably be fine for you.

unreturnedConnectionTimeout=3600 default(0) I’ve set this to 1 hour. If a Connection is used for longer than an hour, then C3P0 will assume it’s been orphaned and will reclaim the Connection to the pool – closing it in the process.