Posts tagged with "jvm"

Tim Bray on the JVM being the good part of Java:

“But the Java language just doesn’t seem like the interesting thing about Java, these days.”

I wish more Java programmers would agree to this. One of my observations at JFokus the other day was that a lot of people really like Java the language, and are going through hoops to implement their ideas in it.

Stephan Janssen has created a kick ass new version of parleys.com in Flex/Air, but he wants to redo it all in JavaFX script, just so that it is Java. Rickard Öbergs new framework for composite oriented programming could be useful, but in my opinion it introduces enough new concepts to qualify for a whole new language. Lipsticking on top of Java makes it feel verbose and clumsy. After a year of Ruby I have very little patience for Java interfaces.

I cannot help myself from making a small comment on Rick Hightowers post on Groovy vs JRuby. In short he thinks Sun should support Groovy instead og JRuby, because the syntax is familiar to Java programmers.

To support his case he presents a chart showing language popularity according to job postings. And since Ruby is at the bottom and Java is on the top, Sun should support Groovy. Which by the way is not even on the chart.

I spent yesterday evening at Javaforum. Ola Bini held a great presentation of JRuby that really showed what can be accomplished today and what we can expect in the future.

Ola is not only an über hacker, he is a great guy too. When asked what work is done with Ruby in Sweden today, he was kind enough to mention the work we’ve done at Valtech with Rails, which of course got him a well deserved beer later.

Yesterday we discovered a small but annoying performance bug: when getting a list of languages from the JVM we did not cache them but kept on retrieving them, which turned out to be quite slow.

So, like the good guys we are we wanted to have a test that ensured that the error was not reintroduced. We looked at JUnitPerf which seemed to be appropriate - it decorates a unit test and times it. The only problem here was that we were talking about that good performance was 800 ms, and bad performance was 1800 ms. Such timings can randomly fail on a slower computer or a computer that was busy doing something else. We do not like that kind of tests.