CK's Blog

Learning to know Featherweight Java - An Easy Way

2011-12-24T21:41:00.001+07:00

It's very long time since last my last post and I am still learning how to properly prove type soundness of a programming language. Here's a list of lectures from Cornell that I've been reading and they're quite good to understand.

Type system primer

2010-02-09T20:45:00.001+07:00

Given an expression e, a type T and a dictionary TT
that maps variables to type, the notation

TT |- e : T

roughly means

T = typecheck(TT, e)

and the horizontal bar notation:


P1     P2     P3
----------------
      Q

means

Q if P1 and P2 and P3

from: http://wiki.jvmlangsummit.com/pdf/28_Siek_gradual.pdf (slide 6)

Groovy Performance Update - Long running programs are as fast as Java

2009-12-07T18:55:00.001+07:00

It's been almost one and a half year that I have not updated anything related to Groovy performance in general. As I posted previously that I have been still doing on this topic, now it's time for updating a bit.

The technique is to hook the callsite caching process. Each callsite-to-be-called is profiling, its runtime information is analysed, and the faster code for it is then generated. The callsite is replaced by its equivalent direct call. Replacement is done, anyway, through JVMTI similar to the trick implemented in the previous version of GJIT. However, the concept used in this version of GJIT has been changed from totally automatic to manually controlled. This means that only selected callsites will be optimised, and you, as a developer, can control this optimisation via the mechanism provided. This concept is not that new, I have posted about it a while ago.

Latest results I came up with are micro-benchmarks. All of them in the long run, after related call sites are optimised, are running at the same speed as Java programs.

Let's examining the graph of the Fibonacci benchmark:

You can see that there are 2 interesting regions of graphs before the Groovy program getting the same speed as Java.
1. At the beginning, there is an overhead of profiling the callsite instantiation system of Groovy.
2. For background optimisation, an optimiser thread requires times for analysis and code generation. (I also make a note on the overhead of HotSpot VM, just for referencing).

After the optimisation phase is completed, the speed of Groovy program goes overlapping with Java. This approach would be working fine for a long running program, but not for scripting. Why? I left this as an exercise for the readers ;-)

Analysis of static Groovy claims

2009-11-14T15:52:00.001+07:00

Continued from my last post, I think I will be in the neutral point of view enough to do the analysis for these claims. All of this analysis are solely based on my opinion, so discussion is always welcome.

It is possible to write a statically typed compiler for Groovy keeping all goodies of the beautiful language.

This is partially true. I do not think I can create a static compiler to cover all Groovy features at once.

It is possible to implement very powerful type inference of local variable and closures, so we don't need to provide verbose type information more than necessary and/or useful for documentation purposes.

This is partially true. A language cannot fully support type inference. Type inference itself has its own limits, and it is a known P-complete or NP-complete problem depending on its implementation) [see this].

It is possibly to have compile-time metagrogramming (properies, categories, default groovy methods, mixins, ast transformations - all but runtime meta-programmings).

This is also true. But adding more phases to the compiler will make it slow. When the compilation time is slow + startup time of the JVM, you might not be happy using the language as a scripting tool. Pluggable type systems would be possible to help this issue.

It is possible to support Scala-like traits (also knows as interfaces with default implementation), which is extremly strong meta-programming tool.

This is true. No doubt.

It is even possibly to compile piece of code in so called mixed mode (resolve and call statically what we can and call the rest dynamically). This mode is great for example for mixing computation with building markup or populating UI elements with results of computation.

This is true. There is also something called Soft typing and Gradual typing which could help one archieve both static and dynamic call in the same language. However, the way of building markup can be just a simpler trick. I have it in my last post.

It is even possibly that because of type inference staticly compiled code can be a little bit less verbose compare to Groovy (almost no need in 'as' conversion for example).

This is probably false. In general, I do not think there will be a better way than a dynamic language to do so.

Static Groovy, is it feasible?

2009-11-12T01:07:00.001+07:00

Static Groovy seems to be a hot topic. There have been debates about it in the past. And recently, Alex's call for implementation has been posted on Groovy's DZone. Yesterday, Jochen's got his view about it here.

To me, I have been (and still) doing somethings to boost Groovy performance. Actually, it is based on the current call site implementation of Groovy 1.6. But that's another approach (As people said, performance is not only concern for static Groovy, early detection of errors is also what they want).

One of the biggest challenge of implementing static Groovy is that how could we implement a framework like Grails using it. This is really an interesting question to me, as Grails requires a lot of dynamic features of Groovy. So, I try to summarise what static Groovy should be capable of for making a Grails-like framework happen.

Firstly, GORM dynamic finders:
This kind of finders mainly uses missingMethod to perform their actions.

Considering this (posted as a comment in Jochen's blog):

class C {
def findBy/s/(Object ...) { .. }
}

You may notice "s" in the method name. It is of type String and can be referenced in the method body.
So this is basically, findBy* of Grails. Missing method could be modelled in the same way. For example,

class C2 {
def /s/(Object ...) { /* doing something with s */ }
}

Secondly, Adding dynamic methods:
This mainly uses in Grails plugins to extend capability of the framework.
The idea of category would be working perfectly for it.

main() {
A.test()
}

class A {
}

class Plugin {
static test(A self) { .. }
}

Resolving the test method would be a bit problem as it's not only through the class hierarchy of A, but also other classes that contain methods that crosscut A. It would be a bit easier for a compiler to resolve them, if we have a marker like @extension static test(A self) { ... } to help it.

Thirdly, interception for implementing invokeMethod:
This may probably involves the concept of AOP. But I will note use its terms here. Actually, the example is came from a work in the AOP area.

When you are going to intercept call of existing methods, this could be working:

class C {
intercept *(X x) {
proceed(x); // intercepting methodForX only
}

intercept *(Y y) {
proceed(y); // intercepting methodForY only
}

intercept *(Object ...) { ... }

def methodForX(X x) { .. }

def methodForY(Y y) { .. }
}

This concept would be called local interception, where an interceptor is capable of only intercepting methods in the same class. System-wide interception would be doing the same. Anyway, it will be something like AspectJ, in eventually.

To sum up, there are really challenges to implement a static counterpart of Groovy. However as you might see, having enough features to implement a Grails-like framework using such language is not that easy. A lot of things need to be proper implemented. Anyway, this is really an interesting thing to do.

Using AsmNodeBuilder to Test Bytecodes with Pleasure

2009-09-04T22:50:00.001+07:00

DSL of Groovy never made me bored. I am working on some bytecode transformation and having a number of tests to run.
Testing low-level transformation means dealing with JVM instructions. For example,

ILOAD 0
INVOKESTATIC java/lang/Integer.valueOf(I)Ljava/lang/Integer;
LDC 0
INVOKESTATIC java/lang/Integer.valueOf(I)Ljava/lang/Integer;
INVOKESTATIC org/codehaus/groovy/runtime/ScriptBytecodeAdapter
.compareLessThan(Ljava/lang/Object;Ljava/lang/Object;)Z
IFEQ L2

There is class MethodNode in the tree package of ASM. The class has the field instructions of class InsnList, which contains its method body. In the following, I have InsnList insn = methodNode.instructions; to perform some optimisation over it.

Before making AsmNodeBuilder, I had to create
a test data using Asm's Tree Nodes. Something looks like:

insn.add(new VarInsnNode(ILOAD, 0))

With Groovy and AsmNodeBuilder, now I can write:

insn.append {
iload 0
}

When comparing results, I had to do:

assert insn.get(0).opcode == ILOAD
assert insn.get(0).var == 0

Now, it becomes:

assertEquals asm { iload 0 }, insn[0]

Of course, I can also do:

assertEquals asm {
iload 0
invokestatic Integer,"valueOf",[int],Integer
}, insn

to assert all instructions in the list.

Look fun? Convinced? There are two classes you may use:

- InsnListHelper.groovy
- AsmNodeBuilder.java (generated from gen_asm_builder.groovy)

Here's how to

call InsnListHelper.install() in the very beginning of your Groovy test case.
Write a test case.
use <InsnList>.append { ... } to create a method body.
do your transformation.
assert the result against an asm { ... } block. Note that Groovy's power assertion won't work with the block for some reasons, use assertEquals instead.

You can also look at an example here.

Improved Complex Number in Groovy

2009-07-26T20:47:00.001+07:00

Thank you for last comment in the previous blog. Here's the improved version of Complex Number.

Number.metaClass.plus = { n ->
if(n instanceof Imaginary) {
    new Complex(r:delegate, i:n.v)
}
}
Number.metaClass.getI = { ->
new Imaginary(v: delegate)
}

class Complex {
def r
def i
String toString() {
    "$r + ${i}i"
}
}
class Imaginary {
def v
def plus(n) {
    if(n instanceof Number) new Complex(r:n, i:this.v)
}
}

def b = 2 + 2.4.i
def c = 4.2.i + 2
println b
println b.class
println c
println c.class

Complex Number in Groovy

2009-06-11T03:49:00.002+07:00

Here's a quick note of making Groovy to support complex numbers:

1. override number operations via metaclass:
Number.metaClass.plus = { n ->
if(n instanceof Imaginary) {
return new Complex(r:delegate, i:n.v)
}
}

2. define class Complex to hold real, r, and imaginary, i, parts
class Complex {
def r
def i
String toString() {
"$r + ${i}i"
}
}

3. create class Imaginary to be a wrapper class (I borrow this idea from Scala's implicit converter).
class Imaginary {
def v
}

4. define i as a global closure. It would be in DefaultGroovyMethods, actually.
def i = { v ->
new Imaginary(v:v)
}

Then when you write:
def b = 2 + i(2.4)
println b
println b.class

This prints "2 + 2.4i" and the type of b is class Complex.

Fortress - Hello World

2009-06-06T22:43:00.001+07:00

Here's my early experiment of running Fortress Hello world program, which is listed below (taken from the tutorial at MIT by the Fortress team):

component hello
export Executable

run() = println("Hello, World !")

end

I'm a bit surprised that its compilation time is "really" slow. I may be guessing that it's caused by type inference in the Fortress compiler. JVM 1.6.0_12 was used in the experiment. One of my quick conclusion is that Fortress is not suitable for scripting. But I think its compiled program will not be slow (as I mentioned that I am suspecting its type inference engine that makes scripting slow).

Here's 5 times of running:

chanwit@lb /cygdrive/c/fortress/fortress_3625
$ time `bin/fortress chanwit/hello.fss`
bash: Hello,: command not found

real    0m11.393s
user    0m0.244s
sys     0m0.199s

chanwit@lb /cygdrive/c/fortress/fortress_3625
$ time `bin/fortress chanwit/hello.fss`
bash: Hello,: command not found

real    0m11.486s
user    0m0.181s
sys     0m0.214s

chanwit@lb /cygdrive/c/fortress/fortress_3625
$ time `bin/fortress chanwit/hello.fss`
bash: Hello,: command not found

real    0m11.412s
user    0m0.213s
sys     0m0.215s

chanwit@lb /cygdrive/c/fortress/fortress_3625
$ time `bin/fortress chanwit/hello.fss`
bash: Hello,: command not found

real    0m11.377s
user    0m0.197s
sys     0m0.198s

chanwit@lb /cygdrive/c/fortress/fortress_3625
$ time `bin/fortress chanwit/hello.fss`
bash: Hello,: command not found

real    0m11.432s
user    0m0.229s
sys     0m0.198s

Hybrid call site model based on Groovy

2009-02-27T14:01:00.001+07:00

I'm trying to model a class structure that support the following features:

callsite; separating call and execution semantics to

support before/after advice of AspectJ's pointcut-advice model (possible support around advice)
further support my typing concerns.

support statically resolved callsite (resolving is done at compile-time, but also changeable at runtime)
support dynamically resolved callsite (as done in Groovy, JRuby, etc.)
must be compatible with Java. i.e., Generated classes can be used as normal Java classes.

My below POC is based on Alex T. implementation. But instead of showing all kind of callsite, I show you here only statically resolved callsite. This callsite is surely fast (I hope it's gonna be at the same level of Java) because it's compile-time thing. The interesting point is that, I have a special class loader for these callsites, namely StaticCallSiteClassLoader. What does it do? This class loader allows re-definition of these callsites.

What I have observed so far is that All of my callsite classes (_0_println, _1_ctor, _2_render and _3_index) have not been loaded when there is no "direct" reference to them. So they can be fully lazy loading using the StaticCallSiteClassLoader. (I've checked this with java --verbose)

How could these callsites are changed at runtime?
You may see the acallsite, an CallSite array that hold all callsites in the example class. It's intended to be public and can be accessed by, for example, a virtual meta-class.
So what's a virtual meta-class? It's kind of meta-class, but in this case, it's not for controlling behaviour of the class (because all dispatch are static). It's for changing behaviour of callsite by reassigning new callsites object to the callsite array.

Notic that I use WeakReference to hold a callsite class loader. This will be making the class loader GC-able. That's it, after deferenceing all old callsites out of the callsite array, the class loader can be unloaded. Therefore, all callsite class definition are gone as well. Then, we can create a new set of callsites for the current class. This technique would be flexible enough for:

changing a static call to be a dynamic call
changing a dynamic call back to a static call
installing a woven callsite with before, after advice (it features dynamic AOP)
inserting type advice, which can lead to bytecode inlining
design a hybrid type system to support both static and dynamic typing in the same system.

import java.lang.ref.WeakReference;

import runtime.CallSite;
import classloader.StaticCallSiteClassLoader;
import dm.Render;

public class TestController {

    /* synthetic */
    private static WeakReference<StaticCallSiteClassLoader> cl;

    /* synthetic normal callsite */
    public static class _0_println extends CallSite {...}

    /* synthetic constructor */
    public static class _1_ctor extends CallSite {...}

    /* synthetic inter-type declaration callsite. statically resolved */
    public static class _2_render extends CallSite {...}

    /* synthetic property callsite */
    public static class _3_index extends CallSite {...}

    /* synthetic */
    public static CallSite[] acallsite;

    static {
        cl = new WeakReference<StaticCallSiteClassLoader>(
                    new StaticCallSiteClassLoader(TestController.class)
        );
        acallsite = new CallSite[4];
        acallsite[0] = cl.get().get("_0_println");
        acallsite[1] = cl.get().get("_1_ctor");
        acallsite[2] = cl.get().get("_2_render");
        acallsite[3] = cl.get().get("_3_index");
    }

    public TestController(){
        super();
    }

    public int getIndex() {
        return 10;
    }

    public static void main(String[] args) {
        acallsite[0].callStatic("hello world");
        TestController t = (TestController)(acallsite[1].callConstructor());
        acallsite[2].call(t, "hello world");
        acallsite[0].callStatic(acallsite[3].callGetProperty(t, "index"));
    }

}

Using AspectJ to find a Grails' bug

2009-02-25T00:27:00.001+07:00

It's because I've got a constraint resource (also time). I've found a Grails bug (4060) that is really hard to spot. There is no exception was thrown and I have no idea how to trace this bug because my knowledge about Spring is really limited. I also do not have any good IDE to help debug Grails well. (calling grails-debug and attaching it remotely to Eclipse won't help much in this situation).

After I enabled Grails log to understand some behaviour of Grails' spring package, I saw some point in the log that it's likely a bug, but the log message is inside Spring, not Grails. (Yep, I need a stack trace).

I then got an idea of using AspectJ to help inserting a conditional code to "dump" stack from that point. What I've used is an execution PCD and a call to Thread.dumpStack();

Here's steps:

Enable trace log in grails-app/Config.groovy
Find a message
Grep to locate the point that emits the message. I found it in Spring code, not Grails.
Instead of rebuild Spring, I wrote this AspectJ code:

    pointcut pc():
        execution(
           public Object DefaultSingletonBeanRegistry
               .getSingleton(String,ObjectFactory)
        );

    before(String name): pc() && args(name,..) {
        if(name.equals("localeResolver")) {
            Thread.dumpStack();
        }
    }

Note that my target Spring bean is localeResolver, so I put a condition here to dump the current stack to find which part of Grails code is doing with this bean at that time.

I then wove the above aspect into spring.jar

$ ajc -cp .:aspectjrt.jar:spring.jar
   -inpath spring.jar\ // I was going to weave spring.jar
   -outjar spring-2.5.6.jar\ // output would be spring-2.5.6.jar
   -showWeaveInfo\ // I wanted to see some weaving info
   -Xlint:ignore\ // ignore error when resolving some missing classes
   Dump.aj // the above aspect

And gotcha, I could really see the context around when this Spring bean is loaded, and reported to Grails JIRA (And Graeme, you did fix it really quickly - you're super cool!).

Thus, using AspectJ code + Thread.dumpStack() is kind of a conditional break point that can help you debugging Grails without an IDE.

Simulate Object with Groovy's Closures and Map

2009-02-20T07:54:00.001+07:00

After reading Chapter 18 of Types and Programming Languages by Benjamin C. Pierce, I've got an idea to simulate how OOP is working with closures and map in Groovy. Just for fun anyway :)

def func_01 = { self, props ->
self.name = props["name"]
}

def func_02 = { self ->
println "${self.name} is running"
}

def a = [init: func_01, run: func_02]
a.self = a

a.init(a.self, [name:"mr. a"])
a.run(a.self)

Explaining Typesheet

2009-02-17T02:01:00.001+07:00

I've been designing a language for typesheet, a technique to speeding up Groovy by enforcing type for specific calls.

Current I can enforce type of a call by writing:

method(my.package.MyClass#main(String[])) {
call(println(*)) && args(s) {
s ~> String;
}
}

This typesheet reads: With in the main method of class MyClass, match every call to meta-method "println" (regardless input args). For matched calls,

let MOP select real methods by assuming the type of input argument to be "String", and
convert values of those arguments to be "String" before passing them to the calls.

You may notice that I emphasis 2 places. There are 2 different phases of the above code to be working. Firstly, in dynamically typed languages, like Groovy, method binding is performed at runtime. So matched call messages are not the real methods. Calls to "println" there may be anything depending on the MOP engine to select.

Secondly, declaration in { s ~> String; } (I call it a type intervention block) enforces MOP to select the method according to the type of "s", which is bound to the only argument of the method. ("s" has been binding using an args predicate).

So, what's happening next? You might be guessing correctly :)
MOP will be fully by-passed for those matched calls (because related types are enforced). Therefore, speed will be increased to the level of normal Java calls.

Playing around XUL, JavaScript and jQuery

2009-02-09T09:06:00.001+07:00

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<x:window
    xmlns:x="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
    xmlns="http://www.w3.org/1999/xhtml"
>
    <x:script type="application/x-javascript"
        src="file:///c:/xul/jquery-1.2.6.js"
    />

<x:script type="application/x-javascript; e4x=1">
<![CDATA[
function test(){
    $('#b').attr("label", "3");
    var frag =
        <listitem value="4"
            label="new item"
            xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        />;
    $('#l').get(0)
        .appendChild(
            (new DOMParser()).parseFromString(
                frag.toXMLString(), 'text/xml'
            ).documentElement
        );
}
]]></x:script>

    <x:button label="click me" oncommand="test();"/>
    <x:button id="b" label="2"/>
    <x:listbox id="l">
        <x:listitem value="1" label="item label"/>
        <x:listitem value="2" label="item label"/>
        <x:listitem value="3" label="item label"/>
    </x:listbox>

</x:window>

The above code is to dynamically adding a new <listitem/> into listbox #l. It will be working fine when we get some XUL fragment remotely from the server-side as well. This is Gecko 1.9.0.5.

What I've learned:

$("#id").get(0) returns a single element, while .get() returns a list.
e4x=1 tells the JavaScript parser to use the newer language spec.
jQuery works fine with XUL, but XML namespace is needed to avoid some gotcha because it's been designed to work with HTML, not actually XUL.
DOMParser works as expected
Gecko 1.9 solved a lot of bugs I was encountering in 1.8.
With Grails as a back-end, we can now create a dynamically half-Web/half-desktop app.

What if Groovy has got Structural Typing

2009-02-02T16:14:00.001+07:00

Here's a quick mock class after I've been reading this entry.

class G7Greeter {

def greet(String who, {def setOutput(String text)} model) {
println "Hello from G7 ${who}"
model.output = "Hello from G7 ${who}"
}

}

It would be great if Groovy has Scala's structural typing feature. Structural typing is good for statically "duck typing"-like behaviour. But it seems we need a fork as Groovy dynamic typing allows multi-dispatch already.

Fortress Summary

2009-01-12T13:52:00.003+07:00

This is a summary from Fortress Language Specification 1.0.

Fortress "secure Fortran" in a nutshell.

General-purpose
Statically typed
Component-based
Designed for producing robust high-performance software with "high programmability"
Intended to be a "growable language"

be gracefully extended
be scaling to "unprecedented" levels of parallelism and of addressable memory

Supports modular and extensible parsing

allow new notations and static analyses to be added

High-performance computation with abstraction and type safety
Support type inference

although it's statically and nominally typed
types can be omit if they are clear in the context
types can be parametric

Functions are first-class values
Components in Fortress are defined as entities with export and import APIs (not in general compared with the same term of Scala)
Built-in parallel computation support for large scale data structures, e.g. for loop is parallel by default

Modular Concerns

Object and Trait

an object consists of fields and methods

traits are named constructs that declare sets of methods. This concept is from Self.

method in traits may be abstract or concrete
trait may extend other traits
trait provides inherited methods as well as those declared in its declaration.

Scala Summary

2009-01-11T14:48:00.002+07:00

I have been reading Scala papers for a couple of days. Here's a quick summary from the first section of "An overview of the Scala programming language":

Scala fuses OOP and functional programming together.
Scala has been designed for construction of components and component system, which is a goal of software industry.
Components can be in any form, any size. Classes, libraries, frameworks, or processes can be considered as components.
Most existing languages offer only limited level of abstraction and composition.
The same concept of programming should be scalable to use for small as well as large programs.
Scala aims to be scalable by fusing OO and functional features into it.
Every value is an object, and every operation is a method call in Scala (uniform object model).
Functions are first-class values in Scala.
Scala has a unified abstraction for both types and values.
Scala provides constructs for composing classes and traits.
Scala provides object decomposition using pattern matching.

Syntax of Type Sheet

2008-12-11T07:42:00.001+07:00

It's beautiful, isn't it?

class(C) => { field(f) => f: String; method(m) && args(a) => { // bound a local(v) => v: int; // order of binding -> is left to right local(n) && call(Integer.minus(_)) && this(n) => return: int; call(print(n)) && match(n) { case call(Integer.plus(_)) => n: int; default => n: String; } }}

Online Twitter App written in Grails

2008-10-02T11:11:00.003+07:00

It is very exciting to tell you that we has now successfully used Grails to clone Twitter's Election. It seems to be a very first online Twitter application written in Grails. The most important thing is that the prototype has been done in just 2 days and we can have 2 Grails applications (a crawler with Quartz plugin to collect tweets, and a front to serve users) working together. Now it serves for the coming Bangkok Governor Election.

It is currently hosted by our lovely cloud, Morph Appspace.

Try it here: http://bangkok51.morphexchange.com

A non-English BDD framework

2008-09-20T15:35:00.003+07:00

I am a big fan of easyb, a BDD framework for Groovy and, of course you can use it to validate spec of your Java programs as it's running on JVM.

But what I really want to have is a support of my native, Thai, language. Recently found out that Groovy can compile UTF-8 code, and I have no problem to make it invoke some method with Thai characters. So, I have been porting the idea from easyb into my own, non-English BDD framework, TSpec.

Now you can tell a story of software specification in Thai, wanna learn it ?

Here's at Github.

Hangman in ZKGrails

2008-09-19T19:16:00.004+07:00

Actually, it's not for your eyes, but Robert Lee has found my hangman source code via Pastbin. Then he posted it on DZone, but what he mentioned is not 100% correct. This hangman app is built on ZKGrails, which is a ZK plugin for Grails (not only Groovy - check the language tag there in the source code it's 'GroovyGrails', not 'Groovy').

Hangman is the first challenge among us, a group of PAW66 developer sites in Thailand.(rails66, grails66, django66, seam66 etc.) We set this program up to show the power of each Web framework we love. I have blogged about this hangman in Thai on Grails66.com, if you can read. That's why I said it's not intended for your eyes.

One more thing I'd like to mention is that I host this app with Morph AppSpace. It's really cool that not only you can host Rails apps, all kind of my Java apps including Grails and even ZK just work there. You did the great job, guys !

Trust me, Grails will be a platform

2008-09-18T03:40:00.001+07:00

Recently, SAP has released its Composition on Grails 1.0, the world first Grails distribution outside the project itself.
Yes, I said it is "the world first Grails distribution". This is really important to me as the release sent out a special signal that "Grails" will be "something" more that a normal web framework on JVM.

Thanks to Grails plugin architecture, you are able to get its core (thinking of it as a Linux kernel), put some plugins and scripts (think of them as programs around Linux), pack them together and that's it ! You got a web framework distribution that contains special features !

For example, imagine that you can have a Blog-ready Grails distro, a distro that contains some preset plugins, which help you create a blog like Wordpress in minutes. Or you can have a CMS-ready Grails distro, which enable you to 'grails create-cms' and you've got a Drupal-like system.

This will be a big step to take Grails into the next level ! Trust me, it's going to be a platform !

Hey Guillaume Laforge, Thai Geeks are going to interview you

2008-08-28T06:49:00.005+07:00

After Groovy has been got the big attention in Thai community this moment, I've been co-operating with Isriya of Blognone.com (a leading technology news site in Thailand) to arrange an interview for Guillaume Laforge. This interview will be a community-based. All question will come from news readers, which of course are Thai geeks. After collecting questions there, I'll forward them to Guillaume via email.

This will be the first time for them to get in touch with him.

See the post (if you can read Thai): http://www.blognone.com/node/8770

Do anything at BarCamp Bangkok 2

2008-08-15T20:15:00.001+07:00

To help promote BarCamp Bangkok 2, here's my screencast:

http://screencast.com/t/JRZprfG6

Enjoy !

A Java-near-speed Groovy

2008-08-15T07:19:00.003+07:00

Almost 2 months that I have not posted here. I'm still in the final phase of Google Summer of Code. The world is going to be wonderful when you have got a really good result from your hard work, is that right ?

I'm currently be able to make Groovy speed step closer to Java. It's a high aim, and it's clear to be possible with JVMIT now. I was working on optimising callsites, but could not find a way to make it faster than Alex T.'s implementation because he did really good job of implementing it. So I went back to look at my old GJIT code. What I found is that something had been fooling my eyes for almost a year. There is a way to avoid JVM 6 specific code to implement an agent for JVM 5. Then I re-read AspectJ source again, and found something useful. I has started to re-write a GJIT agent for JVM 5 from then.

My prototype of the second generation of GJIT was done with Soot framework, where I really learned a lot of useful optimisation tricks (e.g., SourceValue). Later, I found that Soot is not suite for implementing JIT, because of 1. it's somewhat big structure 2. it's class loading problem. I then have had to implement a whole thing using ASM. It really was a nightmare because there is no Jimple to help your analysis. I re-wrote at least 3-4 version of ASM optimisers, and finally got the current one, which has a good enough structure to patch.

Now my goal is to beat all shootout benchmarks. Here's the result from partial sums benchmark compared with Java on my machine.

$ export JAVA_OPTS="-server"
$ time `java -cp bin alioth.PartialSumsJ 5000000`
real 0m10.246s
user 0m0.030s
sys 0m0.015s

$ time `groovy.bat test/partial_sums.groovy 5000000`
real 0m27.110s
user 0m0.030s
sys 0m0.016s

$ time `groovy.bat test/alioth/PartialSums.groovy 5000000`
real 0m28.409s
user 0m0.030s
sys 0m0.015s

$ export JAVA_OPTS="-server
-javaagent:C:\\groovy-ck1\\healthy\\target\\install\\lib\\gjit-0.1.jar"
$ time `groovy.bat test/alioth/PartialSums.groovy 5000000`
real 0m13.434s
user 0m0.030s
sys 0m0.030s

It's 200% faster than current Groovy, and ~20-30% slower than Java. There's still room to go. I hope to take some more steps closer to Java's speed.

Expression-Wide Optimisation (Primitive Callsite #2)

2008-06-21T06:24:00.002+07:00

This is a technique I proposed for optimizing Groovy primitive expressions.

Let's say, we have:

public double a(int i, int j) {
return 1 / ((i+j)*(i+j+1)/2.0D +i+1);
}

This expression consists of 7 callsites. If we can make sure that the following 3 conditions
1. All variables are primitive.
2. The metaclass of each callsite is default
3. The meta method of each callsite is default
are true, the we can replace the entire expression with primitive and native Java bytecodes. Thus, we can by-pass any overhead here.

When some meta-method has been replaced, then the above condition is invalid. The original code will be performed instead of the fast one.

This technique is reasonable to implement because:
1. Callsite makes this checking cheap. We can define "isDefault" flag for a "default" callsite.
2. Instead of checking the default flag one-by-one, checking these flags for a whole expression makes this even cheaper. This also results in easier code generation.

However, we have to generate code twice, say fast and slow paths, for each expression-to-be-optimised.

final boolean exprCallSet = $getExprCallSet(0);
if(exprCallSet) {
return 1 / ((i+j)*(i+j+1)/2.0D +i+1);
} else {
$reevaluateExprCallSet.get()[0] = true;
return DefaultTypeTransformation
.doubleUnbox(ScriptBytecodeAdapter.castToType(
acallsite[0].call($const$0, acallsite[1].call(
acallsite[2].call(acallsite[3].call(
acallsite[4].call(acallsite[5].callOII(i, j),
acallsite[6].call(acallsite[7].callOII(i,j),$const$0)),
$const$1),
DefaultTypeTransformation.box(i)),
$const$0)),
$get$$class$java$lang$Double()));
}

The above snippet is a mock code I'm working on. The next step is to generalise this and modify the Groovy class generator. With this technique, we can unleash all power of Java primitives which will be > 800% faster than the normal callsite caching in 1.6-beta1.

Primitive Callsite Again (Part 1)

2008-06-17T22:09:00.001+07:00

Current Groovy implementation always do boxing, unboxing regardless types of primitive parameters. This is the reason why it's slow down for arithmetic operations. I've come up with some experiments to optimise primitive for Groovy.

The idea is that I'll generate primitive callsite, or primitive calls when:

1. typing is obvious. For example,

int a = 5
int b = a * (a + 5)

in the above example, the second expression will have 1 box/unbox call and 1 primitive call because of type of (a+5).

With (a +5), this can be generated as Object call((int)a, (int)5) because type of a is obvious, also '5'.
But we won't know type of the result. So that a * (...) will be generated using Object call ((int)a, Object) rather than Object call(int, int).

One may argue that this might be not worth, as for a very long and complex expression this optimisation will be useless. For example,

private double a(int i, int j) {
return 1 / ((i+j)*(i+j+1)/2.0D +i+1)
}

The above optimisation can do it job only just for 2 inner most expressions. But you will be surprised that it's actually ~23% faster ! Thus IMHO, it's worth to do that.

2. This second part is to trying to optimise that long expression. The entire expression can be replaced with all primitive calls if only if their meta-class and meta-methods are "DEFAULT". I hope I could detect this via a property of CallSite, then generate 1. fast path, 2. original path. This second idea has not been fully experimented yet. So wait and see what can be done.

Proof-of-Concept Backport Invokedynamic in Groovy

2008-05-27T03:57:00.001+07:00

It is my first day of Google Summer of Code, and here is what I've done today ;-)

I have been reading hard and trying to understand Invokedynamic EDR since last week. It is quite difficult for me, who has little background of this kind of things. However, I have got some good sources for studying how invokedynamic work from John Rose's blog, Alex Tkachman's Method Handle code, Jeroen Frijters's blog, and Rémi Forax's blog.

Although, there is no something complex like Jeroen's sample, here is a working version of Hello World that uses my backport of invokedynamic APIs.

package groovy.dyn.subject.vm5;

import groovy.dyn.CallSite;
import groovy.dyn.Linkage;
import groovy.dyn.MethodHandle;
import groovy.dyn.MethodHandles;
import groovy.dyn.MethodType;
import groovy.dyn.StaticContext;
import groovy.dyn.internal.CallSiteImpl;
import groovy.dyn.internal.StaticContextImpl;

import java.io.PrintStream;
import java.lang.reflect.Method;

public class InvokeDynamicSubject {

private static CallSite[] callsites;
private static final int NUM_OF_CALLSITES = 1;

static {
initCallSites();
try {
Method method = InvokeDynamicSubject.class
.getDeclaredMethod("bootstrapInvokeDynamic",
CallSite.class, Object.class, Object[].class);
MethodHandle mh = MethodHandles.unreflect(method);
Linkage.registerBootstrapMethod(InvokeDynamicSubject.class, mh);
} catch (Throwable e) {
// do nothing now
}
}

private static void initCallSites() {
callsites = new CallSite[NUM_OF_CALLSITES];
callsites[0] = new CallSiteImpl(0,
new StaticContextImpl(
PrintStream.class,
"println",
MethodType.make(void.class, String.class)
)
);
}

private static Object bootstrapInvokeDynamic(CallSite cs,
Object receiver, Object[] args) throws Throwable {
Method method=null;
CallSiteImpl csi = (CallSiteImpl)cs; // down cast: language specific
switch(csi.index()) {
case 0: {
StaticContext sc = cs.getStaticContext();
Class<?&gt; c = sc.getCallingClass();
method = c.getDeclaredMethod(
sc.getName(),
sc.getType().parameterType(1));
MethodHandle mh = MethodHandles.unreflect(method);
cs.setTarget(mh);
return mh.invoke(receiver, args);
}
}
return null;
}

public void test() throws Throwable {
// System.out.println("Hello World");
MethodHandle mh = callsites[0].getTarget();
if(mh == null) {
bootstrapInvokeDynamic(callsites[0], System.out, new Object[]{"Hello World"});
} else {
mh.invoke(System.out, "Hello World");
}
}
}

Groovy, Bazaar and bzr-svn

2008-05-18T23:15:00.001+07:00

In the past, I was wondering how could I manage my Groovy fork (SVN is not good to do that because it's centralized nature). I was thinking to use SVK, but failed to set it up.

Today, Russel posted to groovy-dev that he set up a branch of Groovy on Launchpad. I have heard about Launchpad, but never tried to be its user. More that 2 hours that I have tried to set everything up.

I registered to be a Launchpad user, then forked my branch from Russel's one. OK, then what's next?
I'm still on Windows XP, so I need a set of putty programs for SSH. Later, I use PUTTYGEN to generate my public key and import it into Launchpad.

The next step is to download Python 2.5, Bazaar for Windows. Then, I installed bazaar and was able to branch Russel's trunk locally.

bzr branch http://bazaar.launchpad.net/~russel/groovy/trunk

After that I pushed it back to my branch.

bzr push bzr+ssh://chanwit@bazaar.launchpad.net/~chanwit/groovy/ck1

Then, something went wrong. I did not setup SSH properly. bazaar blamed me that I forgot to set BZR_SSH.

set BZR_SSH=plink

OK, here we go. Now everything went smoothly. I can push my local codes back to Launchpad. So I did clean and re-build Groovy to see if everything was fine. But hey !, the branch of Russel is out-of-date. I need the latest patch Alex just committed. So what to do?

I checked some docs on bazaar wiki and they said it is able to merge code from SVN using bzr-svn plugin. That sounds great to me. So I downloaded bzr-svn, but thing did not go smooth again. I need Python-Subversion binding with the special patches. Come on, where on the earth it is? Alright ! It seems I got everything to run bzr-svn.

I ran this command:

bzr merge http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/

but it was not successful. The document said it should be svn+http. How silly I am. I tried merging again:

bzr merge svn+http://svn.codehaus.org/groovy/trunk/groovy/groovy-core/

And it worked ! After that I did commit.

bzr commit -m "message goes here"

and push all committed code back to Launchpad again:

bzr push

Wow, it was fun and cool!. Now I can have my experiment branch without missing any new patch from the main trunk! That's great, isn't it?

My SPLAT 2008 Homework

2008-03-26T05:27:00.000+07:00

Using Groovy AOP to express business logics in Grails framework

This document describes a number of problems found in the scenario of applying Groovy AOP to Grails framework that reflects Comprehensibility.

From http://grails.org,

"Grails aims to bring the "coding by convention" paradigm to Groovy. It's an open-source web application framework that leverages the Groovy language and complements Java Web development. You can use Grails as a standalone development environment that hides all configuration details or integrate your Java business logic. Grails aims to make development as simple as possible and hence should appeal to a wide range of developers not just those from the Java community."

There are high-level artefacts e.g., Controllers, or Domain classes in Grails framework. An AOP language needs a good design to cover high-level pointcuts for expressing such software artefacts in Grails. Moreover, Grails is extensible via its plug-in system. A developer can define their own artefacts in a newly developed plug-in. For Grails, the AOP language needs to be extensible to capture join points introduced by these artefacts.

For example, Groovy AOP comes with a set of primitive pointcuts like:
- pcall(pattern)
- etc.

But these do not reflect the semantics of Grails artefacts. Their users need some PCDs like:
- controller(pattern)
- action(pattern)
- etc.

Here is an example of a web application written using Grails.

class BookController {
def list = {
def books = Book.list()
render(view:'book', model:[books: books])
}

def show = {
...
}

def update = {
...
}
}

An aspect written in Groovy AOP:

aspect SecurityAspect {
def pc = pcall('BookController.*')
around(pc) {
// check access
}
}

An aspect written in Groovy AOP, with a higher level of PCDs:

aspect SecurityAspect {
def pc = controller('book') & action('*')
around(pc) {
// check access
}
}

An aspect written using a variant syntax Groovy AOP, with a higher level of PCD (shortcut form):
This syntax is probably preferred by the developers, according to idioms they are familiar with.

aspect SecurityAspect {
around(controller:'book', action:'*') {
// check access
}
}

Groovy AOP also needs to support a good way to be able to extend and cover a new software artefact added through Grails plugin system as well.

Conclusion

As a general purpose AOP system for Groovy, Groovy AOP can be used with Grails framework. It may help expressing business logics as application-level aspects. However, the implementation of Grails framework is dynamic because a developer can add a new software artefact by creating a plug-in. To make an AOP system meets this requirement, it should support the ability to define new PCDs through the same plug-in architecture.

Ability to understand by developers ?
- A system should provide idioms that developer are familiar with in the AOP language
Ability to evolve & customize ?
- A system should provide the way to define new PCDs
How well does AOSD support/go along with Comprehensibility?
- Depends on its implementation, and its base language (e.g. Java / AspectJ, Groovy / Groovy AOP). Currently, Groovy AOP has not support this approach well yet.

Composite Id and FK as PK in GORM

2008-03-23T00:48:00.001+07:00

I've been discussing with my colleage about how to map 2 classes in GORM. It's a bit complicated, where we need to use the foreign key from one, Process, class to be the primary key for another class, State.

Code listing as follows:

class Process implements Serializable {

String name
static hasMany = [states: State]

}

class State {

String stateId
Process process

static mapping = {
version false
id composite:['stateId','process'], generator:'assigned'
}

}

Don't forget to use obj.save(insert:true), when you have a GORM mapping with version=false and generation='assigned'.

You see, life is much more easier with GORM.

G2One's released Grails 1.0.2

2008-03-21T02:47:00.001+07:00

The team has just released the simple but powerful Web framework on JVM, Grails 1.0.2. I've also uploaded its Installer for Windows. Check them out.

G2One Inc (http://www.g2one.com) and the Grails development team are
pleased to announce the release of Grails 1.0.2, which includes 84 bug
fixes and improvements. The release is available to download from http://grails.org/Download

Fixes in this release seem to focus on GORM component.

From: Grails.org

OpenLaszlo 4.0.10 released

2008-02-22T07:15:00.001+07:00

OpenLaszlo 4.0.10 is released today. It seems to contain a lot of bug fixed (compared with 4.0.9). This version is getting closer to 4.1, which will be the production version that supports DHTML runtime.

I'm really looking forward to use 4.1, but now it's time to upgrade one of my production application to use 4.0.10.

Source: OpenLaszlo.org

Grails Popularity Indicator?

2008-02-09T01:56:00.001+07:00

Just got this nabble link from Graeme's blog. It's sure to show how much popularity of Grails to date.

Matrix computation environment over Hadoop/HBase

2008-02-05T04:09:00.000+07:00

I've been forming up the Hama project with Edward Yoon.
He's been doing the really great job of getting matrix computation work over Map/Reduce pattern. Now we are planning to have a MATLAB-like environment for them.
Here's a number of issues:

- The language needs to support lazy evaluation,
for re-arragement of a numerical expression to properly pick the right algorithm before computation.

I love Groovy, so it's time to develop the Groovy-derived langauge that suites numerical computing.

- Support BigDecimal, BigInteger by default.
Yep, we're again looking on large-scale computation, and sometime it's beyond the integer's boundary.
So we need the built-in support for these kinds of data type.

- Matrix and Vector to be the first class elements. For example,

def a = [1 2 3] // this is going to be a Vector
def b = [1 2 3; 4 5 6; 7 8 9] // this is going to be a matrix

while,

def a = [1, 2, 3] // this is going to be an ArrayList
def a = [a:"a"] // this is going to be a HashMap

- Java integration in the same spirit as Groovy
So it should compile to bytecode.
Compile code will be exactly Java class, not like e.g., JRuby compile .class, in which contains a lot of specific magic

- Support Closure
An anonymous closure will be inlined, whilst a normal closure will be encoded as an inner class.

More to come ...

Dataflow Analysis with ASM 3.1 and StackMap

2008-01-13T02:04:00.000+07:00

Very surprised that I've got a huge benefit from stack map feature of Java 6.

I'm trying to do some dataflow analysis over compiled Groovy classes, and what I've found in ASM 3.1 is that it comes with method visitor for doing this for me. I've just added some partial evaluation for constants (for almost kinds of JVM instructions with a constant as their operand) and when the visitor visits method instruction, like INVOKESTATIC, I've got type information of each wrapped arguments (Groovy uses Object[] to hold them for dispatching the call with ScriptBytecodeAdapter).

Now my new unwrapping meta-method algorithm is blazing fast. Thanks ASM guys !!.

Application-Specific Performance Tuning for Groovy

2008-01-06T08:07:00.000+07:00

You all know that if we bypass meta-layer of Groovy, the performance will be boosted. I have 1 class, 1 closure (as an inner class) and 3 method calls in the following codes (System#currentTimeMillis, times, and println):

package org.codehaus.groovy.aop

class Test {
static void main(args) {
def s1 = System.currentTimeMillis()
1000000.times {
int i = 10
println "test ${i}"
}
def s2 = System.currentTimeMillis()
println "time: ${s2-s1}"
}
}

I have 100% confidence that those calls won't be dynamic. Then I can have an aspect (written in AspectJ) applied to them for the performance reason. Although, it's quite complicated piece of codes here, but at least your application will be faster.

public aspect TestBooster {

pointcut inv_println(String methodName, Object[] params):
call(static * ScriptBytecodeAdapter.invoke*Method*N(..)) &&
(
withincode(public static void org.codehaus.groovy.aop.Test.main(..))
|| withincode(public Object org.codehaus.groovy.aop.Test$_main_closure1.doCall(..))
)
&& args(..,methodName,params)
&& if("println".equals(methodName));

Object around(String methodName, Object[] params):
inv_println(methodName, params) {
DefaultGroovyMethods.println((Object)null, params[0]);
return null;
}

pointcut inv_times(Object self, String methodName, Object[] params):
call(static * ScriptBytecodeAdapter.invokeMethodN(..)) &&
(
withincode(public static void org.codehaus.groovy.aop.Test.main(..))
)
&& args(Class,self,methodName,params)
&& if("times".equals(methodName));

Object around(Object self, String methodName, Object[] params):
inv_times(self, methodName, params) {
DefaultGroovyMethods.times((Number)self, (Closure)params[0]);
return null;
}

}

The above aspect is for by-passing calls to "times" and "println" with the replacement of the real targets. The woven code is averagely 15% faster (in both client and server VM) because the call distance is shorten from 36 levels to 17.
With this technique, you can apply the optimisation in the way you want just before you deploying the app (without touching your source). Anyway, don't forget to do the regression tests after the optimisation ;-).

Inlining closure

2007-12-26T00:53:00.000+07:00

I did some manual experiments of inlining the body of closure from the previous post to make it fast. So far the inlining technique would work only for anonymous closures as it won't be referred by other codes.

For example, if a$a is an anonymous closure:

DefaultMethods.times(100, a$a);

can be inlined as the private method inlined_DefaultMethods_times:

inlined_DefaultMethods_times(100);

Then the body of DefaultMethods#times will be copied to construct the above private method. After that the callsite of Closure a$a will be replaced with its body, the method a$a__0.

The original DefaultMethods#times:

public static void times(int num, Closure closure) {
for(int i=0;i<num;i++) {
closure.call(i);
}
}

The inlined method inlined_DefaultMethod_times:

private void inlined_DefaultMethod_times(int num) {
for(int i=0;i<num;i++) {
a$a__0(i);
}
}

The result is reallly impressive, 22 sec, which is comparable to original Java code.

Steps toward encoding fast closures, reflection-based closure

2007-12-24T03:31:00.000+07:00

With the reflection-based closure approach from last post, I've got some codes to compare performance.

The following is a Groovy code,

class TestGen_002 {
def a = {
1000000.times {
println it
}
}
}

And this is the manually translated code. Class TestGen_002 contains reflection-based closures, a and an anonymous closure for times.

package org.codehaus.qdg;

import org.codehaus.groovy.qdg.Closure;
import org.codehaus.qdg.runtime.DefaultMethods;

public class TestGen_002 {

public Closure a = new Closure(this, "a__0");

private Object a__0(Object... args) {
Closure a$a = new Closure(this, "a$a__0");
DefaultMethods.times(1000000, a$a);
return null;
}

private Object a$a__0(Object... args) {
System.out.println(args[0]);
return null;
}

}

Although it's fast, 28 secs, compared with traditional Java for loop (22 secs). I've been trying to get its speed closer to Java.

Implementing Closure without using inner classes

2007-12-24T00:22:00.000+07:00

This implementation is inspired from Charles Nutters' discussion about his experiences implementing JRuby. I didn't have much time to look into it, until now. So here's my first implementation of it.

I have my Closure field a, and its body a_body.
In the Closure class, the ctor will reflectively get the declared method "a_body" by name.
When you'd like to invoke the closure, just call a.call(). Then it will normally invoke the "a_body" method with reflection.

package org.codehaus.qdg;

import org.codehaus.groovy.qdg.Closure;

public class TestGen_001 {

public Closure a = new Closure(this, "a_body");

private Object a_body(Object... args) {
System.out.println(args[0]);
System.out.println("a_body");
return null;
}

}

And here's a simple implementation of the class Closure:

package org.codehaus.groovy.qdg;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.security.AccessController;
import java.security.PrivilegedAction;

public class Closure {

private Object target;
private Method method;

public Closure(Object target, String methodName) {
this.target = target;
try {
method = target.getClass().getDeclaredMethod(
methodName, new Class[]{Object[].class});
AccessController.doPrivileged(
new PrivilegedAction(){
@Override
public Object run() {
method.setAccessible(true);
return null;
}
});
} catch (SecurityException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
}
}

public Object call(Object... args) {
try {
return method.invoke(target, (Object)args);
} catch (IllegalArgumentException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
return null;
}
}

A closure body, which is a private method, is accessible by setting Method#setAccessible(true).

Quasi Dynamic Groovy

2007-12-23T09:06:00.000+07:00

I'm trying to summarise what I want from Groovy.
One of my goal is to use Groovy for numerical computing. I love Groovy syntax because it's concise, compact, and elegance when writing an algorithm. So I've started writing code generator from Groovy parser. It's relatively easy to start, if you have .jar distribution of Groovy.

Here's a list of my requirements:
- Partially static Groovy
- AOP support by design, at the level of the runtime system.

Challenges so far are:
1. Is it possible to make a Groovy class partially static? IMO, I think it would. The support reason is very obvious. Now, we can mix Groovy and Java classes in the same system.
So what if we resolve method references at compile-time. If the method reference is found we make it static, if not we just make it dynamic.
2. Is it possible to use the envelope technique to wrap around method calls, getters, setters, etc.
This technique can be used to have a dynamic AOP support.
3. How to keep the class semantic to be as similar as possible to the classic Groovy.

Groovy AOP - Part #4, Getter and Setter PCDs

2007-12-10T16:41:00.000+07:00

I haven't implemented pointcut designators (PCDs) for getter and setter because I actually forgot about them.

I recall them this morning, and really see the advantage of using them for Grails domain classes. I think using it can definitely solve the problem's been caused by Hibernate setter issue. Here's the situation.

I have the domain class, User containing the password field passwd:

class User {
...
String passwd
}

What I wanted to do is to store MD5ed password by just calling new User(password:'abc').save(). But this won't work. It's the Hibernate limitation that does not allow me to have the setter for passwd, say setPasswd, because the setter will be called, at least, twice when Hibernate 1. initialises the object, 2. sets the value into the property. Yes, I got my password hashed twice !

So here can be a solution (I have to try it first to confirm this anyway).

Groovy AOP can provide a shortcut for getter and setter like:

class User {
static aspect = {
before(set:'passwd'){ value -> value = MD5(value) }
}
...
String passwd

}

Why this's going to work? I think it works because Groovy AOP works at meta-layer, while Hibernate works at bytecode (proxied) layer. It's possible for Hibernate to set the property directly (as it does not invoke the call through Groovy invoker). Good use case?

Groovy AOP - Redesign #3, Advise By Convention

2007-12-08T23:02:00.000+07:00

This idea came solely from seeing what Grails's using for interception.
The idea is simple, like ActiveRecord pattern used in Grails (e.g., find*)

In Grails, users'd like to have before, after interceptions for their controllers, domain classes, etc.

Like this:

class MyController {
static beforeInterceptor = ['*', this.&auth]
}

and this:

class MyDomain {
String field1

static beforeUpdate = {
}

}

So Groovy AOP would support these kind of functionalities with conventions in its aspect language like the following for controllers:

MyController {
static aspect {
beforeAll { println 'test' } // = before(call:'*') { }
beforeUpdate { println 'test' } // = before(call:'update') {}
}
}

and following for domain class dynamic methods:

MyDomain {
static aspect = {
beforeSave { }
beforeUpdate { }
afterUpdate { }
afterSave { }
beforeNew {}
}
}

To sum up here, what Groovy AOP should support in its aspect language are before*, after*, and around* to simplify the use of AOP in practice.

Groovy AOP - Redesigned #2

2007-12-03T21:57:00.000+07:00

OK, I'm now continuing to show that what've I made changes to the syntax of Groovy AOP.
Last post, I've showed the new syntax, and there's a few more tweaks here.

In the trunk, now we can have aspect like this:

class MyClass {
static aspect = {
before(call:'update1') { println 'before update 1 ..'}
after(call:'update2') { println 'after update 2 ..' }
}
}

and this:

class MyClass {
static aspect = {
before('update1') { println 'before update 1 ..'}
after('update2') { println 'after update 2 ..' }
}
}

Both have the same semantic. They read, before the call of (join point of) MyClass#update1, do ..., and after the call of (join point of) MyClass#update2 do ...
I think these shortcuts will be comfortable enough for people to use without AOP knowledge.

The implementation's also changed internally to override MetaClassImpl#invokeMissingMethod rather than MetaClassImpl#invokeMethod.

Groovy AOP - Aspect Builder Redesign #1

2007-12-03T08:50:00.000+07:00

I've just got Groovy AOP running first time with Groovy 1.1, and seriously I'm looking to integrate it with Grails when its 1.0 debuts. My problem now is still the classic AOP problem, how could we have an expressive and easy pointcut language for people?

I know that advantages of Groovy AOP to Grails are quite clear, but if and only if developers uses it. So I'm trying to re-design the pointcut language before getting 0.3 out.

class MyController {
static aspect = {
before(call:'*') { println 'something' }
before(withIn:'') { }
around(call:'update*') { inv ->
println 'before'
inv.proceed(inv.args)
println 'after'
}
def pc = call('update*') & within('main')
around(pc) { inv ->
println 'before'
inv.proceed(inv.args)
println 'after'
}
}

def update() {
}

def update2() {
}
}

Above is how we can embed "aspect" into Grails controller. I intend to leave the "static aspect" block to say that "hey, you're using AOP here". Don't know if people will have objection to this.

The shortest code we can use to have "before interceptor" for every method in the class is:

static aspect {
before(call:'*') { println 'before' }
}

Tomorrow, I'll continue with next thought about this.

Groovy equivalence to Chapel's code

2007-11-30T05:56:00.000+07:00

Ability to have our own DSL in Groovy makes it possible to have a high-level language for parallel computing. I'm trying to clone all features of Chapel to Groovy and then optimise the generated codes to make it run (I hope) fast.

int n = 1000
def A = new Vector(size: n)
def B = new Vector(size: n)
forall(2..n-1) { i ->
B[i] = ((A[i-1] + A[i+1])) / 2
}

Hello Android, Are you wanting to sit on Grails?

2007-11-13T08:32:00.000+07:00

Google's released Android SDK yesterday. After quick skimming on packages supported by the SDK, here what I can summarise,
- android packages, UI + 2D + 3D, SAX, DB, device APIs, OS calls
- java packages, java.nio, and java.concurrent (including atomic)
- httpcli
- JSON support
- cryptography, SSL
- Bluetooth support
- Google Map APIs
- XMPP

It seems to be not Java ME packages, but likely the striped down version of Java SE. So I think this could be possible to make quite complicate applications.
My first try here is not about making an app, but I'll see if I can have some templates to generate Grails scaffolding for it. If this can be done in a month, a full-blow application with Grails as a back-end will be easily developed. And it's going to be a big boosting up.

Does Grails need a real compiler?

2007-11-07T04:48:00.000+07:00

We all know what a DSL is, so what's about a domain specific compiler (DSC)?

I've just accidentally seen Grails 1.0-RC1's been invoking its compiler during my work. So I think it's possible to have a DSC to support Grails in someway. It could be definitely based on the Groovy compiler with addition Grails knowledge. For example, in a Grails controller, we can use "render" method to render things like XML, JSON. What if we can compile this render block into a real XML, or JSON chunk embedded in the controller, rather than invoking the dynamic method.

In the development time, we've got Grails running fine and it offers us a great rapid environment. So we just keep using the original Groovy here. And if we have DSC, and it works just before grails war, then our Grails apps performance will be really great during its execution.

Convention over Configuration for Map-Ruduce

2007-11-04T04:43:00.000+07:00

I'd just like to have a quick look to Hadoop's word-count example, if it can be written in Groovy.

Disclaimer: this code doesn't work !

class WordCountMapReduce {
def map = {key, value, output, reporter ->
def line = value.toString()
def itr = new StringTokenizer(line)
while(itr.hasMoreTokens()) {
word.set(itr.nextToken())
output.collect(word, one)
}
}

def reduce = {key, values, output, reporter ->
int sum = 0;
values.each {
sum += it.get()
}
output.collect(key, sum)
}

}

It's time for Groovy to go fore massive computation?

Profiling Groovy Meta-layer

2007-10-15T05:09:00.001+07:00

I'm planning to profile the meta-layer of Groovy. What I'm looking for in this profiling is a number of arguments needed by methods of general applications.

Currently, ScriptByteCodeAdapter#invoke* alway use Object[] as a wrapper of a target method's arguments when dispatching it, and it's difficult for my JIT compiler to replace it with a new call, as suggested by Charles Nutter that my dataflow analysis may be time-consuming. So I came up with the idea of profiling.

There are invoke*0 and invoke*N in ScriptByteCodeAdapter class, and I think there would be invoke*1, invoke*2 ... invoke*K, where K is a threshold number found by the profiler. Then the class ASMClassGen would be patched to generate these newly added methods.

How does Groovy AOP relate to GIT?

2007-09-10T06:05:00.000+07:00

GIT is the name of Groovy just-in-time compiler, which is being developed. I'm using it as an underlying layer for Groovy AOP.

MetaClassImpl, the default meta-class of Groovy, picks a call for each invocation, which is a joinpoint in AOP theory.

GIT is trying to optimise this invocation process by checking the change of a MetaClass of each class. It replaces the meta-call with the real call, which is returned by the MetaClass. Weaving process in Groovy AOP will take the similar approach. But when MetaClass picks a real call, it would return "WovenMetaMethod" that contains also "before", "after", and "around" information. The runtime weaver then uses this information to generate an equivalent list of bytecode instructions and use them to replace the meta-call.

This is how GIT relates to Groovy AOP.

An ERP built with Grails

2007-09-08T01:47:00.000+07:00

I've setup the project called Geogia at Google Code for developing an ERP system using Grails. All domain classes are being re-written based on UML diagrams of project Neogia. Gentleware AG kindly sponsored Poseidon UML CE edition for this project. Thank you :).

This project is being developed using version 0.6 of Grails.

Xfire plugin for Grails 0.6 released

2007-09-07T10:50:00.000+07:00

Nothing's fancy. I've just released my latest Xfire plugin for Grails 0.6.
It's now available from Grails plugins repository.

This command:

$ grails install-plugin xfire

is enough to give it a go.

A few note here, it uses Xerces 2.8.1, where Grails ships with 2.6.2. Just in case for any incompatibility.

Dynamic Recompiling a Groovy Class

2007-09-04T09:46:00.001+07:00

After we identified an invariant dynamic call, the call replacement technique could be applied to the caller method. The following describes an early version of the algorithm to do so:

1. find an invocation statement to ScriptBytecodeAdapter
2. determine a number of parameters that the statement needs.
2.1 if the number of parameters = 3, this invocation has no argument.
2.2 if the number of parameters = 4, this invocation has a set of arguments.
3. statically unwrap the last parameter passed to this statement
(note that Groovy's using Object[]
to wrap a set of method arguments,
and we need to unwrap and pass them
to the new invocation statement)
3.1 in this step, we can also clean up unneeded the Object[] variable
and its assignment statements.
4. construct the new invocation statement,
using information gathered from the profiler.
(we can not infer the target class using
any information provided by the statement,
because the real call will be chosen by Groovy meta-class).
5. fix object casting, this can be done by traversing backwardly
to the statement prior to the invocation.
Then change casting type from GroovyObject
to the correct type (also get this value from the profiler)

The result so far:

$r19_2 = $r19;
goto label7;
label6:
$r19_2 = org.codehaus.groovy.aop.tests.Target.class$groovy$lang$GroovyObject;
label7:
$r20 = ScriptBytecodeAdapter.castToType(r0, $r19_2);
$r21 = (org.codehaus.groovy.aop.tests.Target) $r20;
$r23 = $r21.method2("test");
$r18[$i0] = $r23;
$r24 = ScriptBytecodeAdapter.invokeMethodOnCurrentN(r2, $r16, $r17, $r18);
return $r24;

Bytecode incompatibility

2007-09-03T08:05:00.000+07:00

Last post, I've blogged about using Soot to optimise class files. Soot is alright for me when I used it as a generator. But in the dynamic context, I've got some compiled classes from the different generator (say Groovyc), but I'd like to get them optimised with Soot and then re-define then with the Intromentation. This approach completely failed as Soot-compiled classes have different attributes compared with the original classes.

After this problem's kept me busy for a couple of days, I've came with a solution to use Javassist, another bytecode manipulation to help me re-mix two different versions of class.

I got the original class from Javassist class pool, removed the old target method. Then I loaded the Soot-optimised class from disk, using Javassist's ClassFile, and took only the optimised target method from it. After that I created a new MethodInfo for that method with constant pool of the original class and then I added it to the original class. I finally obtained its bytecode and give it to Intrumentation for class re-definition.

soot.Main.main( new String[]{
"-d",
"mydir",
"-via-shimple",
className
});
try {
String fname = "mydir/"+ className.replace('.', '/') +".class";
ClassPool cp = ClassPool.getDefault();
CtClass target = cp.get(className);
target.defrost();
String mName = "main";
ClassFile srcClassFile =
new ClassFile(new DataInputStream(new FileInputStream(fname)));
MethodInfo srcMethodInfo =
getMethod(srcClassFile, mName, "([Ljava/lang/String;)V");
MethodInfo newMethodInfo =
new MethodInfo(target.getClassFile2().getConstPool(),
mName, srcMethodInfo, null);
target.removeMethod(target.getMethod(mName, "([Ljava/lang/String;)V"));
CtMethod newMethod = CtMethod.make(newMethodInfo, target);
target.addMethod(newMethod);
Instrumentation i = Agent.getInstrumentation();
i.redefineClasses(
new ClassDefinition[]{
new ClassDefinition(Class.forName(className), target.toBytecode())
});
} catch (Exception e) {
e.printStackTrace();
}

Tell me, if you have a better idea !!

Optimising Groovy bytecodes with Soot

2007-08-21T18:51:00.000+07:00

I'm playing around Soot framework and get some optimised bytecodes after applying its default optimisation to Groovy-generated classes.
This does not help much for speed improvement, but I think it could help reduce the usage of PermGen space.

I've tested with a trivial class, and its file size after optimisation is 8.5% shrinker than the original. I'm expecting that this figure would be large if we optimise a whole application.

Possible JIT for Groovy with JVMTI

2007-08-08T18:38:00.000+07:00

Nothing involves Groovy bytecode analysis at the moment, but I show you here the possible way to re-define a Java class with a Java 6 JVMTI agent. Yes, I say Java 6 as Java 5 does not support class re-definition through java.lang.instrument package.

As you might know, several AOP systems, that enable load-time weaving, use class transformation at load-time to weave aspects to the existing programs. They use a java JVMTI agent to achieve this.

Now in Java 6, you can do a bit more further as it offers method

Instrumentation.redefineClasses(ClassDefinition[] defs);

I'm experimenting this technique with a normal class, here:

package org.groovy.git.test;

public class TestClass {

public void myMethod(){
System.out.println("a");
}
}

The re-definition process is performed just to change a TestClass object from printing "a" to printing "b".

package org.groovy.git.test;

import java.lang.instrument.ClassDefinition;
import java.lang.instrument.Instrumentation;

import javassist.ClassPool;
import javassist.CtClass;
import javassist.CtMethod;

import org.groovy.git.Agent;

public class AgentTest {

public static void main(String[] args) throws Exception {
// get an instrumentation from the agent
Instrumentation i = Agent.getInstrumentation();

// here, print "a"
TestClass t1 = new TestClass();
t1.myMethod();

// doing bytecode manipulation,
// replace a new method body for "myMethod"
CtClass ct = ClassPool.getDefault().get(TestClass.class.getName());
CtMethod m = ct.getDeclaredMethod("myMethod");
m.setBody("{ System.out.println(\"b\");}"); // make it printing "b"
byte[] bytes = ct.toBytecode();

// prepare a new class definition
ClassDefinition[] def=new ClassDefinition[1];
def[0] = new ClassDefinition(TestClass.class, bytes);
i.redefineClasses(def);

// this shows "b"
TestClass t2 = new TestClass();
t2.myMethod();
}

}

You might see that the above code get instrumentation from the Agent class, which is in a jar loaded by -javaagent:jarfile. In this experiment, I use Javassist for bytecode manipulation.

As you expected, the above code will show:

a
b

as the TestClass has been re-defined and its method, myMethod, body's been replaced.

Groovy AOP coming soon on the desktop near you.

2007-07-16T22:13:00.000+07:00

I've just committed the early Groovy AOP's grammar, its compilation unit, and ant task. Actually, everything is getting to work now, but I'd like to add some advice caching mechanism to have, at least, some performance impression.

I'm trying to have it released by the end of this month (July 2007).

If you'd like to see what's going on in the mean time, check out its SVN.

XFire plugin for Grails 0.5 released

2007-05-05T04:35:00.000+07:00

I've released the XFire plugin for Grails 0.5 recently. Now it's using XFire 1.2.6 and
Its forked aegis engine has been updated as well. In Grails 0.5, the Artefact APIs for plugin development has been introduced. All Grails core artefacts (domain, controller, etc.) are moved to use these APIs.

This week seems to be a 0.5-plugin-release week. Beside my XFire, we now have Tsuyoshi's Acegi, Sigi's converters, and Peter's remoting plugins running for 0.5. Check them out on Grails Plugins Page.

JIT dynamic weaving for Groovy AOP

2007-05-01T18:59:00.000+07:00

From the previous post, I was talking about selecting metaclass using pattern will give some benefits for AOP in Groovy. Now I come up with a cool idea of what is that benefit. The point here is about MOP infrastructure of Groovy is flexible enough by letting us to change the metaclass of any class at runtime, and this allow JIT (Just-in-Time) dynamic weaving of aspects for Groovy.

What does it mean by JIT dynamic weaving?

In my current implementation of Groovy AOP, there's a big overhead of matching pointcuts and invoking advices in the AOP metaclass, but this process can be improved by assigning a new, optimised, metaclass to the woven class. This new metaclass will be generated at runtime (using any bytecode manipulation framework) and it will contain a minimum set of instructions for invoking advices (no more matching process). However, there're still some important open questions like conflictions, etc. that need to be further investigated.

I'm pretty sure that this technique can improve some performance for Groovy AOP. Although, it's obviously slower than AspectJ, but it's worth comparing.

Groovy running fine on .NET

2007-04-28T05:37:00.000+07:00

It's just a crazy idea to test Groovy on .NET, after I read this post on IKVM weblog that the author test IKVM using JRuby. If JRuby runs fine, probably Groovy does so.

Simple steps here,

1. Download .NET 2.0 Runtime.
2. Download SharpDevelop IDE 2.1, just in case that you're lazy enough to code.
3. Download IKVM for .NET 0.34 rc2 binary
4. compile your Groovy jar with the following command:

ikvmc -target:library groovy-all-1.1-SNAPSHOT.jar

Some errors will appear, just ignore them.
You'll get groovy-all-1.1-SNAPSHOT.dll.

5. Open SharpDevelop, create a new .NET console application.
6. Add references, all IKVM DLLs and your groovy DLL.
7. Open your main class, type the following code (in C# for example)

using System;
using System.Collections.Generic;

namespace GroovyDotNet {
  class MainClass {
    public static void Main(string[] args) {
      groovy.ui.InteractiveShell.main(args);
    }
  }
}

8. Run the program, and you'll also have an executable file as well.

Alright, if you don't want to get your hand dirty, do step 1 and wait for the binary. I'll upload it soon.

Update:
Here's the screen shot.

and here's the binary.

Patterns for selecting metaclass will allow better support AOP in Groovy

2007-04-24T23:22:00.000+07:00

I'm still being with quantification thoughts for dynamic AOP.

There're some diffirences between dynamic and static weaving implementation. I'm saying about what AspectJ does, and what I'm going to do with Groovy AOP.

In AspectJ, it's focusing on static weaving for better performance. The idea behind is that every dynamic joinpoint has the corresponding static shadow, which is projected on source or bytecode of the target program. All quantifying will be done by AspectJ compiler to match every defined pointcuts, of course, at compile-time or load-time. Easy kinds of quantifiable joinpint are, for example, constructors and methods.

But nothing like this exists when we're talking about dynamic AOP. Dynamic AOP has nothing to do about 'static' shadows. This kind of weaving allows re-definition of aspect at run-time. Dynamic joinpoint in Groovy is powerful and a bit more complex to implement because of its MOP mechanism. Every class in Groovy has its own Metaclass to control the behaviour. ACtually, from AOP perspective, the metaclass can be though of as a basic per-target aspect. But when we're saying about AOP weaving, it allows multiple aspects to weave into a single target class. Comparing with MOP in Groovy, it's clear that AOP is somehow more powerful. In case of my AOP implementation, I have the AOP-metaclass to help dispatching advices.

So what's more ?

To fully support AOP quantification in Groovy, I came up with pattern matching idea to assign a metaclass for the target class. I'm feeling strange with this. I'm thinking of it as a good way to support pointcut-advice AOP model for Groovy. But there's something interesting about it that's beyond my head.

I hope I can figure it out soon.

Ubuntu 7.04

2007-04-22T17:46:00.000+07:00

Ubuntu Linux 7.04 came out, I did upgrade and everything goes fine.
Many guys in Java community get excited that JDK 1.6 is already in it's repository. My OpenOffice got updated to 2.2 as well, and that's great.

I've also tried it in VMWare player and, of course, there's no correct driver for 7.04 at the moment. The problem I have is just about the mouse. But it's not a big deal, I tweaked XOrg.conf and set the driver back to the original one ("mouse" instead of "vmmouse").

My new Ubuntu experience has just started !

AOP for Groovy is here !! Code moved to be Grails-AOP

2007-04-21T18:17:00.000+07:00

AOP for Groovy is here !

I've just refactored and uploaded my AOP subsystem into the Grails-Plugins repo. Anyway, it cannot say that this AOP implementation is Grails-Plugins. It's likely to be a drop-in module because it contains ObjectMetaClass that will hook into system-wide metaclass instantiation process.

This is an AspectJ-like, the pointcut-advice model implementation of AOP for Groovy. Both 2 important properties of AOP, Quantification and Obliviousness, has been implemented by design.

Browse the repo: http://svn.codehaus.org/grails-plugins/grails-aop/

The ways to express pointcuts, the choice is yours

2007-04-19T02:52:00.000+07:00

From the non-AOP programmers' perspective, the pointcut mini-language in AspectJ seems to be a bit difficult to learn. Before they can start writing some aspects, they need to know background concepts about join points, the way how to quantify them with a combination of pointcut designators, and the way how to express advice codes.

I cannot argue this because making pointcut languages simple yet powerful is quite an active research in the AOP area.

Some workaround to solve this problem could be having different kind of way to express pointcuts in one framework. So this means we're going to have several mini-languages inside the host language for describing aspects. They are what I'm going to implement for my AOP subsystem for Groovy.

For example, call() PCD is a quite common one you often use, so having:

Test.around['test*'] = {} instead of around(): call(Test.test*(..)) { }

can reduce the learning curve.

But when, the power of the basic pointcut language is not enough, you can use the full version of pointcut language, like this:

static aspect = {
def p = pointcut{
pcall('public *':'set*') & pcall( ... ) &
within(MyClass:'some*')
}
around(p) { context ->
proceed(context.args)
}
}

The choice of expressing pointcuts is just yours.

Aspect Groovy: Per class and Per instance

2007-04-16T03:21:00.000+07:00

From last post, I'm going to the next step by re-implementing my AOPSupportMetaClass again in Java to have some precise controls. Now the AOP metaclass got updated and support weaving both per class and per instance. However, the pointcut expression style is still based on John McClean's implementation.

This is for per instance weaving

def t = new TestObject()
t.around['save'] = { inv ->
inv.args[0] = inv.args[0] + '.'
inv.proceed(inv.args)
}
t.save('test')

And you can guess, this is per class weaving

TestObject.around['save'] = { inv ->
inv.args[0] = inv.args[0] + '.'
inv.proceed(inv.args)
}
def t = new TestObject()
t.save('test')

Last test code can be obtained from here.

Groovy and AOP Metaclass

2007-04-15T04:29:00.000+07:00

I've recently found John McClean's last year article about AspectJ-like AOP model implemented in Groovy. In its comments, his readers posted that he should have a custom MetaClass to support his approach. I'm sure he probably did it because he's going to talk about AOP in Groovy at Grails Exchange conference this May. However based on his implementation, I've done the similar MetaClass as well, as I need some kind of AOP facility to support my research.

Probably after the Grails Exchange event, I can see his AOP code somewhere.

Here's my implementation:

package org.plaop;

import groovy.lang.DelegatingMetaClass

public class AOPSupportMetaClass extends DelegatingMetaClass {

def after = [:]
def before = [:]
def around = [:]

public AOPSupportMetaClass(MetaClass delegate) {
super(delegate);
initialize();
}

public Object getProperty(Object object, String prop) {
if(prop == 'around') return this.around else
if(prop == 'before') return this.before else
if(prop == 'after') return this.after else
return super.getProperty(object, prop)
}

public Object invokeMethod(Object arg0, String name, Object[] args) {
if(before[name]!=null) {
before[name](inv)
}

def inv = new InvocationContext(methodName: name, args: args, called: arg0)
inv.proceed = { arglist ->
super.invokeMethod(arg0, name, arglist)
}

def result = null
if(around[name]!=null) {
result = around[name](inv)
} else {
result = super.invokeMethod(arg0, name, args)
}

inv.proceed = null

if(after[name]!=null) {
after[name](inv)
}
return result
}
}

This is how to use it:

void testBasicAround() {
def mcr = InvokerHelper.getInstance().metaRegistry
AOPSupportMetaClass amc = new AOPSupportMetaClass(
mcr.getMetaClass(TestObject.class))
mcr.setMetaClass(TestObject.class, amc)

def t = new TestObject()
t.around['save'] = { inv ->
inv.args[0] = inv.args[0] + '.'
inv.proceed(inv.args)
}
t.save('test')
}

The big bug here is that this MetaClass hasn't yet supported per class weaving model. But it's not that hard to implement. John's article really realised me the power of Groovy MOP from AOP perspective.

Invariant Dynamic Calls

2007-04-08T21:26:00.000+07:00

Basically, dynamically typed languages, Groovy in this context, dispatch calls by firstly choosing appropriate methods, then invoking them. The choosing process is obviously expensive. Several techniques, such as method caching, are currently implemented in Groovy to speed things up. However, choosing methods through reflection won't allow JIT to optimise method bodies for callers. With caching, the shortest steps for Groovy are still:

calling an invokeX method -> looking up cache -> calling the cached chosen method,

and you can not further optimise the invocation beyond this point.

The only way to do this is to simply replace that call by the chosen method call.
It's basic and everyone on the groovy-dev list knows about this (I supposed). Anyway, there're a lot arguments in the list that we should preserve the "dynamicity" of Groovy. I agree with those arguments, so we should leave Groovy core as it is, but we can really do somethings at the application level, in production phase.

During unit testing, developers may find sets of "invariant dynamic calls" of their applications. I roughly define an invariant dynamic call as a call that has only one chosen method. Trivial examples for this kind of call in Grails framework are Domain class' .save() and .delete(). If we assume that our test suites cover the application enough, so we can basically conclude that each dynamic call identified by the test suites is an invariant dynamic call, if there is only one chosen method for it. Then, we just simply replace these calls with static signatures, in class files or even by on-the-fly transformation, to gain performance back.

My current technique to analyse calls at bytecode-level is, firstly scanning for ScriptBytecodeAdapter.invoke*, then reverse looking for LDC "methodName" and other arguments that will be stored onto the stack.

Beyond Java 6
I dont exactly know when INVOKEDYNAMIC will arrive, but with this instruction replacing invariant dynamic calls will be much easier by
1. changing INVOKEDYNAMIC to appropriate kind of invoke, say INVOKEVIRTUAL, INVOKESPACIAL, INVOKESTATIC or INVOKEINTERFACE.
2. changing type descriptors to the correct classes.

I haven't followed the spec of INVOKEDYNAMIC at the moment, it's time to have a quick read again.

OpenLaszlo 4.0.0

2007-03-31T06:04:00.000+07:00

OpenLaszlo 4 released a few days ago. I was impressed with its CSS support, although it's a pull (not push - like HTML's CSS) style. Anyway I've found some bugs that prevented me from compiling an LZX program for the DHTML runtime. Hopefully, these bugs will be get fixed soon.

Another thing is that styles, which are working well in Flash runtimes, doesn't work for the DHTML runtime as well. However, these bugs don't stop me from using this great software !!!

Get OpenJDK Hotspot Compiled !

2007-03-24T04:49:00.000+07:00

I'm very newbie on hacking JVM and I'm very happy to get OpenJDK Hotspot B10 compiled on Ubuntu 6.10. Compilation time is 1 hour and 5 mins. Actually, what I'm wanting to do from now on is to add some modification into its interpreter mode. Everything's just started.

Some configuration
- OpenJDK Hotspot VM 7-EA-B10 (21 Mar 07)
- Importing JDK 1.6_01
- Ubuntu 6.10
- GCC 4.1.2 (Ubuntu 4.1.1-13ubuntu5)
- Linux 2.6.17-11

Flattening Xml to Map using depthFirst

2007-02-05T18:37:00.000+07:00

It's very wonderful and extremely easy to use groovy.xml.XmlParser to flatten an XML document into a Grails compatible Map:

def Map xmlToMap(String xml) {
def root = new XmlParser().parseText(xml)
def map = [:]
root.depthFirst().each { n ->
if(n.value.size == 1) {
def key = n.name
def p = n.parent
while(p.parent != null) {
key = "${p.name}.${key}"
p = p.parent
}
map[key] = n.value[0]
}
}
return map
}

Multiple Assignment soon in Groovy 1.1

2007-02-04T11:27:00.000+07:00

Beside other cool features, the last entry in GDC 3 report about what's going to be added into Groovy 1.1 is multiple assignment. I'm definitely looking forward to use it !!!

GORM and Data Grid

2007-02-04T11:21:00.000+07:00

Graeme Rocher revealed the possibility for GORM to support data grid on top of Terracotta or Tangasol Coherence.

This's going to be a big impact, at least, from my research perspective.

Groovy is the most interesting JVM-based non-Java language

2007-02-04T11:10:00.000+07:00

By Java.net poll, Groovy gets 27.3% and becomes the most interesting non-Java language running on JVM. However, JRuby ranks no. 2 with 20.9%.

This survey gives a good picture of Groovy, and of course Grails, momentum.

Configuring Grails datasource with a .properties file

2007-01-22T07:37:00.000+07:00

A Grails user needs to configure Grails data sources with an external .properties file (posted here), but having Spring beans inside "resources.xml" for it won't work for some reasons. I was trying to investigate what's going on, and found that there're steps done by Grails Hibernate plugin to retrieve references of datasouce before some beans defined in "resources.xml" are processed.

Anyway, I like the concept of using .properties file as well. So I modified *some*DataSource.groovy to see how can I use .properties to fill the data source properties, and here's the code:

import java.util.Properties
import org.springframework.core.io.FileSystemResource

class DevelopmentDataSource {

def static propFile = "web-app/WEB-INF/conf.properties";

boolean pooling = true
String dbCreate = "create-drop"

String url
String driverClassName
String username
String password

public DevelopmentDataSource() {
def props = new Properties()
try {
props.load(new FileSystemResource(propFile).inputStream)
} catch(Exception e){
e.printStackTrace();
}
this.driverClassName = props.getProperty("jdbc.driver","org.hsqldb.jdbcDriver")
this.url = props.getProperty("jdbc.url","jdbc:hsqldb:mem:inDB")
this.username = props.getProperty("jdbc.username","sa")
this.password = props.getProperty("jdbc.password","")
}
}

I know that it's not an elegant solution for the moment, but it works :).
With this modified datasource, you use the "propFile" to point to some file outside .WAR, and have some better level of abstraction.

XFire plugin changed convention and upgraded to XFire 1.2.4

2007-01-20T05:20:00.000+07:00

I've patched the XFire plugin to 1.2.4 and changed some convention to be more compatible with Grails.
Now you can just tweak your Grails services to be Web services by adding the static property 'expose'.
Here's an example:

class TestService {

static expose=['xfire']

def String doSomething(DomainClass dc) {
return "done"
}

def String getData() {
return "data"
}

def void setSomething(String something) {
// set some values here
}
}

The current build is going to skip all properties in a service, including transactional.
However, it's smart enough to expose some methods like 'getData' or void 'setSomething' correctly.
The policy used to expose methods in this build will detect existence of both "getter" and "setter" for a property.
Because in Groovy and Grails, we usually have property by simply defining a property with the 'def' keyword.

BTW, I was trying to compile it using JDK 1.4 but nothing works.
Some type casting exception has been occurred inside XFireSpringServlet and I cannot fix it yet.
So please stay tuned if you're going to use this plugin with Grails on 1.4 VM.

I've finally done XFire plugin for Grails

2007-01-11T13:27:00.000+07:00

Last post, I mentioned about Grails plugin architecture in 0.4. This great feature allows us to develop our own plugins. I firstly thought that it might be difficult to develop my own one. But after having a look into some plugin codes in Grails itself, and another one - OpenLaszlo plugin. I finally got some ideas about how the plugin works, and what to do.

However, I was suffered a bit by bugs from Spring Bean Builder because it doesn't provide complete APIs to cover methods I need, such as "bean.initMethod". Anyway, it's not too hard to figure it out, and I have some workaround to avoid these bugs. I'm planning to fix them soon after my XFire plugin is stable for Grails 0.4.

So, what's about the XFire plugin for Grails ?
It's a plugin to expose a Grils service as a Web service. Only requirement is that the service must have "XFireService" suffix. The plugin scans pulbic methods of the service, and generates complex type definition for parameter and return types using a modified XFire's Aegis engine.
For a Grails domain class, this plugin will generate type information for every properties, including "id", but it will ignore "version" and other Groovy specific properties.
If you want to exclude some methods, you can define "static excludes = []" in the service.

Here's some example:

class MyXFireService {

def static excludes = ["notMe"]

def String myMethod(MyDomain d) {
d.save()
return "test"
}

def String notMe() {
return "nothing"
}
}

I've added a page for this plugin at Grails space here:
http://grails.org/XFire+plugin

XFire for Grails Applications - the pre-plugin Era

2007-01-06T16:44:00.000+07:00

I've updated my Grails from 0.3.1 to 0.4 snapshot and its new coming plug-in architecture looks very promising. I'm hoping that someone will implement an XFire plugin for Grails soon (mentioned some where in Grails' wiki). Anyway, I'm going to talk about how to integrate XFire into an Grails application manually.

Here, I briefly show you steps to integrate annotation-based XFire Web services into your Grails Applications.

1. download XFire distro (I'm using 1.2.3).
2. put everything (.jar files) of XFire into ${YOUR_GRAILS_APP}\lib
3. create your Web service class in src/java
4. modify resources.xml
5. modify web.template.xml
6. grails run-app

It's still configuration-based approach, not conventional yet.
Anyway, this might be useful to someone, who currently need to use XFire, when the XFire plugin still be an imaginary thing.

Note that, this covers only HTTP-based transportation of XFire, since Grails is mainly for Web.

Let's go into details:
Before starting, you have to put all XFire .jar files into your /lib folder first.

So, you can start by put your annotation-based classes in "src/java" folder.

@WebService
public class MyService {

@WebMethod
public String doSomething() {
return "hello";
}

@WebMethod(exclude=true)
public void hideMePlease() {
return;
}

}

what you needs are modification of "resources.xml" for spring, and "web.template.xml".

OK, then add some XML chunks into your spring/resources.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">

<beans>


<import resource="classpath:org/codehaus/xfire/spring/xfire.xml" />


<bean name="myService" class="org.codehaus.xfire.spring.ServiceBean">
<property name="xfire" ref="xfire"/>
<property name="serviceBean" ref="myService"/>
<property name="serviceClass" value="MyService"/>
<property name="serviceFactory" ref="jsr181"/>
</bean>


<bean id="jsr181"
class="org.codehaus.xfire.spring.config.ServiceFactoryBean"
init-method="initialize">
<constructor-arg index="0" value="jsr181" />
<property name="transportManager" ref="xfire.transportManager" />
</bean>

</beans>

Finally, put some servlet configuration into your "web.template.xml", like this

<servlet>
<servlet-name>XFireServlet</servlet-name>
<display-name>XFire Servlet</display-name>
<servlet-class>
org.codehaus.xfire.spring.XFireSpringServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>XFireServlet</servlet-name>
<url-pattern>/servlet/XFireServlet/*</url-pattern>
</servlet-mapping>

<servlet-mapping>
<servlet-name>XFireServlet</servlet-name>
<url-pattern>/services/*</url-pattern>
</servlet-mapping>

OK, let's type "grails run-app" and browse to "http://localhost:8080/${your_grails_app}/services/myService/" to see its WSDL link.
And that's all, your XFire service is now ready.

Are you suffering from using Dojo in Grails ?

2006-12-08T10:45:00.000+07:00

Everything works fine for Grails 0.3.1 when I'm not using Dojo.
But after I'm using it with Grails, I'm suffering from the 100% CPU usage.
This performance hit's caused by Jetty (Grails' default server) is trying to response Dojo files.

From my understanding, it might be that
1. Jetty in Grails distribution has not been configured for this purpose ? or
2. It's normal that a Servlet container's not good at serving a big static file ?

Anyway, I still don't know what's going on inside the container, but I've got a workaround for this problem.
My current solution is to use lighttpd as the front server to serve this Dojo monster ;)
I connect lighttpd with Grails' server using the mod_proxy.
Here's my current config in \etc\lighttpd.conf

proxy.server = ( "/" =>
( "127.0.0.1" =>
(
"host" => "127.0.0.1",
"port" => 8080
)
)
)

Then you need to put your Dojo files into the \htdocs, and correct all script's references in your GSP pages.
Lighttpd uses the default 80 port. So, you just point your browser to http://127.0.0.1//, every should work correctly.

IMO, this solution should work for the production phase as well.

Minimum "rt.jar" for Hello World

2006-12-01T21:12:00.000+07:00

Here's a list of classes that are needed to run a Java hello world program.
I find this list using java -verbose (motivated by this post).

== listfile.txt ==
/java/io/BufferedInputStream.class
/java/io/BufferedOutputStream.class
/java/io/BufferedWriter.class
/java/io/Closeable.class
/java/io/DataInput.class
/java/io/DataInputStream.class
/java/io/ExpiringCache.class
/java/io/ExpiringCache$1.class
/java/io/ExpiringCache$Entry.class
/java/io/File.class
/java/io/FileDescriptor.class
/java/io/FileInputStream.class
/java/io/FileOutputStream.class
/java/io/FilePermission.class
/java/io/FilePermission$1.class
/java/io/FilePermissionCollection.class
/java/io/FileSystem.class
/java/io/FilterInputStream.class
/java/io/FilterOutputStream.class
/java/io/Flushable.class
/java/io/InputStream.class
/java/io/ObjectStreamClass.class
/java/io/ObjectStreamField.class
/java/io/OutputStream.class
/java/io/OutputStreamWriter.class
/java/io/PrintStream.class
/java/io/Serializable.class
/java/io/Win32FileSystem.class
/java/io/WinNTFileSystem.class
/java/io/Writer.class
/java/lang/AbstractStringBuilder.class
/java/lang/Appendable.class
/java/lang/ArithmeticException.class
/java/lang/ArrayStoreException.class
/java/lang/Boolean.class
/java/lang/Byte.class
/java/lang/CharSequence.class
/java/lang/Character.class
/java/lang/CharacterDataLatin1.class
/java/lang/Class.class
/java/lang/Class$1.class
/java/lang/Class$3.class
/java/lang/ClassCastException.class
/java/lang/ClassLoader.class
/java/lang/ClassLoader$3.class
/java/lang/ClassLoader$NativeLibrary.class
/java/lang/ClassNotFoundException.class
/java/lang/Cloneable.class
/java/lang/Comparable.class
/java/lang/Compiler.class
/java/lang/Compiler$1.class
/java/lang/Double.class
/java/lang/Error.class
/java/lang/Exception.class
/java/lang/Float.class
/java/lang/IncompatibleClassChangeError.class
/java/lang/Integer.class
/java/lang/Iterable.class
/java/lang/LinkageError.class
/java/lang/Long.class
/java/lang/Math.class
/java/lang/NoClassDefFoundError.class
/java/lang/NoSuchMethodError.class
/java/lang/NullPointerException.class
/java/lang/Number.class
/java/lang/Object.class
/java/lang/OutOfMemoryError.class
/java/lang/Readable.class
/java/lang/Runnable.class
/java/lang/Runtime.class
/java/lang/RuntimeException.class
/java/lang/RuntimePermission.class
/java/lang/Short.class
/java/lang/Shutdown.class
/java/lang/Shutdown$Lock.class
/java/lang/StackOverflowError.class
/java/lang/StackTraceElement.class
/java/lang/StrictMath.class
/java/lang/String.class
/java/lang/String$CaseInsensitiveComparator.class
/java/lang/StringBuffer.class
/java/lang/StringBuilder.class
/java/lang/StringCoding.class
/java/lang/StringCoding$CharsetSD.class
/java/lang/StringCoding$CharsetSE.class
/java/lang/StringCoding$StringDecoder.class
/java/lang/StringCoding$StringEncoder.class
/java/lang/System.class
/java/lang/System$2.class
/java/lang/SystemClassLoaderAction.class
/java/lang/Terminator.class
/java/lang/Terminator$1.class
/java/lang/Thread.class
/java/lang/Thread$UncaughtExceptionHandler.class
/java/lang/ThreadDeath.class
/java/lang/ThreadGroup.class
/java/lang/ThreadLocal.class
/java/lang/ThreadLocal$ThreadLocalMap.class
/java/lang/ThreadLocal$ThreadLocalMap$Entry.class
/java/lang/Throwable.class
/java/lang/VirtualMachineError.class
/java/lang/annotation/Annotation.class
/java/lang/management/MemoryUsage.class
/java/lang/ref/FinalReference.class
/java/lang/ref/Finalizer.class
/java/lang/ref/Finalizer$FinalizerThread.class
/java/lang/ref/PhantomReference.class
/java/lang/ref/Reference.class
/java/lang/ref/Reference$Lock.class
/java/lang/ref/Reference$ReferenceHandler.class
/java/lang/ref/ReferenceQueue.class
/java/lang/ref/ReferenceQueue$Lock.class
/java/lang/ref/ReferenceQueue$Null.class
/java/lang/ref/SoftReference.class
/java/lang/ref/WeakReference.class
/java/lang/reflect/AccessibleObject.class
/java/lang/reflect/AnnotatedElement.class
/java/lang/reflect/Constructor.class
/java/lang/reflect/Field.class
/java/lang/reflect/GenericDeclaration.class
/java/lang/reflect/Member.class
/java/lang/reflect/Method.class
/java/lang/reflect/Modifier.class
/java/lang/reflect/ReflectAccess.class
/java/lang/reflect/ReflectPermission.class
/java/lang/reflect/Type.class
/java/net/ContentHandler.class
/java/net/Parts.class
/java/net/URL.class
/java/net/URLClassLoader.class
/java/net/URLClassLoader$1.class
/java/net/URLConnection.class
/java/net/URLStreamHandler.class
/java/net/URLStreamHandlerFactory.class
/java/net/UnknownContentHandler.class
/java/nio/Bits.class
/java/nio/Buffer.class
/java/nio/ByteBuffer.class
/java/nio/ByteOrder.class
/java/nio/CharBuffer.class
/java/nio/HeapByteBuffer.class
/java/nio/HeapCharBuffer.class
/java/nio/charset/Charset.class
/java/nio/charset/Charset$3.class
/java/nio/charset/CharsetDecoder.class
/java/nio/charset/CharsetEncoder.class
/java/nio/charset/CoderResult.class
/java/nio/charset/CoderResult$1.class
/java/nio/charset/CoderResult$2.class
/java/nio/charset/CoderResult$Cache.class
/java/nio/charset/CodingErrorAction.class
/java/nio/charset/spi/CharsetProvider.class
/java/security/AccessControlContext.class
/java/security/AccessController.class
/java/security/AllPermission.class
/java/security/BasicPermission.class
/java/security/BasicPermissionCollection.class
/java/security/CodeSource.class
/java/security/Guard.class
/java/security/Permission.class
/java/security/PermissionCollection.class
/java/security/Permissions.class
/java/security/Principal.class
/java/security/PrivilegedAction.class
/java/security/PrivilegedActionException.class
/java/security/PrivilegedExceptionAction.class
/java/security/ProtectionDomain.class
/java/security/SecureClassLoader.class
/java/security/UnresolvedPermission.class
/java/security/cert/Certificate.class
/java/util/AbstractCollection.class
/java/util/AbstractList.class
/java/util/AbstractMap.class
/java/util/AbstractSet.class
/java/util/ArrayList.class
/java/util/BitSet.class
/java/util/Collection.class
/java/util/Collections.class
/java/util/Collections$EmptyList.class
/java/util/Collections$EmptyMap.class
/java/util/Collections$EmptySet.class
/java/util/Collections$ReverseComparator.class
/java/util/Collections$SynchronizedMap.class
/java/util/Comparator.class
/java/util/Dictionary.class
/java/util/Enumeration.class
/java/util/HashMap.class
/java/util/HashMap$Entry.class
/java/util/HashSet.class
/java/util/Hashtable.class
/java/util/Hashtable$EmptyEnumerator.class
/java/util/Hashtable$EmptyIterator.class
/java/util/Hashtable$Entry.class
/java/util/Iterator.class
/java/util/LinkedHashMap.class
/java/util/LinkedHashMap$Entry.class
/java/util/List.class
/java/util/Locale.class
/java/util/Map.class
/java/util/Map$Entry.class
/java/util/Properties.class
/java/util/Random.class
/java/util/RandomAccess.class
/java/util/Set.class
/java/util/SortedMap.class
/java/util/Stack.class
/java/util/StringTokenizer.class
/java/util/TreeMap.class
/java/util/TreeMap$Entry.class
/java/util/Vector.class
/java/util/concurrent/atomic/AtomicLong.class
/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.class
/java/util/concurrent/atomic/AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl.class
/java/util/jar/JarEntry.class
/java/util/jar/JarFile.class
/java/util/jar/JarFile$JarFileEntry.class
/java/util/jar/JavaUtilJarAccessImpl.class
/java/util/zip/Inflater.class
/java/util/zip/InflaterInputStream.class
/java/util/zip/ZipConstants.class
/java/util/zip/ZipEntry.class
/java/util/zip/ZipFile.class
/java/util/zip/ZipFile$2.class
/java/util/zip/ZipFile$ZipFileInputStream.class
/sun/io/Converters.class
/sun/misc/ASCIICaseInsensitiveComparator.class
/sun/misc/AtomicLong.class
/sun/misc/AtomicLongCSImpl.class
/sun/misc/ExtensionDependency.class
/sun/misc/FileURLMapper.class
/sun/misc/JarIndex.class
/sun/misc/JavaLangAccess.class
/sun/misc/JavaUtilJarAccess.class
/sun/misc/Launcher.class
/sun/misc/Launcher$AppClassLoader.class
/sun/misc/Launcher$AppClassLoader$1.class
/sun/misc/Launcher$ExtClassLoader.class
/sun/misc/Launcher$ExtClassLoader$1.class
/sun/misc/Launcher$Factory.class
/sun/misc/NativeSignalHandler.class
/sun/misc/Resource.class
/sun/misc/SharedSecrets.class
/sun/misc/Signal.class
/sun/misc/SignalHandler.class
/sun/misc/SoftCache.class
/sun/misc/URLClassPath.class
/sun/misc/URLClassPath$3.class
/sun/misc/URLClassPath$FileLoader.class
/sun/misc/URLClassPath$FileLoader$1.class
/sun/misc/URLClassPath$JarLoader.class
/sun/misc/URLClassPath$Loader.class
/sun/misc/Unsafe.class
/sun/misc/VM.class
/sun/misc/Version.class
/sun/net/www/MessageHeader.class
/sun/net/www/ParseUtil.class
/sun/net/www/URLConnection.class
/sun/net/www/protocol/file/FileURLConnection.class
/sun/net/www/protocol/file/Handler.class
/sun/net/www/protocol/jar/Handler.class
/sun/nio/ByteBuffered.class
/sun/nio/cs/AbstractCharsetProvider.class
/sun/nio/cs/FastCharsetProvider.class
/sun/nio/cs/HistoricallyNamedCharset.class
/sun/nio/cs/MS1252.class
/sun/nio/cs/MS1252$Decoder.class
/sun/nio/cs/MS1252$Encoder.class
/sun/nio/cs/SingleByteDecoder.class
/sun/nio/cs/SingleByteEncoder.class
/sun/nio/cs/StandardCharsets.class
/sun/nio/cs/StandardCharsets$Aliases.class
/sun/nio/cs/StandardCharsets$Cache.class
/sun/nio/cs/StandardCharsets$Classes.class
/sun/nio/cs/StreamEncoder.class
/sun/nio/cs/StreamEncoder$CharsetSE.class
/sun/nio/cs/Surrogate.class
/sun/nio/cs/Surrogate$Parser.class
/sun/nio/cs/ext/ExtendedCharsets.class
/sun/nio/cs/ext/MS874.class
/sun/nio/cs/ext/MS874$Decoder.class
/sun/nio/cs/ext/MS874$Encoder.class
/sun/reflect/ConstantPool.class
/sun/reflect/ConstructorAccessor.class
/sun/reflect/ConstructorAccessorImpl.class
/sun/reflect/DelegatingClassLoader.class
/sun/reflect/DelegatingConstructorAccessorImpl.class
/sun/reflect/LangReflectAccess.class
/sun/reflect/MagicAccessorImpl.class
/sun/reflect/MethodAccessor.class
/sun/reflect/MethodAccessorImpl.class
/sun/reflect/NativeConstructorAccessorImpl.class
/sun/reflect/Reflection.class
/sun/reflect/ReflectionFactory.class
/sun/reflect/ReflectionFactory$1.class
/sun/reflect/ReflectionFactory$GetReflectionFactoryAction.class
/sun/reflect/misc/ReflectUtil.class
/sun/security/action/GetPropertyAction.class
/sun/security/util/Debug.class
/sun/util/PreHashedMap.class

The following is a command for 7z to strip down the rt.jar (from 37,043 Kb to 1,806 Kb).

7z.exe d -r -x@listfile.txt rt.jar *.class

I tested with JRE 1.5_08 on Windows XP.

Practical AOP #2 - What's done behind-the-scene?

2006-04-08T20:38:00.000+07:00

I'll show you something that I think it's hard to maintain without AOP.
As in my Practical AOP #1, I mentioned that I have 8 inter-type declarations and 5 pointcuts to make data-binding work in ZK framework.

The main important thing is that I need one of the ZK base class to implement my Bindable interface. This change can be considered as somekind of the architectural change. Other point is that several UI element classes need to be modified. One of my pointcuts weaves to add the special event trigger to, at least, 9 classes.

The figure below partially shows the UML-like class diagram for the data-binding aspect.

AOP | Modularity ~= Responsibility

2006-04-08T20:00:00.000+07:00

It's difficult to making change to many opensource projects that their developers are taking full responsibility to their own codes. The process of changing must be done via their process. Many projects use the opensource community to find their bugs rather than feature enhancement becuase the developer still want to control the way the project should be. This is somewhat to crash the innovations. Someone who has some ideas to completely enhace the original project has to *fork* to the new project. In my opinion, we can use AOP to solve these social phenomena.

What I've done is in the same way I mentioned above. At the first place, I want to add some new features to ZK. I created some new code and was thinking about sending the patch to ZK developers. But I stopped and thought again. If I send my patches to them, my code may break their code and it's not good for the ZK community. The development may have to be slow down because something will be patched into the core. So my solution is to convert all my new code into an aspect. Then I'll take all responsibilities to my aspect rather than push it to the ZK core developers. I think this solution could be good when someone wants to contribute a new thing to the core of some working frameworks. That's why the data-binding aspect has been made.

Practical AOP #1: Data-Binding Aspect for Web UI

2006-04-08T04:37:00.000+07:00

ZK (http://zk1.sf.net) is one of the best XUL tool for Java that I've known. It's a very powerful framework working on server-side to render DHTML with Ajax capability. ZK is heavily based on MVC model, but I personally want to use the .NET-like data-binding feature in this framework. To avoid making changes direct to the ZK core, which is being maintained by its developers, I use AspectJ (1.5) to create the "data-binding" aspect.

However, I firstly started with OO approach in my development process. After I have some working code, I've tried to refactor the data-binding aspect out of the base code. During development, I've found that it is difficult to develop aspects without looking to the base source code. Because I need to ensure that my aspect weaves the base code correctly.

In my data-binding aspect, I have 5 pointcuts and 8 inter-type declarations.

Result
I've finished the first version of zk-databinding aspect outside the ZK team.
With AspectJ 1.5 and Java 5, I can deploy my aspect to a Web container (tested with
Tomcat 5.5.16) and get the data-binding feature transparently.
Not surprisingly, the data-binding aspect works with ZK 1.1 and ZK 1.2 flawlessly.

Together + NHibernate ~= A Great Duo

2006-03-15T01:41:00.000+07:00

I just have an opportunity to use Borland Together 2005 for VS.NET. Its LiveSource ? feature is very cool !!!. So, I’m here to tell my experience.
I’m evaluating a modeling tool for modeling business sytem that will be implemented using NHibernate. This system will contains 70-80 classes (a small-medium system). Someone who visited my website may be wonder why I don’t use ECO III. The main reason is because ECO III doesn’t work will with MySQL dbms. The other reason is that ECO III uses the unified approach to maintain object id, so the system may have a number of objects no more that 2^31 (please correct me if I’m wrong). However, this limitation is not a problem for a small to medium system. I calculated that the system can run and work well for at least 50 years. But the problem will occur when there are a lot of transaction per day. Object ids will be run out, and ECO won’t reuse any deleted id.

On the other hand, NHibernate is boring because it cannot fully manage bi-directional associations because it isn’t controlled by a state machine, which ECO has. The main advantages of NHibernate are. 1. ) It allows developer to do o/r mapping at low-level, and 2.) NHibernate objects are plain .NET objects (while ECO objects are not, all ECO business entity implements IObject interface).

I’m evaluating DevExpress XtraGrid for UI layer, it’s amazing control. Not much needed to say. Its databinding ability is extremely cool !!. One problem I encountered for NHibernate with DevExpress and other GUI layer is just we need to implement Equals, ToString, Hash methods for every class. And I’m now ready to by XtraGrid :). FYI, I use ObjectViews to connect NHibernate to XtraGrid instead of ISet, IList or Array.

Back to Together, it is useful for modeling and it makes me wonder that why Together for VS.NET is faster that Together for Delphi (they should be share the same implementation, shouldn’t they.) Code synchronization is beautiful (v. SP1) I am much faster to model the business entity. AFAIK, Together is one of a few tools that allow designer to put some attributes to the design elements (class, method). I think Rational XDE also have this feature, but didn’t try yet. One feature I don’t see in Together is automatic field encapsulation as property, which is needed by NHibernate. May be I just don’t know how to use it (please tell me if you know). Other great features of Together are namespace management, and enum and inner class modeling, which may be useful for one who uses NHibernate. Together also provides very flexible refactoring.

Moved to Manchester

2006-01-18T12:37:00.000+07:00

Long time no posting.
I'm very busy about moving from Thailand to Manchester, UK.
This is the first day in Manchester that I can online more than 3 hrs :).
I'll study a PhD research program at the University of Manchester for, at least, 3 years.

Sequence = Firebird Generator in NHibernate 1.0

2005-10-13T17:12:00.000+07:00

Code below shows how to use "sequence" to have an auto-incremental field in NHibernate 1.0 with Firebird.
I use Generator(Class="sequence") to make a field to be autoinc, and if you want to specify a generator name, you can use a Param(Name="sequence", Content) attribute.

namespace TestNHibernate
{
[Serializable]
[Class(NameType=typeof(TestClass))]
public class TestClass {

private int _id;
private string _name;

public TestClass() {
}

[Id(1, Name="Id")]
[Generator(2, Class="sequence")]
[Param(3, Name="sequence", Content="TestClass_Id_Gen")]
public int Id {
get{ return _id;}
set{ _id = value; }
}

[Property(Name="Name", Length=10)]
public string Name {
get { return _name; }
set { _name = value; }
}
}
}

NHibernate 1.0 and Firebird

2005-10-13T02:15:00.000+07:00

I've some experiences with Hibernate 2.1 but never touch NHibernate.
It's first time I play around NHibernate, just because I want to test it.
I found that NHibernate meets my all criterias (create DDL, gen mapping on the fly, etc.) to enable MDA.
I use mapping attributes from NHibernateContrib to model a domain class (see below).

// new configuration
Configuration config = new Configuration();
// set properties
IDictionary props = new Hashtable();
props["hibernate.connection.provider"] =
"NHibernate.Connection.DriverConnectionProvider";
props["hibernate.dialect" ] =
"NHibernate.Dialect.FirebirdDialect";
props["hibernate.connection.driver_class"] =
"NHibernate.Driver.FirebirdDriver" ;
props["hibernate.connection.connection_string"] =
"User=SYSDBA;Password=masterkey;" +
"Database=C:\\workspace\\FirebirdNET\\test.fdb;" +
"DataSource=;Port=3050;Dialect=3;Charset=NONE;Role=;" +
"Connection lifetime=0;Connection timeout=15;" +
"Pooling=True;Packet Size=8192;Server Type=0";
config.AddProperties(props);

// auto-generate Hbm on-the-fly
using( MemoryStream stream = new MemoryStream() ) {
HbmSerializer.Default.Serialize(stream, typeof(TestClass));
stream.Position = 0;
config.AddInputStream(stream);
}

// create database schema
SchemaExport s = new SchemaExport(config);
s.Create(true, true);

sf = config.BuildSessionFactory();

// create an object, then save
using(ISession ss = sf.OpenSession()) {
ITransaction tx = ss.BeginTransaction();
TestClass tc = new TestClass();
tc.Id = 1;
ss.Save(tc);
tx.Commit();
ss.Close();
}

// try find the object as IList
using(ISession ss = sf.OpenSession()) {
IList a = ss.Find("from TestClass");
Text = a.Count.ToString();
ss.Close();
}

A sample domain class:

using System;
using NHibernate.Mapping.Attributes;

namespace TestNHibernate {

[Serializable]
[Class(NameType=typeof(TestClass))]
public class TestClass {

public TestClass() {
}

private int id;

[Id(-2, Name="Id")]
[Generator(-1, Class="assigned")]
public int Id {
get{ return id;}
set{ id = value; }
}

}
}

ECO objects cannot be serialized !!!

2005-09-30T04:52:00.000+07:00

I just understand that why Borland didnot promote enough their use of ECO for Web Services. I also realize that why there are only few discussion about Web Services issue on ECO news group. It is because we cannot directly use ECO types as WS complex types.

Here is my simple code:

[WebMethod]
public SystemUser[] ListAllUsers() {
SystemUserEA ea = (SystemUserEA)AccessFactory.Create(EcoSpace,
typeof(SystemUserEA));
return ea.FindAll();
}

However, I've already got the idea and trick how to make ECO fully support Web Services :).

Released EcoAccess 1.0 Final

2005-09-26T22:08:00.000+07:00

I'm pround to present version 1.0 of EcoAccess, a free proxy-based declarative DAO library for Borland ECO.

I also updated a website to include one more tutorial - Query as List, and a special report to show that you can save many line of codes using EcoAccess.

You can download EcoAccess v.1.0 Final from http://www.centillex.com/ecoaccess/

Considering Briefcase Model for ECO

2005-09-24T21:49:00.000+07:00

After playing around ECO II, I found that it is quite difficult to make ECO's elements serialized with BinaryFormatter. So, I looked back to DTO pattern, and tried to make a utility to generate simple DTO for wrapping ECO objects.

I named this utility ETO - ECO Transfer Object, and I found that it can work correctly to clone my simple ECO object graph. But I hope it to work with more complicated graph.
If anyone'd like to try this utility please contact me.

Moreover, I also try to make generated ETO objects to be compatible with CompactFormatter and hope that it could work on .NET Compact Framework. That's right, I wanna see ECO working on Pocket PC :).

Eco on Rails

2005-08-08T14:38:00.000+07:00

I've successfully tested ECO with EcoAccess on MonoRail Web application framework.
It worked great, and I have some codes to show here.

/// EcoController.cs
using Castle.MonoRail.Framework;
using Centillex.EcoAccess;
using User;

namespace EcoRailsSample
{
public class EcoController : SmartDispatcherController {

UserEcoSpace eco = new UserEcoSpace();

public void List() {
}

public void Edit(int id) {
}

public void View(int id) {
if(eco.Active == false) eco.Active = true;
ISystemUserEA si;
si = (ISystemUserEA) AccessFactory.Create(eco, typeof(ISystemUserEA));
PropertyBag["system_user"] = si.FindById(id);
}
}
}

I set a simple HTML in View.vm (NVelocity template) like this:

## View.vm
<h3>System User</h3>

Name : $system_user.FirstName <br/>
Last Name: $system_user.LastName <br/>

Here is the screenshot of the above codes:

EcoAccess v.1.0 M1 Released

2005-08-02T20:17:00.000+07:00

EcoAccess is now available to download from Centillex.com
This is very early access version. However, you can use many exciting features of it.

Please download it from this page.

EcoAccess: A Declarative DAO for ECO

2005-07-31T18:30:00.000+07:00

I'd like to introduce my work for Borland ECO.
It was inspired by many Java projects such as Beehive and Hibernate.
This project "EcoAccess" is based on Dynamic Proxy from Castle to enable a declarative programming model to Borland ECO.
Obviously, it utilise many ECO services and let you easy to have OCL access methods.
I'd like to thank many articles from ECO section of HowToDoThings.com that guide me on ECO.

The most intesting concept I implemented into EcoAccess is that it provides a pure interface programming model like this:

[AccessEcoSpace(typeof (UserEcoSpace))]
public interface ISystemUserDAO {

[Ocl("SystemUser.allInstances->select(s|s.id = id)->first")]
SystemUser FindById(int id);
}

You can read the first tutorial here.

First get in touch with Comega

2005-04-13T17:51:00.000+07:00

Test.cw

using System;

public class Test {

class Address {
struct {
string text;
};
}

static void Main() {
Address a = <Address><text>test</text></Address>;
Console.WriteLine("Comega says hello!");
Console.WriteLine(a.text);
Console.ReadLine();
}
}

The above code results:

Comega says hello!
test

@Inherited won't work with Interface (JDK 1.5)

2005-03-30T14:52:00.000+07:00

In my early code of SQLWarp, I created the annotation ConnectionInfo to be annotated on an interface, and I need it for an interface, not a class.

@Retention(RUNTIME)
@Inherited
public @interface ConnectionInfo {
public String driver();
public String url();
public String userID() default "";
public String password() default "";
}

The JDK doc says that @Inherited won't work with an Interface, so this is my work around to get annotation from the class that implements the interface which is annotated by @ConnectionInfo.

ConnectionInfo c = (ConnectionInfo)obj
.getClass()
.getInterfaces()[0]
.getAnnotation(ConnectionInfo.class);

Annotion-Based SQL Maps: Part II (JDK 1.5)

2005-03-30T14:42:00.000+07:00

I show you the code sample from iBatis SQL Maps 2.0 last post.
I continue realizing the idea:

public interface MyDAO {

@Sql(expr="
SELECT
ADR_ID as id,
ADR_DESCRIPTION as description,
ADR_STREET as street,
ADR_CITY as city,
ADR_PROVINCE as province,
ADR_POSTAL_CODE as postalCode
FROM ADDRESS
WHERE ADR_ID = ?value
")
public Address getAddress(int value);

}

Q: We need code genraotor to create a class from the SQL expression.
A: MiddleGen could help.
Q: Implement the above method using a proxy class, a runtime class-wrapper.
A: CGLIB or Javassist.
Q: Need parsing parameters in the SQL expression, and bind to method's parameters.
A: I think this can be done using in-house parser, or hacked from iBatis SQL Maps.

My Draft Notes on Class Versioning, O/R Mapping and Separation of Concerns

2005-03-29T11:03:00.000+07:00

Review Rashid's works:

class Person<2.0> {
private String firstName;
private String surName;
}

class Person<1.0> {
private String firstName;
private String lastName;
}

Next step?
Separate, then later weave.
this means
+ We seperate when design --> yield easier design
+ We weave when use --> it must be complex enough to serve all business logics
+ Modification to EJB3 should be great (it's same to OODBMS, dont care RDBMS layer)

Why?
+ It's not possible to change all RBMS invesment to OODB
+ It seems that implementing virtual databases over the tranditional RDBMs is better
+ A virtual database (in my case OR/mapping - Hibernate, Ejb3) can be fully applied with AOSD
+ class versioning schema manager (Rashid 2002-2004)
+ annotation
+ concern
+ data alignment concern

This is an idea for separating Object and Relation concerns:

// teacher data concern
@Entity("Teacher", "1.0")
class Teacher {
private int teacherID;
private String firstName;
private String lastName;
}

@Entity("Student", "1.0")
class Student {
private studentID;
private firstName;
private lastName;
}

// separate advisor concern
@Entity("Teacher", "2.0")
class Advisor {
private List adviseeLists;
}

// separate advisor concern
@Entity("Student", "2.0")
class Advisee {
private Advisor advisor;
}

Teacher t = entityManager.load(Teacher.class,
new Integer(1));
Advisor a = versioningManager.morph(t,
Advisor.class);

This is a new idea for field substitution
How the developer access this code?
possible answer: IoC?

@Version(2.0)
class Student {
@Substitute(version="1.0", name="lastName")
private surName;
}

class StudentDAO {

public Student findById(int id) {
// codes go here ...
}

@Conform("th.ac.sut.ent.Student", "2.0")
public static void main(String args[]) {

Student s = new StudentDAO().findById(10);
// not found, throw exception
System.out.println(s.getLastName());
// should be ok
System.out.println(s.getSurName());
}
}

Idea on Annotaion-based iBATIS SQLMaps (JDK 1.5)

2005-03-28T11:40:00.000+07:00

This is my proposal for hacking iBATIS SQLMaps to be annotation-based version.
After looking at the example, I saw the following code:

<select
id="getAddress" parameterClass="int"
resultClass="examples.domain.Address">
select
ADR_ID as id,
ADR_DESCRIPTION as description,
ADR_STREET as street,
ADR_CITY as city,
ADR_PROVINCE as province,
ADR_POSTAL_CODE as postalCode
from ADDRESS
where ADR_ID = #value#
</select>

can be changed to annotation attaching on a method of a Java interface.
#value# should be able to bind with the parameter, like this:

@Sql("select ... ")
public Address getAttress(int value);

Proxy-based AOP is enough for this implementation. A proxy class can be geneated at runtime, using the technique I proposed in SQLWarp.

later...

Refactored Suranaree.Galvanium (.NET/Java)

2005-03-23T20:12:00.000+07:00

It is completely my fault trying to integrate some GUI features into my Galvanium framework. Now I refactor all GUI-related features out of the framework, and upgrade its dependencies (IKVM from 0.8 to 0.12, and lastest Hessian 3.0.8). The new binary will be posted soon. This version will be 1.0 M3.
Features

At least 250% faster than XML Web Services
Lightweight Protocol based on Hessian
Seamless Integration of J2EE objects and .NET GUI
Direct .NET/Java type mapping
Display/Edit Java objects in Databinding Controls of .NET
Works behind Firewall
Support Mock Object via ClientProxyFactory

Components

ClientProxyFactory
BeanDescriptor
BeanCollection

with additional 2 samples.

Annotion-Based Embedded SQL (JDK 1.5)

2005-03-22T18:54:00.000+07:00

I wanna learn how to create and use annotations in JDK 1.5, so I got some idea from voruta.sf.net.
Voruta is an embedded SQL framework using Javadoc's style annotation. Based on the same idea, but mine is more dirty :), I implement data access framework for embedding SQL statement with JDK 1.5 annotation. I call it the SQLWarp. You can download and try it here.