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.

18 Comments | By Ola Bini | In: Uncategorized | tags: java, language design, programming languages, scala, static typing. | #

As everyone knows, regular expressions are incredibly important in many programming tasks. So it pays to know some of the particulars of the regexp syntax. One example that bit me a while back was a simple oversight – something I did know but hadn’t kept in mind while writing the bad code. Namely, the way the caret (^) works when used in a String with newlines in it. To be fair I’ve been using Java regexps for a while and that problem doesn’t exist there.

To illustrate the difference, here is a program you can run in either MRI or JRuby. If running in JRuby you’ll see that the Java version needs the flag MULTILINE to behave as Ruby does by default.

str = "one\nover\nyou"
puts "Match with ^"
str.gsub(/^o/) do |e|
 p $~.offset(0)
 e
end

puts "Match with \\A"
str.gsub(/\Ao/) do |e|
 p $~.offset(0)
 e
end


if defined?(JRUBY_VERSION)
 require 'java'
 regexp = java.util.regex.Pattern.compile("^o", java.util.regex.Pattern::MULTILINE)
 matcher = regexp.matcher(str)
 puts "Java match with ^"
 while matcher.find()
   p matcher
 end

 regexp = java.util.regex.Pattern.compile("\\Ao", java.util.regex.Pattern::MULTILINE)
 matcher = regexp.matcher(str)
 puts "Java match with \\A"
 while matcher.find()
   p matcher
 end
end

So, what’s the lesson here? Don’t use caret (^) and dollar ($) if you actually want to match the beginning or the end of the string. Instead, use \A and \Z. That’s what they’re there for.

2 Comments | By Ola Bini | In: Uncategorized | tags: java, regular expressions, ruby. | #

I’m not sure if this is well known or not, so I’ve been meaning to write a quick notice about it. The short story is this: JRuby can run RSpec and RBehave. Why is this important? Well, you can write code that tests Java code using RSpec and RBehave, meaning that it will be possible to get much more readable tests, even for code living in Java land.

Even if your organization won’t accept writing an application in Ruby, it would probably be easier to get the testing done in Ruby. And writing tests in an effective language means that you will either write more production code, or more tests. Either of those are a quite good outcome.

A quick example of this in action. To run this example, you need JRuby 1.0 or later, and the rspec gem:

require 'java'

describe java.util.ArrayList, " when first created" do
before(:each) do
  @list = java.util.ArrayList.new
end

it "should be empty" do
  @list.should be_empty
end

it "should be able to add an element" do
  @list.add "content"
end

it "should raise exception when getting anything" do
  lambda{ @list.get 0 }.should raise_error(java.lang.IndexOutOfBoundsException)
end
end

In this code the examples are not that realistic, but you can see that the RSpec code looks the same for Java code, as it does for Ruby code. Even the raise_error exception matcher works. You can run this:

jruby -S spec -fs arraylist_spec.rb

The RBehave test suite also runs, which means you can stop using JBehave now… =)

This is a perfect example of the intersection where JRuby’s approach can be very powerful, utilizing the existing Ruby libraries to benefit your Java programming.

No Comments | By Ola Bini | In: Uncategorized | tags: java, jruby, rbehave, rspec. | #

I have for a time argued that the JVM should become more like an Operating System, and Java the language for OS development. Other languages should run on top of the JVM for running applications. It seems I’m not alone in this line of thought. Robert Varttinen wrote some about it here. To me it seems like a compelling future. But it seems the next logical step for enterprise applications would be further virtualization. I would for example like my beans implemented in Ruby. But not only that, I would want all the business logic to be OS agnostic. I would like my Ruby logic to live on top of a JVM J2EE server, but that logic should be able to move, transparently, to a .NET-server and provide the same business logic at that place. What would be even better is if I didn’t have to deploy it manually to all places, but the logic would just move to the places where it’s needed. Will we see that anytime soon?

4 Comments | By Ola Bini | In: Uncategorized | tags: future, java, jvm. | #

My blogging in the future will be a little bit fractured (or more fractured, some might say), since I have been invited to write at Inside Java for APress. The address is http://java.apress.com and I do recommend that you subscribe to the feed if you’re interested in Java or associated technologies. My first posting was about the two closure proposals for Java 7, and I will try to focus my posting there to be more Java specific, mostly in article format. But if I write anything I deem to be exceptionally good, I promise to link from here to there.

Go subscribe now!

2 Comments | By Ola Bini | In: Uncategorized | tags: apress, blogging, java. | #

Yesterday marked the first one day conference in Sweden focused on Java. All in all, it was a resounding success. I am personally very happy about how well everything ran. The only part that wasn’t really up to par was the panel discussion.

So, a quick rehash of the day. First Simon Phipps did his thing in the keynote, speaking much about where Sun’s open source initiative comes from. I would have liked some more specific info on the future though, but I guess that’s hard for him to say…

After that, Thorbiörn Fritzon from Sun in Sweden started of the Language track with talking about some new features in Mustang, specifically some Swing topics and the JSR 223 support (scripting). After that he showcased a really cool stack-based calculator he’d hacked during the weekend, where you could attach the functioning of the buttons to different scripts, and the scripts could be implemented in any language on the classpath that supported JSR 223. The final showdown of calculator buttons was first a script in Haskell (using Jaskell) that pushed a lambda on the stack. This lambda curried addition, with the first object on the stack. Then another script written in Python popped the lambda from the stack, popped the next value and called the lambda with the value from the stack, in effect doing an addition the longer way…

After that it was time for my presentation. It felt really good and I believe most in the audience was satisfied.

After that I sat in on Dan Bergh Johnsson from Omegapoint talking about domain driven design, and how to refactor to find your domain. I found it quite elementary, and nothing really new.

Last, Jonas Bonér talked about OpenTerracotta, which is an incredibly cool tool for clustering your JVM applications, and by doing that achieving many different cool things. Look it up! I wish there had been more time for Jonas to get in depth about the implementation of Terracotta, though. Most interesting thing he told us was about a situation where they wanted about 50-80 clients pounding in a cluster at the same time, and they used Terracotta for this too, using a CyclicBarrier that was synchronized over all the JVM’s. Very nice.

The panel debate wasn’t that interesting. Most of the questions asked by the moderator didn’t really achieve any discussion. Open sourcing Java doesn’t seem like such a controversial topic anymore.

After the debate, the conference was over, but then BEA provided a pub evening with entertainment, so we stayed and networked a little, talked with interesting people and generally had fun. After that, six of us continued to a pub in Stockholm, called Monk’s Cafe, where we drank good Belgium beer and talked until our throats were sore. A very interesting day, no doubts.

No Comments | By Ola Bini | In: Uncategorized | tags: java, jfokus, terracotta. | #

A few weeks ago I noted that Sun in Sweden announced on the JavaForum meetup that they were going to have a full day Java conference in January. This conference is called JFokus and will have 4 different tracks with 4 speakers on each track. I will feature in one of these tracks, talking about testing Java code with JRuby and RSpec, and also how to build a DSL for doing database integration testing using Ruby. I believe it will be very interesting, and the rest of the day looks incredible nice too.

So, if you’re in Sweden, Jan 30:th, look into it!

More information can be found at the official site: http://www.jfokus.se/.

2 Comments | By Ola Bini | In: Uncategorized | tags: java, javaforum, jfokus, jruby. | #

Sometimes it feels like the progress I’ve done with the OpenSSL library is almost swallowed up by all the new functions I’ve found that needs to be implemented. It’s an uphill battle.

implementation doesn’t handle the But, I’m happy to say that the latest digression is finished. I have successfully implemented the X509_STORE-family of functions plus all dependencies. In the end I had to create a wrapper for X509Certificate and my own PEM-reader and PEM-writer, since BouncyCastle’sOpenSSL specific aux trust information that can be appended to these certificates.

But anyway, that means there is a Java implementation of X509_STORE, X509_STORE_CTX, X509_VERIFY_PARAM, X509_LOOKUP, X509_LOOKUP_METHOD, X509_TRUST, X509_PURPOSE and a whole slew of others too. About the only thing I didn’t implement was X509_POLICY_TREE. That was just too much. I’ll tackle that hurdle if it seems Ruby needs it.

So, what is the status then? Coming in at almost 10 000 lines of code there is only three real parts left to do. Or, three parts left that have MRI test cases, I should say. Since there are quite a few files not tested in the MRI implementation. Like DH keys. Wow. But I ignore that for now. The current goal is the OpenSSL::X509::Store-family, the OpenSSL::PKCS7-family, and the SSL-stuff, the rest of the way. So, wish me luck.

1 Comment | By Ola Bini | In: Uncategorized | tags: aux, java, jruby, openssl, PEM, X509_STORE. | #

My interesting OpenSSL implementation exercise continues. I am now very close. Very, very close. I’m actually so close that SSLSocket and SSLServer actually works, provided that you use Anonymous Diffie-Hellman (which is suicidal, but that’s another story). All of this have been submitted to my openssl-branch. What’s missing is the X509-store and PKCS#7. And the X509-store doesn’t really look good. Not good at all. It’s needed for full SSL support. But the bad thing is this: there isn’t any Java libraries that duplicate the functionality. Nada. At least not that I can find. The functionality needed is to read and write X509_store-formatted files and directories, to be able to add certificates and CRL’s and to verify against these a certificate, based on various interesting OpenSSL rules.

I wouldn’t say that I mislike OpenSSL. I wouldn’t say that I hate it either. It’s very impressive in many ways. But boy. It seems I have to port a substantial part of it to Java, and I’m not looking forward to it. I need to to do both a port, and add support for KeyStore and CertStore so the Java SSLEngine also can use the information. Will this be an interesting exercise? Oh yes.

So, without further ado, this is the plea of this blog post: If you know of any easier way to do this, please tell me. Now! (where “this” is the X509_STORE-family of functions.)

2 Comments | By Ola Bini | In: Uncategorized | tags: java, jruby, openssl, store, x509. | #

Every time I’ve written Java code lately, I’ve been painfully aware of how much unnecessary code I write every time. And most of this is Java’s fault. This blog post is a very small thought experiment. TIJuAVA does not exist as software. Yet. If I someday have the time I would love to implement it, but there are more pressing needs right now.

So, what are the rules? Basically, all valid Java programs are valid TIJuAVA programs. Some valid TIJuAVA programs are not valid Java programs. Simply put, the main difference is that you don’t need to declare a type for any local variables or member variables. Type declarations are only necessary in method declarations. You can declare local variables and member variables if you want to, and in certain very unlikely circumstances you will need too.

Let’s take a very simple example. This code is taken from the JRuby source code, but I have added one or two things to make it easier to showcase:

package org.jruby.util.collections;

import java.util.ArrayList;
import java.util.Collection;
import java.util.Iterator;

public class IdentitySet {
   private items = new ArrayList();

   public void add(Object item) {
       items.add(item);
   }

   public void remove(Object item) {
       iter = items.iterator();
       while (iter.hasNext()) {
           storedItem = iter.next();
           if (item == storedItem) {
               iter.remove();
           }
       }
   }

   public boolean contains(Object item) {
       iter = items.iterator();
       while (iter.hasNext()) {
           storedItem = iter.next();
           if (item == storedItem) {
               return true;
           }
       }
       return false;
   }

   private Collection getItems() {
       return items;
   }

   private void something(java.util.AbstractSet inp) {
       val1 = inp;
       for(iter = val1.iterator();iter.hasNext();) {
           System.err.println(iter.next());
       }
   }
}

This code doesn’t really show all that can be done with this approach, and if I were to show a real example, this blog would be unbearably filled with code. So, this is just a tidbit.

The TIJuAVA system would need to be implemented as a Java two-pass compiler. Basically, the first pass finds all variable names that need to have a type inferred, and then walks through the information it’s got, basic on method signatures and methods called on the variable. In almost all cases it will be possible to come to one conclusion on which type to use. The compiler would then generate regular Java byte code, basically the same bytecode that would have been generated had you written the types by hand.

Of course, most people use IDE’s to write code nowadays. Wizards and code generators and what not. So why something like this? Well, even though your IDE writes your code for you, it is still there, and you still have to understand it at some level. If not when writing, you would still need to read it. And boy does type declarations clutter things. Especially generics. And here is one interesting tidbit. Generic types would also be possible to infer in most cases.

Another thing that could be easily added is some kind of in-place literal syntax for lists and maps. This would be more like a macro feature, but the list syntax would mostly just be a call to Array.asList, which isn’t to bad.

An objection that I anticipate is from people who think that the code will be less readable by removing the type pointers. This should be more of a problem when you have large methods, but everyone these days use refactorings so they won’t have methods with a LOC over 20. And if that’s the case, the local variables should be easily understood by the operations that are used on them.

So. Someday, when I have time, this may be reality. If anyone is interested, that is.

7 Comments | By Ola Bini | In: Uncategorized | tags: java, programming languages, type inference. | #