Archive for the 'java' Category

Thread.setContextClassLoader Doesn't Work on CF 8.0.0

Published
by
barneyb
on July 10, 2008
in coldfusion and java
. 0 Comments

I know the number of CF 8.0.0 installs is probably pretty minimal compared to CF 8.0.1, but thought this was worth pointing out.  If you use Thread.setContextClassLoader on CF 8.0.0, it raises no exception, but it doesn't actually set the ClassLoader for the thread.

I ran into this today using my CF Groovy/Hibernate integration on one of my existing CF installs that is still 8.0.0.  It totally bombs, because the classloading trickery fails if it can't set up a classloader.  After spending a bunch of time on it, I just gave up, as nothing I tried had any effect.

Both CF 8.0.1 and Railo 3.0b2 correctly allow overriding the context ClassLoader, and can therefore use the Hibernate via CF Groovy.  I haven't tried in a while, but OBD exhibited similar symptoms as CF 8.0.0 when trying to run Hibernate, so it may suffer from the same problem.  This only affects the Hibernate stuff I'm doing, the base Groovy integration requires no ClassLoader trickery, so it works on all four without issue (and probably CF 7 too).

I should also note that this is NOT the underlying JVM.  I use the same JVM (a 1.6 series from Sun) for all my stuff, both development and production.

Fun with Classloading in Java

Published
by
barneyb
on July 4, 2008
in cfml, development, groovy and java
. 0 Comments

With my CF Groovy project, I've been doing a lot of Java coding of late. It's all been written in CFML, but it's mostly Java code in CFML syntax. As an aside, doing that sucks. CFML is horrible for writing anything more than the simplest Java code. But on to the topic at hand….

To this point in my career, basically all of the Java code I've written has been application code. Most of the CFML, JavaScript, and ActionScript I write is also application code, but I've contributed significantly to Fusebox and built a number of micro-frameworks in all three languages. However, none of that touches on the stuff I've done in the past couple weeks. The primary source of my issues getting Groovy and Hibernate to play together was classloading.

Unlike Grails (GORM, really), any of the various examples on the web, and I'm guessing Joe Rinehart's Hiberailooving project, three of the inviolate framework objectives were zero dependency on an IDE beyond text editing, no manual compilation, and no container restarts. Obviously, Hibernate provides a set of IDE tooling that can be brought to bear, but I'm talking about just the CF integration portion. I want to be productive with emacs and a web browser.

This presented a number of issues with classloading, because Groovy can only be loaded by the GroovyClassLoader (and subclasses). Basically this forced my hand to using compiled Groovy code, and ensuring it and Hibernate are loaded by the same ClassLoader. No GroovyClassLoader at all.

Now all that's well and good, but you have to be a bit careful, because two of the goals where no manual compilation and no container restarts. Doing compilation from CF is fairly simple (instantiate FileSystemCompiler and call 'main' with the right args), though again, getting all the right stuff on the classpath in the right order proved a nightmare. This is further complicated by the while JEE classloader situation, which isn't straightforward at all.

The details of this intricate dance completely escaped me for a week and a half. Then one night, while lying in bed, it all clicked together (thank you, Heather, for going to England). The solutions seem fairly obvious now, but they took a lot of fussing and fighting to deduce. I'd never even instantiated a ClassLoader before, aside from a couple one-off URLClassLoaders in CFML to lazy-load some JARs. Now I've got stacks of ClassLoaders, in some places two or three deep.

After my initial post-epiphany implementation was complete, I realized I can do some streamlining, but that's for after the release. I think I can even remove the need to drop the Groovy JAR in your /WEB-INF/lib folder, without adding any code complexity or runtime overhead, which would a nice bonus for ease of deployment. I.e., unzip the engine, write an entity, save it to the DB. No JARs, no restart the container, nothing.

It's been a very interesting (and pleasurable) experience, since it's so different from my day job of banging out boring little presentation apps all day. I've learned a lot, and even just the past few days of thinking about how other Java apps/frameworks work, I've realized how applicable that knowledge really is.

CF Groovy Takes a Nap

Published
by
barneyb
on July 2, 2008
in cfml, database, development, groovy, java and railo
. 0 Comments

After close to two weeks of struggling, I finally managed to deploy pure source to a CFML runtime (Railo, in this case), and get Groovy entities in and out of the database with Hibernate.  No compliation, no IDE, no development-mode server, just my Groovy source along with a hacked up CF Groovy.  This is very exciting for me, because while Groovy is cool and all, CF's dynamic nature has become a must have.

I don't have source to download yet, just a horribly hacky proof of concept, but here's what the user of the "framework" does.  First, create your entity:

package com.barneyb
import javax.persistence.*

@Entity
class Person {

  @Id
  @GeneratedValue
  Long id
  Long version
  String name
  Date dob

  def getAgeInSeconds() {
    (new Date().getTime() - dob.getTime()) / 1000
  }

  def getAgeInDays() {
    ageInSeconds / 86400
  }

  def getAgeInYears() {
    ageInDays / 365.249
  }

  String toString() {
    "$name is $ageInYears years ($ageInDays days) old"
  }

}

That's the same class as my initial CF Groovy demo used, except with the of JPA annotations added.  Because I'm binding to Hibernate, you can use any Hibernate-supported annotations, but I opted to stick with vanilla JPA.  Now we need our hibernate.cfg.xml, which is totally stock:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
  "-//Hibernate/Hibernate Configuration DTD//EN"
  "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>

  <session-factory>

    <property name="current_session_context_class">thread</property>
    <property name="cache.provider_class">org.hibernate.cache.NoCacheProvider</property>
    <property name="show_sql">true</property>
    <property name="hibernate.dialect">org.hibernate.dialect.MySQLDialect</property>
    <property name="hibernate.connection.driver_class">com.mysql.jdbc.Driver</property>
    <property name="hibernate.connection.url">jdbc:mysql://localhost:3306/dbname</property>
    <property name="hibernate.connection.username">username</property>
    <property name="hibernate.connection.password">password</property>
    <property name="hibernate.hbm2ddl.auto">update</property>

    <mapping class="com.barneyb.Person" />

  </session-factory>

</hibernate-configuration>

You could also map your classes manually with XML, if you wanted, but for the sake of simplicitly, I've done it all with annotations.  You'll also notice the database connection information embedded directly in the file. This is far from ideal.  I'm hoping to extract it from a CFML DSN, but that might only be possible on Adobe ColdFusion (via the Admin API).  The last thing is the test script:

<g:script>
  import java.text.SimpleDateFormat

  import org.hibernate.*
  import org.hibernate.cfg.*

  import com.barneyb.Person

  sdf = new java.text.SimpleDateFormat("yyy/MM/dd")
  sdf.lenient = true

  def sf = new AnnotationConfiguration()
      .configure().buildSessionFactory()
  def sess = sf.openSession()
  def tx  = sess.beginTransaction()
  sess.createQuery("delete Person").executeUpdate()
  sess.save(new Person(
    name: attributes.name ?: "Barney",
    dob: sdf.parse(attributes.dob ?: "1980/06/10")
  ))
  tx.commit()
  sess.close()
  sf.close()
</g:script>

No need to compile anything, no need to drop JARs all over your server, nothing.  Write, refresh, persist.  That includes adding new entities, new properties to existing entities, etc.

It's not ready for public consumption at the moment, but that's my top "free time" priority.  For the incredibly impatient, there's a branch in my SVN repository with the current source.  Don't expect anything pretty.  ;)

Closures for Java

Published
by
barneyb
on June 26, 2008
in groovy and java
. 14 Comments

Wanting some light reading for this evening, I decided to dig into the Closures for Java draft spec (homepage).

Oh. My. God.

I'm a huge fan of closures. They're elegant, simple, and easy to use. Their semantics are subtle, but not confusing. They allow for very concise implementation of otherwise complicated algorithms, trimming a vast number of "normal" control structures, particularly various looping constructs.

Java already has (anonymous) inner classes which provide similar semantics, though with a marginally clunkier interface. This mechanism is basically how closures in Groovy are implemented, with some compiler magic to do the heavy lifting.

If you go look through the Closures for Java spec, however, what you see is appalling. Closures are about simplicity and elegance, and the spec outlines exactly the opposite. Closures themselves are exactly what you'd expect, using the Groovy (or Ruby) syntax, though types are required for the arguments. But what you don't expect is the function type syntax, the closure conversion rules, generics support, etc. It's a mess. Check this example:

String name;
{int => long} transform;

The first line declares a variable of type "java.lang.String". The second declares a variable of type "function that takes one int argument and returns a long". Note that that is different from a variable declared as "{int => int}", of course. Even better, any closure that can be assigned to the 'transform' variable implicitly implements every single-method interface whose method accepts an int and returns a long. It's unclear to me whether the converse is true - I couldn't take any more dry spec-speak.

The spec is pretty short (less than nine pages), and if you do any Java, it's definitely worth perusing. After reading, you'll realize that anonymous inner classes are just fine, thank you very much, even with the requirement of having to declare the interfaces explicitly. With the amount of baggage they seem to be lugging into Java (mostly because of it's typing), all I can say is "yuck." Closures require a bit more dynamic an environment to be effective, I think, and Java is static. Totally static.

ActionScript 3 provides an interesting middle ground that provides the benefits but culls a lot of the garbage. In AS3 you declare functions with typed arguments and an explicit return type. However, every function is of type function, which means if I have an algorithm that requires an {T, T => int} closure (that's the Comparator interface, by the way), I can happily pass in any old function I want and the compiler won't care. I'll get an error at runtime, of course.

Much the dancing the spec details is to protect developers from this potential situation, and the rest is to deal with backwards compatibility an interoperability with older libraries. I understand that Java is a strongly typed language, and that the compiler is omnipotent, but c'mon. Backwards compatibility is also very useful, but again, to what extent. You can already thrash a generics-based library with reflection, because it's absolved from compiler checks. It seems like there should be a point where you recognize the fact that the language has very deliberately poked holes in it's own security structures, and realize that that means trying to create airtight compiler checking is pointless.

I guess that's why Groovy got created, though. Backwards compatibility is important for Groovy as well, but the compiler (javac, mind you, not groovyc) and all it's type checking wonder has basically been given the finger since everything is just an Object and duck-typed as needed. Quack! I'm a developer that likes transparency in my compiler. Compiler writers are supposed to be smart, they can figure out what I'm doing and tell me if it'll work or not. I shouldn't have to give them explicit instructions, at least not that explicit.

NB: Function pointers (a la CFML) are NOT closures. Closures bind to their definition scope, function pointers just point at a function with no bound scope. I've heard the argument that function pointers are equivalent/sufficient. They're not.

Scriptlets in CF Anyone?

Published
by
barneyb
on June 14, 2008
in cfml, groovy, java and tools
. 3 Comments

My last post about Comparators via CF Groovy was simplistic in nature, but the underlying concept is incredibly powerful.  Here's a similar snippet (from the demo app), this time using a Comparator class:

<g:script>
Collections.sort(variables.a, new ReverseDateKeyComparator())
</g:script>

So what do we have here?  Why it's a snippet of Java embedded directly in your CFML page, and it gets dynamically compiled and executed just like the CFML.  Let me say that again: it's a snippet of Java embedded directly in your CFML page.  It's even better than that, though, because it's Groovy, which is Java plus a whole lot more.

In addition to the scriptlet functionality, CF Groovy provides a classloading framework for Groovy scripts and classes, in addition to the ones provided by the CFML runtime and the JVM.  You can define an extra Groovy classpath for your scriptlets like this:

<g:setPath path="#expandPath('/groovy')#,#expandPath('/packages')#" />

There's no way to tell how the ReverseDateKeyComparator class in the first example is implemented, but it happens to be a Groovy class that I've added to the classpath with the <g:setPath> tag.  That class, just like the scriptlet, is dynamically compiled and executed just like the CFML.  This is also very powerful, because it eliminates the compile/build/deploy cycle that is usually required for Java code in a JEE environment.

Combining these two, you can use <g:script> to execute arbitrary scripts from the Groovy classpath, instead of inlining them:

<g:script name="myScript.groovy" />

This lets you reuse scripts across CFML pages, as well as reusing classes between scripts.

I've added CF Groovy to my Projects page, so that's the place for the latest info, as well as some documentation and the all-important Subversion information.

Design Patterns in Dynamic Langauges

Published
by
barneyb
on May 20, 2008
in java
. 0 Comments

I went to the Portland JUG meeting this evening to hear Neal Ford talk about design patterns in dynamic languages. Unlike Joshua Marinacci a couple months ago, Neal actually seemed to understand what he was talking about, which was a relief. He gave a quick run-through of dynamic vs. static languages (or ceremonial vs. essential, as he says), and then stepped through a bunch of the GoF design patterns, what they're about, and how they're largely irrelevant in Groovy and/or Ruby because the language provides the "pattern" as part of core language constructs.

What I found most interesting was the different ways that Ruby and Groovy do similar things. While I don't know that I've blogged much about it, those who interact with me in meat-space know all about my aversion for Ruby's ghastly syntax. (I swear Matz was drunk when he was doing the initial implementation and decided it should be a design goal to use every friggin' printable character in ASCII.) Seeing some of it's power compared with Groovy gave me some more appreciation for the language, even if it did nothing for it's appeal. Decorator implementations and method interception were particularly interesting.

Bottom line, however, is that design patterns (at least th GoF's) are incredibly relevant to dynamic languages. In fact, I'd say they're more relevant than ever. With "old" langauge (Java, C++, etc. that the GoF book was targeted at), you could either recognize the patterns and leverage their nomenclature, or you could not recognize them, lose a bit of productivity, but not really be too worse for wear. However, with the dynamic languages having many of the pattern implementations built in, you're really stuck if you don't understand the patterns and what they're about, because you can't use the language without that knowledge.

To use my favorite metaphor (carpentry tools), anyone can use a hammer and a chisel bevel the edge of a board (one specific board, mind you, no retries). It probably won't be very pretty unless you're quite skilled, but anyone can do it given time and patience. Give someone a table router and you've got all kinds of potential to hurt yourself, not to mention chances to ruin their one board, but you can do it quick if you know how. If you don't understand how the more powerful tool works, you're going to be in a world of hurt, but if you can leverage it's strengths, you'll be amazingly better off.

So don't skip the GoF book just because you use a dynamic language. You better know it inside out, just ignore the implementation details.

Use ColdFusion? Use Java.

Published
by
barneyb
on May 8, 2008
in coldfusion, development and java
. 18 Comments

If you use ColdFusion (or another Java-based CFML runtime), you should be using Java. There's a reason that CF uses Java under the hood: Java is incredibly powerful. Yes the interface to Java from the CF level is cumbersome and creating hybrid CF/Java applications pretty much costs you CF's RAD capabilities, but there are some real gems in the Java libraries.

On CF-Talk today, someone asked about reversing an array. There's not a built-in function for doing that, but if you remember that CF arrays are just Java Lists (java.util.Vector, specifically), you can suddenly leverage the full Java Collections framework. In this case, the solution was simple:

createObject("java", "java.util.Collections").reverse(myArray);

Want get unique values from an array? Not a difficult problem, but how about this:

myArray = createObject("java", "java.util.ArrayList").init(
  createObject("java", "java.util.HashSet").init(myArray)
);

Want them sorted? Here you go:

createObject("java", "java.util.Collections").sort(myArray);

Yes, there is an arraySort() CF built-in, but it only sorts text and numbers. So if you want to sort an array of Dates, you're stuck. Collections.sort, on the other hand, will happily sort the dates.

This only breaks the surface of what you can do with Java. Obviously you can't leverage this if you have to support non-Java CFML runtimes, but if you developing for a Java runtime (or runtimes), you owe it to yourself to learn a little bit about the Java tooling available to you.  I've blogged about a couple other Java tricks (fast directory filename listings and string builder tricks) in addition to myriad Java libraries that can be leveraged (Batik, Weka, Ant, etc.)

Here's an complete example of the above tricks:

a = [1, 2, 3, 4, 5, 1, 2, 3, 4, 5];
// reverse it
createObject("java", "java.util.Collections").reverse(a);
writeOutput(a.toString()); // [5, 4, 3, 2, 1, 5, 4, 3, 2, 1]

// sort it
createObject("java", "java.util.Collections").sort(a);
writeOutput(a.toString()); // [1, 1, 2, 2, 3, 3, 4, 4, 5, 5]

// pull unique elements
a = createObject("java", "java.util.ArrayList").init(
  createObject("java", "java.util.HashSet").init(a)
);
writeOutput(a.toString()); // [3, 2, 1, 5, 4]

// unique elements in sorted order
createObject("java", "java.util.Collections").sort(a);
writeOutput(a.toString()); // [1, 2, 3, 4, 5]

Interesting @task Edition Breakdown

Published
by
barneyb
on June 18, 2007
in development, java and tools
. 1 Comment

The operational support team where I work uses a product called @task for trouble tickets, and I'm currently build some Subversion/Trac integration pieces so that we can keep everything in sync between us (the developers) and them.  I saw they have a SOAP interface for the product, but made an interesting discovery: it's only available as part of the Enterprise edition of the software.  That's not totally irrational on it's own, but what I found a bit strange is that both Professional and Enterprise editions expose an EJB (yeah, Enterprise Java Beans) interface.  It doesn't matter a whole lot, and I honestly prefer an SSB EJB interface over a SOAP one, since I'm building the client in Java anyway (with Spring, of course), but I thought it was interesting.

Telling it like it is

Published
by
barneyb
on April 21, 2007
in java
. 0 Comments

I was writing some Java today, and ran across the DraconianErrorHandler in the depths of Xerces (package com.sun.org.apache.xerces.internal.util).  It's a very apt name (it simply throws any errors it's passed), but the name struck me as something outside the bounds of the expected.  I'd have undoubtedly named it ErrorPropogationErrorHandler or something that described what it does, rather than alluding to a metaphor of it's behavior.

Clearsilver on OSX

Published
by
barneyb
on December 7, 2006
in java
. 0 Comments

It's been a while since I've posted, but I've got a lot to talk about. First up is Clearsilver on OSX.

For those of you who don't know, Clearsilver is a lightweight templating engine written in C. It has bindings for a wide array of languages, including Java. Java bindings, of course, mean ColdFusion can use it as well. It's very low-level, which is both good and bad, but it's crazy fast and quite easy to work with. However, I had been unable to get it to compile on OSX until recently. Fortunately, the fix is simple once I figured it out.

Download the source tarball and unpack. Open up `rules.mk.in` in the root directory and around line 91 or so, replace "-shared" with "-dynamiclib" in the LDSHARED and CPPLDSHARED lines. Now run `./configure` with the appropriate options. Now open up `java-jni/Makefile` and around line 10, change "libclearsilver-jni.so" to "libclearsilver-jni.jnilib" in the NEO_UTIL_SO line. Do your normal make process and you should be greeted with working Java bindings. Just drop clearsilver.jar and libclearsilver-jni.jnilib in your classpath, subject to the standard JNI caveats about multiple loads per JVM instance.

I'm a total noob with C tooling, so I'm sure there's a better way to approach this (probably with some magical setting in the autoconf scripts). However, I don't know what it is, and making two little text changes wasn't enough of a burden to make me dig deeper. If anyone has a better solution, however, I'd be interested to hear about it.

On a related note, some of the code I contributed has made it into the official distributions.  While I'm sure they're not using the Java bindings (which is all I contributed to), it's still pretty cool to be able to say a package I helped develop powers Google Groups, WUnderground, and Trac, among others.