Seeing Is Believing

29. June, 2008

If you take a photo of something, does that photo show reality? What is there?

Most of us believe so but actually, the photo only shows what was there when you pressed the button. This misconception led to the Image Fulgurator. What’s that? It’s a device which projects a picture when it notices a flashlight, i.e. when someone makes a photo. Because of the flash, you can’t see the image of the Fulgurator, but you will see it later on your photo. The photo shows what was there, not what is there.


Fan Programming Language

26. June, 2008

Another language running on the VM which is worthwhile to check out: Fan.


Jazoon: The Closures Controversy

26. June, 2008

If you ever wanted to know if it is possible to go through 60 information-packed slides in 50 minutes: Yes, it is. I’ve been there and Joshua pulled it off in from of about 100 people, so it’s not a delusion of mine, either.

In his talk, Joshua presented a host of reasons why the BGGA proposal is a really bad idea. The key information here is “BGGA”. We all want closures and Joshua is no exception, it’s just that the BGGA proposal is like Generics on steroids and if you can’t wrap your brain about Generics wildcards, then you won’t understand BGGA closures as well.

The code in the proposal doesn’t look too bad at first glance:

{int x, int y => x+y}

Unless you try to use an array. If you did “int[] x”, you’d get an error because closures are based on generics and generics can’t handle arrays or primitives.

But the next example is better to understand why BGGA will add a new level of hell to Java which will be worse than generics:

{int,String=>Number throws IOException} xyzzy;

is translated into

interface Function1 { // system-generated
    R invoke(int x1, A2 x2) throws E;
}
Function1 xyzzy;

Doesn’t bother you because you’re never going to see this? Well, think again because if you try something that the generics type system doesn’t understand, you’ll get a generics error message like this one:

NewtonWithClosures.java:26: invoke(capture#418 of ? super {double => double}) in {capture#418 of ? super {double => double} => capture#928 of ? extends {double => double}} cannot be applied to (double)

The reason for this is that the closures are implemented using generics and without any high level support in the compiler so the compiler can’t generate a more useful error message. And this was a simple example. We all know how quickly generics get messy and for me, that means that any implementation of any new feature that is based on generics is a threat to the future of Java.

Again, I’m for closures and I use them as often as I can in Groovy but the current proposal is just a new way to make Java harder to use. Why don’t they simply change the compiler to allow to access field and method objects (from java.lang.reflect) via the class? Like so:

collect(list, Math.class.min)

If we could use Method objects like first class citizens (instead of via the horrible reflection API with it’s horde of checked exceptions), we could use Method objects as simple closures. Then, all we would need is a set of util classes for single mutable primitives and we’re done. Sure, the syntax wouldn’t be as compact but every normal Java developer would be able to understand the concept and how it’s supposed to be applied in a few hours.

If you care, here is a link to the whole set of arguments by Joshua Bloch. Read it, keeping in mind that Joshua is pro closure, he just wants to avoid a second generics debacle.


Jazoon: One Year Of Groovy

26. June, 2008

That was my talk. Attendance could have been better but I guess with Joshua Bloch presenting Java Puzzlers, Cédric Beust with “A quick guide to modern languages and interesting concepts for the busy Java programmer” and Adam Bien with Glassfish at the same time, it wasn’t so bad.

Here is the link to the presentation as OpenOffice document. Feel free to post any comments or questions below.


Jazzon: Weblog in 15 minutes II

26. June, 2008

I wish I could link that presentation because it was the best I’ve seen in the whole show, both visually and how it was presented. So here is the link to the abstract. There is something to be learned by this talk for anyone who wants to demo a software: One human being can’t talk and use a computer at the same time. While David explained things, Bertrand wrote the code. Thumbs up!

And in this case, the visual candy didn’t distract from the fact that these guys were really showing off something that ought to have an impact. They showed agile web development with Apache Sling.

A sling gives you range and power and Apache Sling does just that. With just a few pieces of JavaScript added to an existing static HTML web site, they built a blog in roughly 10 minutes. Impressive. I’ve got to try this out myself, probably this weekend.


Jazoon: Thursday Keynote

26. June, 2008

Thursday’s keynote was “Effective Java Reloaded” by Joshua Bloch where he presented a few key points from his new book.

The examples showed how to replace bit fields (or rather int constants which are used a bit fields) with EnumSet and EnumMap, and how to do lazy initialization for various cases effectively and correctly. If you’re a Java programmer who does more than “Hello World”, this book is a must have because it explains not only how to do things but how to do things elegantly and why.


Jazoon: Web Tests

26. June, 2008

In his talk, Dierk König showed ways to test a web applications with canoo webtest. There are several way to come up with a test script: Recording the user actions with a browser plug-in or by writing the script directly, for example.

He also explained the best ways to test an old application (just test what you can, look for NPE’s, for example, load all pages, make sure some properties appear). Of course, since the app wasn’t designed to be testable, you’ll be limited in what you will be able to test.

IFRAMEs, on the other hand, are not a problem, as are AJAX requests. The main issue with AJAX is that while they are still asynchronous, the test framework has some limitations as to what it can test (permutation of request order). Testing special code for IE and FF is not a problem, the framework supports some browser bugs, too. Also, you can have special code to login or to get the app into a certain state and use this code as a kind of “subroutine” in several tests to avoid code duplication.

Internally, webtest will use htmlunit to examine the HTML returned by the app and execute the JavaScript in it. So DOM manipulations can be tested, too.

It’s not really suitable for load tests, though, since it lacks the features to run concurrently on several computers at once. Use JMeter for that.

If you need to prepare the DB before the tests, use dbunit.