May, 2008


29
May 08

Does JavaRebel really work?

Does JavaRebel really work? — this is what we get for listing all of the technical issues, we feed the skeptics… Truthfully, it is nice to see people taking time to criticize our product even though we (and apparently all of our clients) don’t agree with the verdict. Good going, Rajesh!


25
May 08

Firebug 1.2 – log limit has been reached

You are doing JavaScript logging while debugging using the console.log() of Firebug. If you log more than 200 lines you get a message “Firebug’s log limit reached” and you are out of luck. Currently the option name to higher the limit is maxQueueRequests. This is not an obvious name for console logging limit. Hopefully google will index this and this post will help somebody out. I guess the reason for this kind of name is that while 1.2 is in development they just reuse limits for different stuff. I’ve added a bug report.


20
May 08

First Days at the Great Indian Developer Summit

This is a guest post by Rein Raudjärv, who at the moment is with Toomas Römer at the Great Indian Developer Summit. Edited by Jevgeni Kabanov for brevity and to fit with other blog content.

Our trip started after a big birthday party. I slept in (my phone battery ran out of power) and got no time for breakfast or anything. There were almost 25 extra kilos of luggage and with a re-check-in to a local Indian airline in Delhi we decided to leave our back wall and some T-shirts in the Tallinn office. We got to Finland quickly and easily.

The flight to Delhi took about 7 hours. The landing at about midnight was delayed because of the thunderstorm above the airport. The first impression of India was high temperature (above 30 degrees Celsius). There already were guys waiting at the airport waiting to carry your luggage to the nearest (his cousin’s) taxi. We had to use the taxi to get to the next airport. People were sleeping outside the building — we didn’t understand why they were not allowed to enter. Inside most of people including the personal was sleeping as well.

We got to the flight to Bangalore (officially named Bangaluru) in the second morning. The taxi trip to the hotel illustrates the Indian traffic in the daylight. The number of lanes is very dynamic. They have lot of scooters and 3-wheel drives. I also saw a cow sleeping on the sidewalk. Nobody was interrupting the holy animal. In general India is not so clean. At the same time people are quite friendly and happy to help us.

The first day at the conference started with several hours setting up the booth. We had only a table, a chair and a title “ZEROTUMAROUND” waiting for us and no WiFi in sight. We asked for extra tables and a plasma TV. Trying out different things we finally came up with the final booth layout. The title and WiFi got fixed during the day. Except for the slow network connection, hotness (felt like 30 degrees inside) and lacking of toilette paper everything went really well. During the day there were several folks enjoying our cartoon and giving some fliers in front of our booth.

Great Indian Developer Summit

Our initial booth

Our booth that is ready

Indian girls with fliers in front of us


20
May 08

The JSR 292 — invokedynamic

I read through the first draft of JSR 292 this morning and had several questions that I’m not 100% sure the current specification addresses:

  • Can I rebind the CallSite after I have set the MethodHandle?
  • Can I keep a reference to CallSites at all?
  • Is the setMethodHanlde method implied to be thread-safe?

The reason I’m asking is that the only way to rebind a method as seen in spec is lazily, by invalidating all the call sites in the class (or everywhere) and rebinding methods when called. It may sometimes be necessary or easier to do that eagerly and it looks like the current API does allow that. It should either be forbidden explicitly or allowed explicitly.

I’ll send a link to the JSR-292-COMMENTS list as well, but perhaps someone knows the answer already?


19
May 08

Concise EDSL Closures in Java

This trick was pointed to me (without the ThreadLocal part) by Rein Raudjärv, who saw it used in jMock.

The problem with Java “closures” aka anonymous inner classes being a tad too ugly is a well known one, but this semi-solution seems to be quite unused. Although you can apply the same principle for many situations it’ll work best for embedded DSLs.

Let’s start by defining an EDSL intefrace:
[java]
public interface DSL {

DSL doSomething();
DSL doSomethingElse();
DSLPreClosure closure();
}
[/java]

As you can see we separated the actual closure application in a separate interface:
[java]
public interface DSLPreClosure {
DSL apply(DSLClosure closure);
}
[/java]

The reason for that is that we want to use closures without defining a method in the anonymous inner class:
[java]
public class Test {
public static void main(String[] args) {
new DSLImpl()
.doSomething()
.closure().apply(new DSLClosure() {{
dsl
.doSomething()
.doSomethingElse();
}})
.doSomethingElse();
}
}
[/java]

What happens is that we abuse a little used Java feature — initializers. If you put a block in the body of a class definition it will be executed right after the constructor. In our case we construct a new subclass of DSLClosure and immediately add an initializer:
[java]
new DSLClosure() {
//Initializer starts here
{
//Closure body goes here
}
//Initializer ends here
};
[/java]

Of course while this allows to execute a block of code with fewer symbols to write, we still need to somehow pass parameters. Note, that since the initializer executes inside the constructor call, it will be executed before the actual apply() method is called. Therefore we make use of the ThreadLocal class to pass the parameters inside the call:
[java]
public class DSLImpl implements DSLWithClosure {
static final ThreadLocal curDSL =
new ThreadLocal();

public DSL doSomething() {
//Do something…
return this;
}

public DSL doSomethingElse() {
//Do something else…
return this;
}

public DSLWithClosure closure() {
curDSL.set(this);
return this;
}

public DSL apply(DSLClosure closure) {
curDSL.set(null);
return this;
}
}
[/java]

Finally the DSLClosure exposes the ThreadLocal parameter as a protected field:
[java]
public class DSLClosure {
protected DSL dsl =
(DSL) DSLImpl.curDSL.get();
}
[/java]

Of course, for the sake of correctness we should also allow nesting closure calls on the same thread, so we should use a stack inside ThreadLocal, but this is left as an exercise to the reader :)