JNA is really, really good


The last few months JRuby have used something called JNA to introduce some functionality we couldn’t do before. This mainly includes POSIX file operations of different kinds. I’ve just spent a few days getting a basis for UNIX Domain Sockets working in JRuby, using JNA, and I’ve gotta say that I’m incredibly impressed by it. For simpler function calls, it just works. For more complicated stuff you might have to set up structures and so on, but it’s still incredibly slick. The best part: no native compilation needed.

Of course, this has some performance considerations, but it’s still better than nothing.



Denmark, QCon and JavaOne


Today is my last day in Sweden for a while. It’s been an incredible time, and I think that my coworkers from ThoughtWorks have had a wonderful experience in Sweden. What will happen regarding a Swedish office is still up in the air, but I’m cautiously optimistic about it all. In fact, if someone knows a possible client please get in touch. =)

Next week I’m going to Denmark, visiting the castle Hindsgavl where the Danish Java User Group (JavaGruppen) is holding a conference. I will do one presentation on JRuby and one tutorial on JRuby on Rails.

The next planned event will be QCon in London where I will present about some of the more exciting upcoming features in the JVM. That’s going to be great fun.

The last week in February I’ll be in San Francisco, possibly helping out with some really cool ThoughtWorks events. I’ll post more about that when I have the information.

I will also present at Developer Summit in April, in Stockholm.

Finally, expect me to do one presentation and one BoF at JavaOne. I might also do a talk at CommunityOne.

It’s going to be a busy spring time.



Polyglot, not panglot or omniglot


It’s interesting. One of the common reactions I’ve heard to my recent writings about polyglot programming is something I really don’t understand. Actually, I’ve heard the same objection to other persons writing about polyglot.

The objection is that just because I propose polyglot programming – using several different programming languages for different purposes in the same system – I can use whichever language
and as such should not try to find better languages or say that certain languages are bad.

But that’s really a confounding of the issue. Just because I can use any language in the dynamic layer doesn’t mean I should. In fact, just because polyglot programming as a strategy means you will use more than one language, it is even more important to be careful and use the best languages available for the task. Which is why I’m working to improve JRuby, why I’m evaluating Scala as a replacement for Java, why I’m working on a language based on Io. It’s all about using the best languages. I may be a polyglot, but I’m definitely not a panglot or omniglot.



Distributed version control and SVN


As everyone else has discovered, I’ve just realized how nice DVCS can be. Of course, I’m part of several open source projects that all happen to use Subversion. I’ve tried Bazaar, Mercurial, Git and SVK. Of all these, Mercurial is the one I really, really like. But here is the problem: hgsvn is really not up to scratch right now. I tried to pull some stuff from SVN at one project and it immediately errored out. git-svn on the other hand works like a charm. It seems that right now I have to use git, unless someone has a good solution for getting Mercurial really working with SVN. (Also, the fact that hgsvn is pull-only is a bit problematic.)

Advice appreciated.



Ruby antipattern: Using eval without positioning information


I have noticed that the default way eval, instance_eval(String) and module_eval(String) almost never does what you want unless you supply positioning information. Oh, it will execute all right, and provided you have no bugs in your code, everything is fine. But sooner or later you or someone else will need to debug the code in that eval. In those cases it’s highly annoying when the full error message is “(eval):1: redefining constant Foo”. Sure, in most cases you can still get all the information. But why not just make sure that everything needed is there to trace the call?

I would recommend changing all places you have eval, or where using instance_eval or module_eval that takes a string argument, into the version that takes a file and line number:

eval("puts 'hello world'")
# becomes
eval("puts 'hello world'", binding, __FILE__, __LINE__)

"str".instance_eval("puts self")
# becomes
"str".instance_eval("puts self", __FILE__, __LINE__)

String.module_eval("A=1")
# becomes
String.module_eval("A=1", __FILE__, __LINE__)


Viability of Java and the stable layer


This post is basically a follow up to Language explorations. That post had several statements about what I believe, and some of them have been a bit misunderstood, so I’ll try to substantiate them a bit more here. Specifically, I want to talk about the viability of the Java language and whether “the stable layer” should be a static or dynamic language.

Lets begin with the stable layer. First, notice that I didn’t have any specific definitions for the different layers when I wrote the post. In fact, I think that they are inherently a bit fuzzy. That’s OK. DSL’s are also quite fuzzy. The attributes I put at the stable layer is first of all that it shouldn’t need to change much. In a smaller application, you can actually look at supporting structures as the stable layer, things like application servers or web servers. But for larger applications I find that you usually need your own stable kernel.

The reasons I choose static typing for stable layer is for several reasons. Performance is absolutely one of these, since everything will run on this base it’s an advantage if that part is as performant as possible. Secondly, I am no dynamic language, TDD purist that says that static typing is totally unnecessary. Static type checking can be very helpful, but it stops you from having a malleable language. So the kernel should be stable, this means that as much checking as possible is necessary. None of these requirements explicitly preclude a dynamic language, but the specific features of dynamic languages doesn’t really come to their rights at this level, and also leading to performance and static type checking suffering.

The more contentious part about my post seems to have been my off hand comment that I don’t believe Java is really good for anything. I didn’t give much reason in that post, and people have reacted in different ways, from saying that “Java is really good” to “Why are you involved in JRuby if you think Java is so bad?”. So lets start with why Java is a bad language. (I am only talking about the language here, not the platform). Also, that Java is a bad doesn’t say anything about the worse alternatives, so no comments along the lines of “if you think Java is so bad, why don’t you use X instead”.

In short:

  • Java is extremely verbose. This is really a few different problems in one:
    • No type inference
    • Verbose generic type signatures
    • Anonymous class implementations
  • There is no way to create new kinds of abstractions:
    • No closures
    • Anonymous classes are a really clunky way to handle “block” functionality
  • Broken generics implementation
  • Language is becoming bloated

A few notes. That Java is becoming bloated is one of those things that people have been blogging about lately. After 1.5 came out, the complexity of the language got very much larger, without actually adding much punch for it. The improvements of generics were mostly negated by the verbosity of them. Fixing all the problems above will bloat the language even more. And at the same time, programming in Java is needlessly painful right now.

So, lets look at the question about why I’m working on JRuby. Well, first, I believe the JVM is a very good place to be at. It’s the best platform out there, in my opinion. The libraries are great, the runtime is awesome, and it’s available basically everywhere. The bytecodes of the JVM spec is good enough for most purposes. There is some tweaking that can be done (which we are looking at in JSR292), but mostly it’s a very nice place. And working on JRuby is really one of the ways I’ve seen how bad Java as a language is. We are employing several different tricks to get away from the worst parts of it, though. Code generation is used in several places. We are generating byte codes at runtime. We are using annotations to centralize handling of JRuby methods. And we are moving parts of the implementation to Ruby. I believe that JRuby is important because it can run in the same environment as Java, but without the problems of Java.

What are the solutions to the problem with Java? There are basically two different ways. Either define a subset of Java, not necessarily totally compatible, that takes the best parts of Java syntax, does away with the problems and so on. That should be possible, but I don’t know anyone who has done it. Or, you can go with an existing static language on the JVM. Here you have two choices – either one of the ports of existing extremely static languages (like ML or Haskell), or you can go with something like Scala. I haven’t decided on the best solution here yet. The only thing I’m sure of is that Java in itself is a problem. I’m investigating Scala, but maybe Scala isn’t the right answer either. We’ll see.



The final, objective truth of Rails versus Grails.


So it’s time to bring out the guns, boxing gloves and whatever martial arts knowledge you possess. If you want the full story, start with Graeme’s post here, and drill your way down from there.

I finally lost my patience with this discussion and decided that I should tell you all the truth. The final, totally objective, totally realistic answer to the question of Rails, Grails and Everything.

No, wait. I won’t!

And that’s it. This discussion is becoming a bit silly. I don’t expect someone will see me recommending Grails, and I’m sure we all would be very surprised seeing Graeme recommend JRuby on Rails. So what’s the point?



Are you using ResultSetMetaData.getColumnName?


As the title says, are you using java.sql.ResultSetMetaData.getColumnName in your code? It’s interesting, I have done for years, and I didn’t know that it was just a bug, waiting to happen.

Until I tried MySQL’s 5.1-branch of their JDBC code, I’d always assumed that getColumnName was the right one for generic SQL code. Turns out it isn’t. Specifically, it isn’t the right one if you’re using aliasing in your code. Say you have SELECT Host AS h FROM Host. Now, until the 5.1 branch MySQL JDBC, you would get “h” if you did getColumnName(1) on this result sets metadata. Not so anymore. Now you get “Host”. So what should you use? getColumnLabel. It’s on the same interface. Until tonight I’d never seen a difference between them. But now there is one – so go through all your JDBC code and make sure you’re using the right one here.

Oh, that’s right. MySQL 5.0.5 seems to have a bug in multibyte aliasing. So if you alias Host to be a Chinese character, for example, you will not get the same value back from getColumnName or getColumnLabel. I assume this is a bug, since the 5.1-branch seems good.



Emacs Inferior mode for the Io language


For anyone who like the Io language and work with Emacs, here is a small Inferior mode for Emacs and Io.
It’s adapted from the Ruby Inferior mode. Download it here. To use it, just do “(require ‘inf-io)” and then M-x run-io.

Enjoy.



Scala magic


Oh, right. This is a perfect example of Scala magic that I REALLY don’t understand yet. If there are any Scala wizards reading, please explain!

This line of code is from a test cases written in specs:

      runtime.ev("\"hello world\"")._with(interpreter)
must be_==(runtime.stringFor("hello world"))

Runtime is a Scala class and so is interpreter. I added println()’s before and after, and at different methods in this statement. Now, the baffling thing, the really strange thing (at least in my mind), is that the left hand side of the must, gets evaluated THREE times. But this code only run once. How can that happen? What does Scala do here? (And must doesn’t seem to be a special method. I looked at the implementation, and it’s just a regular method on a trait, mixed into the Scala Object.

Someone please explain this! =)