Wednesday, December 17, 2014

XRebel 1.2

Just released XRebel 1.2. It is amazing, astonishing, splendid, beautiful, awesome, beautiful, beautiful, beautiful! :) I'm most pleased with its ability to show the relation between ORM-level events/queries and the generated SQL queries that are executed via JDBC. Like this:

Or even like this:

The cool part is that even with no special requirements to filtering, the call tree scales very well - the user could see the compact call stack with relevant branching points starting from the incoming HTTP request towards the JDBC calls, or NoSQL... or outgoing HTTP invocations.. even RMI!

/me happy! :)

Saturday, December 6, 2014

Java EE meets Kotlin

Here's an idea - what if one tries implementing Java EE application with Kotlin programming language? So I though a simple example, a servlet with an injected CDI bean, would be sufficient for a start.

Start with a build script:

And the project structure is as follows:

Here comes the servlet:

What's cool about it?

First, it is Kotlin, and it works with the Java EE APIs - that is nice! Second, I kind of like the ability to set aliases for the imported classes: import javax.servlet.annotation.WebServlet as web, in the example.

What's ugly about it?

Safe calls everywhere. As we're working with Java APIs, we're forced to use safe calls in Kotlin code. This is ugly.

Next, in Kotlin, the field has to be initialized. So initializing the 'service' field with the null reference creates a "nullable" type. This also forces us to use either the safe call, or the !! operator later in the code. The attempt to "fix" this by using the constructor parameter instead of the field failed for me, the CDI container could not satisfy the dependency on startup.

Alternatively, we could initialize the field with the instance of HelloService. Then, the container would re-initialize the field with the real CDI proxy and the safe call would not be required.


It is probably too early to say anything for sure, as the demo application is so small. One would definitely need to write much more code to uncover the corner cases. However, some of the outcomes are quite obvious:

  • Using Kotlin in Java web application appears to be quite seamless.
  • The use of Java APIs creates the need for safe calls in Kotlin, which doesn't look very nice.

Disqus for Code Impossible