September 24th, 2008
Invoke dynamic in JDK 7
First post from the JVM Language Summit. Mark Reinhold just stated that invokedynamic definitely will be in Java 7. This is obviously great news for anyone who cares about dynamic languages.
August 29th, 2008
RSA parameters in OpenSSL, Ruby and Java
I would just like to publish this information somewhere, so that Google can help people find it easier than I did. If you have ever wondered how the internal OpenSSL RSA parameters map to the Java parameters on RSAPrivateCrtKey, this little table will probably help you a bit. There are three different names in motion here. The first one is the internal field names in OpenSSL. These are also used as method names in Ruby. The second name is what gets presented when you use something like to_text on an RSA key. The third name is what it’s called in Java.
- n == modulus == modulus
- e == public exponent == publicExponent
- d == private exponent == privateExponent
- p == prime1 == primeP
- q == prime2 == primeQ
- dmp1 == exponent1 == primeExponentP
- dmq1 == exponent2 == primeExponentQ
- iqmp == coefficient == crtCoefficient
July 4th, 2008
Java and mocking
I’ve just spent my first three days on a project in Leeds. It’s a pretty common Java project, RESTful services and some MVC screens. We have been using Mockito for testing which is a first for me. My immediate impression is quite good. It’s a nice tool and it allows some very clean testing of stuff that generally becomes quite messy. One of the things I like is how it uses generics and the static typing of Java to make it really easy to make mocks that are actually type checked; like this for example:
Iterator iter = mock(Iterator.class);stub(iter.hasNext()).toReturn(false); // Call stuff that starts interaction verify(iter).hasNext();
These are generally the only things you need to stub stuff out and verify that it was called. The things you don’t care about you don’t verify. This is pretty good for being Java, but there are some problems with it too. One of the first things I noticed I don’t like is that interactions that isn’t verified can’t be disallowed in an easy way. Optimally this would happen at the creation of the mock, instead of actually calling the verifyNoMoreInteractions() afterwards instead. It’s way to easy to forget. Another problem that quite often comes up is that you want to mock out or stub some methods but retain the original behavior of others. This doesn’t seem possible, and the alternative is to manually create a new subclass for this. Annoying.
Contrast this to testing the same interaction with Mocha, using JtestR, the difference isn’t that much, but there is some missing cruft:
iter = mock(Iterator) iter.expects(:hasNext).returns(false) # Call stuff that starts interaction
Ruby makes the checking of interactions happen automatically afterwards, and so you don’t have any types you don’t need to care about most stuff the way you do in Java. This also shows a few of the inconsistencies in Mockito, that is necessary because of the type system. For example, with the verify method you send the mock as argument and the return value of the verify-method is what you call the actual method on, to verify that it’s actually called. Verify is a generic method that returns the same type as the argument you give to it. But this doesn’t work for the stub method. Since it needs to return a value that you can call toReturn on, that means it can’t actually return the type of the mock, which in turn means that you need to call the method to stub before the actual stub call happens. This dichotomy gets me every time since it’s a core inconsistency in the way the library works.
Contrast that to how a Mockito like library might look for the same interaction:
iter = mock(Iterator) stub(iter).hasNext.toReturn(false) # Do stuff verify(iter).hasNext
The lack of typing makes it possible to create a cleaner, more readable API. Of course, these interactions are all based on how the Java code looked. You could quite easily imagine a more free form DSL for mocking that is easier to read and write.
Conclusion? Mockito is nice, but Ruby mocking is definitely nicer. I’m wondering why the current mocking approaches doesn’t use the method call way of defining expectations and stubs though, since these are much easier to work with in Ruby.
Also, it was kinda annoying to upgrade from Mockito 1.3 to 1.4 and see half our tests starting to fail for unknown reasons. Upgrade cancelled.
June 15th, 2008
JtestR 0.3 Released
JtestR allows you to test your Java code with Ruby frameworks.
Homepage: http://jtestr.codehaus.org
Download: http://dist.codehaus.org/jtestr
JtestR 0.3 is the current release of the JtestR testing tool. JtestR integrates JRuby with several Ruby frameworks to allow painless testing of Java code, using RSpec, Test/Unit, Expectations, dust and Mocha.
Features:
– Integrates with Ant, Maven and JUnit
– Includes JRuby 1.1, Test/Unit, RSpec, Expectations, dust, Mocha and ActiveSupport
– Customizes Mocha so that mocking of any Java class is possible
– Background testing server for quick startup of tests
– Automatically runs your JUnit and TestNG codebase as part of the build
Getting started: http://jtestr.codehaus.org/Getting+Started
The 0.3 release has focused on stabilizing Maven support, and adding new capabilities for JUnit integration.
New and fixed in this release:
JTESTR-47 Maven with subprojects should work intuitively
JTESTR-42 Maven dependencies should be automatically picked up by the test run
JTESTR-41 Driver jtestr from junit
JTESTR-37 Can’t expect a specific Java exception correctly
JTESTR-36 IDE integration, possibility to run single tests
JTESTR-35 Support XML output of test reports
Team:
Ola Bini – ola.bini@gmail.com
Anda Abramovici – anda.abramovici@gmail.com
May 19th, 2008
Break Java!
As some of you might have noticed I am not extremely fond of everything the Java language. I have spent some time lately trying to figure out how I would change the language if I could. These changes are of course breaking, and would never be included in regular Java. I’ve had several names for it, but my current favorite is unJava. You can call it Java .314 or minijava if you want. Anyway, here’s a quick breakdown of what I’d like to see done to make a better language out of Java without straying to far away from the current language:
- No primitives. No ints, bytes, chars, shorts, floats, booleans, doubles or longs. They are all evil and should not be in the language.
- No primitive arrays. Javas primitive arrays are not typesafe and are evil. With generics there is no real point in having them, especially since they interact so badly with generic collections. This point would mean that certain primitive collection types can’t be implemented in the language itself. This is a price I’m willing to pay.
- Scala style generics, with usage-defined contra/co-variance and more flexible type bounds.
- No anonymous inner classes. There is no need for them with the next points.
- First class methods.
- Anonymous methods (these obviously need to be closures).
- Interfaces that carries optional implementation.
- No abstract classes – since you don’t need them with the above.
- Limited type inference, to avoid some typing. Scala or C# style is fine.
- Annotations for many of the current keywords – accessibility specifically, but also things like transient, volatile and synchronized.
- No checked exceptions.
- No angle brackets for generics (they really hurt my eyes. are there XML induced illnesses? XII?). Square brackets look so much better.
- Explicit separation of nullable from non-nullable values.
These points are probably quite substantial together, but I still don’t think the language would be that difference from Java in syntax and semantics. The usage patterns would be extremely different though. You wouldn’t sacrifice any performance with these kinds of things – they wouldn’t change the characteristics of the output that much, and I believe these things could make the language smaller, cleaner, and easier to work with.
May 15th, 2008
Would Type Inference help Java
My former colleague Lars Westergren recently posted a blog (here) about type inferencing, posing the question whether type inference would actually be good for Java, and if it would provide any benefits outside of just “less typing”.
In short: no. Type inferencing would probably not do much more than save you some typing. But how much typing it would save you could definitely vary depending on the type of type inference you added. The one version I would probably prefer is just a very simple hack to avoid writing out the generic type arguments. One simple way of doing that would be to allow an equals sign inside of the angle brackets. In that case you could do this:
List<=> l = new ArrayList<String>();
List<String> l2 = new ArrayList<=>();
Of course, you can do it on more complicated expressions:
List<Set<Map<Class<?>, List<String>>>> l = new ArrayList<=>();
This would save us some real pain in the definition of genericized types, and it wouldn’t strip away much stuff you need for readability. In the above examples it would just strip away one duplication, and you don’t need that duplication to read it correctly. The one case where it might be a little bit harder to read would be if you defined a variable and assigned it somewhere else. In that case the definition would need to carry the type information, so the instantiation would use the <=> syntax. I think that would be an acceptable price to reduce the verbosity of Java generics.
Another kind of generics that would be somewhat useful is the kind added to C#, which is only local to a scope. That means there will be no type inferencing of member variables, method parameters or return values. Of course, that’s the crux of Lars question, since this kind of type inference potentially removes ALL type information in the current text, since you can do:
var x = someValue.DoSomething();
At this point there is no easy way for you to know what the type of x actually is. Reading it like this, it looks a bit frightening if you’re used to Java type tags, but in fact this is not what you would see. In most cases you have a small method – maybe 5-15 lines of code, where x is being used in some way or another. In many cases you will see methods called on x, or x used as argument to method calls. Both of these usages gives you clues about what it might be, but in fact you don’t always need to know what type it is. You just need to know what you can do with it. And that’s exactly what Java interfaces represent. So for example, do you know what class you get back from Collections.synchronizedMap()? No, and you shouldn’t need to know. What you do know is that it’s something that implements Map, and the documentation says that it is synchronized, but that is it. The only thing you know about it is that you can use it as a map.
So in practice, the kind of type inference C# adds is actually quite useful, clean, and doesn’t cause too much trouble – especially if you have one of those fancy ideas that do method completion… =)
From another angle, there are some things that type inference could possible do, but that you will never see in Java. For example, say that you assign a variable to something, and later you assign that variable to some other value. If these two values are distinct types that doesn’t overlap in the inheritence chain, you will usually get an error. But if you have an advanced type system, it will do unification for you. The basic versions will just find the most common supertype (the disjunction), but you can also imagine the compiler injecting a new type into your program that is the union of the two types in use. This will provide something similar to duck typing while still retaining some static type safety. If your type system allows multiple inheritence, the synthetic union type might even be a subclass of both the types in question.
So yeah. The long answer is that you can actually do some funky stuff with type inference that doesn’t immediately translate to less typing. Although less typing and better abstractions is what programming languages are all about, right? Otherwise assembler provides everything we want.
April 15th, 2008
Connecting languages (or polyglot programming example 1)
Today I spent some time connecting two languages that are finding themselves popular for solving wildly different kinds of problems. I decided I wanted to see how easy it was and if it was a workable solution if you would want to take advantage of the strengths of both languages. The result is really up to you. My 15 minutes experiment is what I’ll discuss here.
If you’d like, you can see this as a practical example of the sticky part where two languages meet, in language-oriented programming.
The languages under consideration is Ruby and Erlang. The prerequisite reading is this eminent article by my colleague Dennis Byrne: Integrating Java and Erlang.
The only important part is in fact the mathserver.erl code, which you can see here:
-module(mathserver).
-export([start/0, add/2]).
start() ->
Pid = spawn(fun() -> loop() end),
register(mathserver, Pid).
loop() ->
receive
{From, {add, First, Second}} ->
From ! {mathserver, First + Second},
loop()
end.
add(First, Second) ->
mathserver ! {self(), {add, First, Second}},
receive
{mathserver, Reply} -> Reply
end.
Follow Dennis’ instructions to compile this code and start the server in an Erlang console, and then leave it there.
Now, to use this service is really easy from Erlang. You can really just use the mathserver:add/2 operation directly or remotely. But doing it from another language, in this case Ruby is a little bit more complicated. I will make use of JRuby to solve the problem.
So, the client file for using this code will look like this:
require 'erlang'
Erlang::client("clientnode", "cookie") do |client_node|
server_node = Erlang::OtpPeer.new("servernode@127.0.0.1")
connection = client_node.connect(server_node)
connection.sendRPC("mathserver", "add", Erlang::list(Erlang::num(42), Erlang::num(1)))
sum = connection.receiveRPC
p sum.int_value
end
OK, I confess. There is no erlang.rb yet, so I made one. It includes some very small things that make the interfacing with erlang a bit easier. But it’s actually still quite straight forward what’s going on. We’re creating a named node with a specific cookie, connecting to the server node, and then using sendRPC and receiveRPC to do the actual operation. The missing code for the erlang.rb file should look something like this (I did the minimal amount here):
require 'java'
require '/opt/local/lib/erlang/lib/jinterface/priv/OtpErlang.jar'
module Erlang
import com.ericsson.otp.erlang.OtpSelf
import com.ericsson.otp.erlang.OtpPeer
import com.ericsson.otp.erlang.OtpErlangLong
import com.ericsson.otp.erlang.OtpErlangObject
import com.ericsson.otp.erlang.OtpErlangList
import com.ericsson.otp.erlang.OtpErlangTuple
class << self
def tuple(*args)
OtpErlangTuple.new(args.to_java(OtpErlangObject))
end
def list(*args)
OtpErlangList.new(args.to_java(OtpErlangObject))
end
def client(name, cookie)
yield OtpSelf.new(name, cookie)
end
def num(value)
OtpErlangLong.new(value)
end
def server(name, cookie)
server = OtpSelf.new(name, cookie)
server.publish_port
while true
yield server, server.accept
end
end
end
end
As you can see, this is regular simple code to interface with a Java library. Note that you need to find where JInterface is located in your Erlang installation and point to that (and if you’re on MacOS X, the JInterface that comes with ports doesn’t work. Download and build a new one instead).
There are many things I could have done to make the api MUCH easier to use. For example, I might add some methods to OtpErlangPid, so you could do something like:
pid << [:call, :mathserver, :add, [1, 2]]
where the left arrows sends a message after transforming the arguments.
In fact, it would be exceedingly simple to make the JInterface API downright nice to use, getting the goodies of Erlang while retaining the Ruby language. And oh yeah, this could work on MRI too. There is an equivalent C library for interacting with Erlang, and there could either be a native extension for doing this, or you could just wire it up with DL.
If you read the erlang.rb code carefully, you might have noticed that there are several methods not in use currently. Say, why are they there?
Well, it just so happens that we don’t actually have to use any Erlang code in this example at all. We could just use the Erlang runtime system as a large messaging bus (with fault tolerance and error handling and all that jazz of course). Which means we can create a server too:
require 'erlang'
Erlang::server("servernode", "cookie") do |server, connection|
terms = connection.receive
arguments = terms.element_at(1).element_at(3)
first = arguments.element_at(0)
second = arguments.element_at(1)
sum = first.long_value + second.long_value
connection.send(connection.peer.node, Erlang::tuple(server.pid, Erlang::num(sum)))
end
The way I created the server method, it will accept connections and invoke the block for every time it accepts a connection. This connection is yielded to the block together with the actual node object representing the server. The reason the terms are a little bit convoluted is because the sendRPC call actually adds some things that we can just ignore in this case. But if we wanted, we could check the first atoms and do different operations based on these.
You can run the above code in server, and use the exact same math code if you want. For ease of testing, switch the name to servernode2 in both server and client, and then run them. You have just sent Erlang messages from Ruby to Ruby, passing along Java on the way.
Getting different languages working together doesn’t need to be hard at all. In fact, it can be downright easy to switch to another language for a few operations that doesn’t suit the current language that well. Try it out. You might be surprised.
March 10th, 2008
I’m at QCon
I’m attending QCon in London this whole week. I’ll give a talk on Thursday called “Evolving the Java platform”, talking about different things that might be a part of the next generation Java platform. On Friday I give the talk “JRuby: Power on the JVM”, which is a more advanced JRuby talk than the regular introduction talks I usually give.
Hope to see you around!
February 15th, 2008
Is Groovy like Java?
I usually don’t mention the G word in my blog – the results have a tendency to be less than palatable. This time I’m going to make an exception though. The reason is that this meme has been floating around as an argument for Groovy, and I really don’t agree with it. In fact, the reason I’m writing about it is because I think the meme in itself generally can be bad for Groovy.
The thing I’m talking about is the saying that Groovy is just like Java. That you can start using Groovy directly without learning anything about Groovy and that basically all Java syntax is valid Groovy.
Now, the last part has never been really true, since there are a few valid Java constructs that are not supported in Groovy (anonymous classes, I’m looking at you). This might be fixed in the 1.5 version. I don’t really know, but that’s not the point. Since Groovy isn’t using the Java parser there will always be a few small corner cases that are not valid in Groovy but Java accepts. This is not a problem, by the way. The only way it can be a problem is when you’re using Groovy the wrong way, or you absolutely need to do something that Groovy doesn’t support. Since one of the Groovy catch calls is that you shouldn’t implement everything in Groovy, this can’t really be a concern either. If you’re using Groovy correctly, you should just drop down to the Java layer for that particular feature.
Now that that part is out of the way, let’s take a look at the other parts of this idea. Namely that you should choose Groovy because it’s just like Java, and you can start writing Java code directly in Java. These statements are definitely true, since you can absolutely pick up a language that way. In my mind, though, this misses the whole point of using another language on top of the JVM. If you’re building an application and chooses to use Groovy for this instead of Java, isn’t the reason that you’re doing that the fact that you expect Groovy to give you something Java does not? And if that’s the case, doesn’t it sound like a disservice to people picking up Groovy to say that they can begin by just programming Java. There is no gain here. Really. In fact, the equivalent program in Groovy and Java will perform much worse on Groovy since there are several layers of dispatching in Groovy that you don’t have in Java. The result? An application with exactly the same source code, but running 10 times slower.
Since this message is mostly used in marketing and introduction facilities, the people it’s geared at are by definition newbies to the Groovy world. Many of them are totally new to dynamic languages. And the first thing they do is write Java in Groovy, find it slow and obviously, from that point don’t understand why you should use Groovy. This is bad for Groovy. Groovy has some extremely powerful features and libraries that can really make your life on the JVM blissful (compared to using Java, for example). Groovy’s integration with Java is top notch, which means that you can always fall back to Java when you need Java specific features. If you’re using Groovy, I think you should use the full power of the language so you can actually get the full benefit of Groovy.
February 13th, 2008
Java Annotations
I feel that a few rants are about to burst in me. Let me take this first; this is not a rant, though. Just a very large exclamation:
Java Annotations are NOT a way to implement DSLs, and will never be.
Java annotations are really nice, but seriously, they are NOT manna from heaven.
