Archive for the 'java' Category

DWR Rules!

Published
by
barneyb
on November 17, 2006
in java
. 2 Comments

I've been using DWR quite a bit on a new Java application, and WOW, it's awesome.  It's not really that different from any other JS remoting toolkit, but it is really slick.  In a nutshell, you declare "remotable" objects (mine happen to be Spring-configured services) along with what methods are remotable, and any complex data types (e.g. beans) that need to be marshalled in an out of the method invocations.  Then you just add a JS file to your page and start calling methods on your remotable objects just as if they were local.  Really slick.

I think what really sells it is the zero-config client usage.  No defining a gateway, no extra methods, just "normal" client-side code.  The only exception is the use of a callback instead of a return variable from methods (so they can run asynchronously), but still very elegant.

I'm a big fan of AJAXing HTML applications on an as-needed basis.  It lets you keep your application in HTML (which is fast to code and easy to maintain), but lets you give certain areas a richer UI, without having to go all one way or the other.  But let me tell you, over the past few weeks I've shifted my thinking and have started building basically static HTML pages and doing everything dynamic with remoting.  Very much the Flex paradigm, but realized in HTML, which is awesome because you can still go with HTML for part of the app.

I know I've not really said much (and managed to spent three paragraphs doing it), but of all the new stuff I've been using on this project, DWR has had the most WOW impact, which is surprising to me since it's band of utility is pretty darn narrow compared to something like Spring or Hibernate.

HotSpot is Hot

Published
by
barneyb
on November 10, 2006
in java
. 0 Comments

I've been doing a lot of Java lately, and (at least at work) moving away from ColdFusion.  I've got mixed feelings about the transition, but that's a different post.  Today I was doing some VERY primitive profiling on the application, and was amazed.

Not surprisingly, the majory of the request processing time went to data access.  We're using Hibernate, and it brings it's own overhead on top of the actual DB.  However, even with some gnarly HQL, it runs reasonably fast.  And as an aside, the Hibernate guys are friggin' nuts.  Turn on debugging some time and trace through the code.  If you don't nearly soil yourself, you're a braver man than I.

Also not surprising was confirmation that ClearSilver is ludicriously fast.  Even doing some pretty complicated multi-part renderings I couldn't get an entire request to spend more than 2-3 milliseconds running the ClearSilver engine.

What was surprising was how good of a job HotSpot does.  I don't claim to understand it's voodoo, but in a nutshell it monitors your Java bytecode as it's executing and optimizes it's execution, including converting the bytecode to native code, compiling it, and then using the compiled version if it thinks it ncessary.  There's a whole pile of things that it does, but that's how it got it's name (it finds the "hot spots" and cools them down).
I was quite demoralized after getting the first full implementation of our rendering engine working when even simple pages were costing 300-400ms each.  Note that "simple" means "a GET for a dynamic, multi-object page", so not really that simple.  But simpler than some gnarly form post.  I went back and made some tweaks to some of the problem areas, restarted Tomcat, and didn't see much improvement.  On a whim, I hit refresh four of five more times, and suddenly the execution times dropped to less than half of what they were.  A smile crossed my face as I thought "I love when technology just magically does the right thing."

I've got to do some checking, but those seven or eight requests that it took for HotSpot to kick in probably comprised several hundred executions of a particular method, so it doesn't take effect right away.  I also suspect that Hibernate will have some hot spots that will eventually be optimized as well, so I'll get even better performance once they're found.

If you're doing profiling (at least on Java), make sure you give your JVM some time to "warm up" and figure out how to best optimize itself.  I know I haven't done that in the past, but I sure will from now on.