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! :)

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:

	buildscript {
	ext.kotlin_version = '0.9.976'
	repositories {
	mavenCentral()
	maven {
	url "https://oss.sonatype.org/content/repositories/snapshots"
	}
	}
	dependencies {
	classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
	}
	}
	apply plugin: 'kotlin'
	apply plugin: 'java'
	apply plugin: 'war'
	sourceCompatibility = 1.5
	version = '1.0'
	repositories {
	maven {
	url "https://oss.sonatype.org/content/repositories/snapshots"
	}
	mavenCentral()
	}
	sourceSets {
	main {
	kotlin {
	srcDir 'src/main/kotlin'
	}
	output.resourcesDir = "build/classes/main"
	}
	test {
	kotlin {
	srcDir 'test/main/kotlin'
	}
	}
	main.java.srcDirs += 'src/main/kotlin'
	}
	dependencies {
	compile group: 'javax', name: 'javaee-api', version: '7.0'
	testCompile group: 'junit', name: 'junit', version: '4.11'
	compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
	}

view raw gistfile1.groovy hosted with ❤ by GitHub

And the project structure is as follows:

Here comes the servlet:

	import javax.servlet.http.HttpServlet
	import javax.servlet.http.HttpServletRequest
	import javax.servlet.http.HttpServletResponse
	import javax.servlet.annotation.WebServlet as web
	import javax.inject.Inject
	import javax.enterprise.context.Dependent
	web(name = "Hello", value = array("/hello"))
	public class HomeController : HttpServlet() {
	Inject
	var service: HelloService? = null
	override fun doGet(req: HttpServletRequest, resp: HttpServletResponse) {
	doStuff(resp)
	}
	private fun doStuff(resp: HttpServletResponse) {
	resp.getWriter().write(service!!.message())
	}
	}
	Dependent
	public class HelloService() {
	fun message(): String {
	return "Hello, CDI!"
	}
	}

view raw gistfile1.groovy hosted with ❤ by GitHub

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.

Conclusions

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.