So Apple finally got around to releasing Java 6 for OS X.
Pity it’s Leopard only, but better than nothing (I really have to get around to upgrading).
This Java for Mac OS X 10.5 Update 1 adds Java SE 6 version 1.6.0_05 to your Mac. This update does not replace the existing installation of J2SE 5.0 or change the default version of Java.
Eric Redmond over at Death by Overcoding has posted a discussion on 5 Reasons Static Typing Sucks
It’s a great article, and I agree with pretty much all of it. For the most part excessive static typing is a PITA. The illusion of safety is just that. Static compile time checks only catch the most trivial of bugs, and even then, most of those would have manifested themselves the first time the code was even run. When it comes down to it, the trade offs of the traditional benefits of static typing (you don’t shoot yourself in the foot; you and the compiler always know what’s going on), are often outweighed by the disadvantages discussed in the article.
However, the one thing I’ve always liked when working with static type systems, and one that is often glossed over when discussing dynamic typing systems, is how easily tools can interpret and navigate code. When coding Java in Eclipse, it’s amazing how easy understanding a massive code base can become. You’ve got simple hyperlink navigation, sophisticated refactorings, and smart code analysis that can show you what is called from where and how. Even interfaces and figuring out which implementation is used (which is kinda dynamic typing for Java) can be groked easily with a good IDE.
Got a class with some methods? Want to find where it’s called from? Check. Want to find what methods can be called on the argument you’ve been passed? Check. Want to refactor a whole class hierarchy? Check.
I really love Ruby, but the first thing that struck me when I sat down to code is how much you’re on your own figuring out what is happening. Got a method with an argument passed in? What is it? What can you do with it? Dunno. Want to call another method? What arguments does it take? What about the block it accepts? What does it return? Dunno.
Dynamic languages are great for quickly writing simple elegant code, but not always so great for following and debugging existing code (especially code someone else has written).
Try digging into the internals of Rails, and you’ll become very familiar with the free text search of your text editor. What the hell is that variable? Where was it even instantiated? Dunno. Once you understand the general layout of the classes and modules its pretty straight forward, and thankfully Rails has a pretty well laid out architecture. Which is probably the whole point. If your Ruby code is clean and well designed, then obviously it’s going to be easier to navigate.
So really it comes down to good developers doing smart things. The size and complexity of a good Ruby code base is significantly less than something comparable written in Java for instance. As with most things in software development, this is about trade offs. Ruby is smaller and simpler, but the tools don’t allow you to refactor as easily as Java (the agile purists will say your unit tests allow you to refactor, but it’s still a lot more manual and involved than the automatic refactorings you can do in Java).
It means that in dynamic languages, its more important to have a good design so you don’t get lost in dynamic spaghetti down the track. But at the same time you’re more likely to have a good architecture in the first place because you’re not wasting mental energy focusing on satisfying the static typing system. One of the weakness of static typing discussed in the original article touches on that - the fact that more design must be done up front to predict the future when using static typing. With dynamic typing you’ve got less baggage stopping you from evolving your design as you work, so you can apply the YAGNI principle more easily.
…Although I do still miss being able to zip around Ruby code like I can in Java.
(Yeah, I know Netbeans is getting there, but it’s still a long way behind what you can do with tools analysing and refactoring static typed code).
A decade ago, people said you couldn’t do refactorings and static code analysis with Java. Maybe IDEs will evolve enough over the next few years will make this true for Ruby as well, and we’ll get the best of both worlds.
An interesting bit of digging on damnhandy into the WWDC session list points out that Java on Leopard (Mac OS X 10.5) is going to sport a 64 bit Java VM, along with Swing support for the new Leopard UI features. The WWDC notes are pretty brief and just buried in the general session listing page, so details are still sketchy.
javascript:void(0)
The interesting thing damnhandy points out, is that seeing as Leopard Java (Java 6?) is going to be 64 bit, it probably won’t run on Tiger (Mac OS X 10.4). That’s kind of a shame, but it’s better than nothing. I posted a few weeks ago that as a developer, I just want something that lets me develop Java code for other platforms and could care less about Swing support for the new Leopard UI. I wish Apple would either release Java 6 that runs with Tiger (even without Leopard support), or release the source to OpenJDK if they aren’t going to maintain it.
The session took place at 9am PDT (about 7 hours ago). Haven’t been able to find any details yet as to what was in it, but will update when info become available.
Update - actually, there was no new info. So Java 6 on OS X is still out in the wilderness…
Developing Java apps on Mac OS X is pretty nice in general: The tools are as good, if not better than other platforms (having a proper command line beats Windows any day); compiling and execution runs fast enough; and the hardware and the OS itself is a pleasure to use.
My only complaint, and one that is getting a bit of noise, is that there is no production release of Java 6 available. Sure, there is a preview version from months ago. But the final version has more than a few differences in the API, and I’m guessing a stack of defect and performance fixes as well.
The rumor is that Apple is not releasing Java 6 till Leopard ships (around October). Supposedly so Java 6 on OS X will support the Leopard look and feel. Which is a pain in the neck - I couldn’t care less if Java 6 looks like Leopard. To be honest it’s a pretty small minority that must use it as a runtime environment. However OS X must get a lot of use as a development environment. Most of the development I do is for apps that are going to run on Windows anyway. Surely Java 6 could just be released first, and then a separate look and feel plugin for Leopard released after the fact? (it’s not like that is all that hard with Swing)
The rumors about Leopard are just that - rumors. There hasn’t been anything official from Apple saying what the release schedule looks like.
Simon Brocklehurst sums it up:
What is particularly frustrating, however, is that Apple remains totally silent on their Java strategy. When will Java 6 see a production release on MacOS X? With the Leopard release? Somtime in 2008? In 2015? Never? No-one has any idea; and Apple isn’t talking - not to developers; not to customers; not to anyone.
Now, however, the OpenJDK project is… well… open! The Java platform is moving full steam ahead to Open Source under the GPL. All of which begs the question is: will the Apple developer community decide to build their own up-to-date version of Java that runs on MacOS X? If Apple would only make their Java strategy clear, it might help the community figure out if that’s worth doing or not…
I can live with delayed releases, but it makes planning development a bit more difficult when you’re playing guessing games. A little more certainty would be nice.
Shine Technologies (my workplace) has sent a couple of international jet setters over to San Francisco for this year’s JavaOne conference.
Mark Johnson and Ben Teese have been writing about their experiences on Shine’s blog. Reports on various presentations and the keynote are covered.
Meanwhile I’ve been sent to lovely Tasmania. Which is kind of overseas… well I mean you fly over the sea to get here from mainland Australia. Anyway, the beer is better here than on the mainland and the cooler climate is more suited to my kiwi body temperature.
After doing a bit of Ruby coding, I get that "this should be easier" feeling when working in Java for any length of time. An example of that is doing some simple operation on a list. In this case, I’m wanting to do something trivial.
The task is simple: given an unsorted list of objects, find the lowest value of some property.
In Java this would look something like:
Date startFoo = null;
for(Foo f : getFoos()) {
if (startFoo == null) {
startFoo = f.getStartDate();
} else {
startFoo = (startFoo.before(f.getStartDate()) ? startFoo : f.getStartDate());
}
}And in Ruby, this would look something like:
get_foos.map{|f| f.start_date}.inject{|low,start| low < start ? low : start}Not a huge difference in code length or complexity, but once you start needing to do this a few times the extra verbosity starts to add up. All that typing makes it harder to build momentum and get into flow while coding. In any example more complicated than this you’d often have to explicitly handle generic declarations or type casting (which means even more typing). In Ruby you can pretty much think of how it’s going to work, and just run with it (once you grok how map and inject work).
There is a lot of talk about adding closures to Java 7. That’s something I’d love as it would make a lot of the techniques used in Ruby possible in Java. I just hope that it’s done better than when generics were introduced in Java 5. (We’ve just upgraded one of our products from 1.4 to 5, and I’ve been exposed to generics in action for the first time. Not so impressed so far… but that’s another post.)
UPDATE
As pointed out by robert in the comments, there is an even simpler approach:
get_foos.map{|f| f.start_date}.minCheers 
My recent post "JRuby Can Save Swing" generated a bit of discussion around the blogosphere. A few blogs replied, and a lot of good points were made. I was a little disappointed that most of the rebuttal I got was in regard to Joshua Marinachi’s original 2003 post and his list of why Swing sucks, and not to the points I raised about the potential that a new framework based in JRuby could provide. I guess that is blogging-101 - put your payload at the front and minimize the lead up. 
From the original post, my dream list for a higher level GUI framework for Swing are
pinderkent replied with the idea that Swing is beyond saving, and nothing JRuby or anything else can do can save it. I don’t think Swing is at that point. I think in the last few years Swing has turned a corner an is improving with each release (5 was great, 6 is good as well). My initial article title was intentionally a little inflammatory. I don’t actually think Swing “needs” saving. All the same I think there are some areas that can be helped out.
Pinderkent then trots out the tired “Swing is slow argument”. This may have been the case… on a Pentium 2 back in 1998. This has not been true for a long time. Swing itself is more efficient, and CPUs are faster. It just isn’t an issue anymore. The pinderkent says they haven’t actually done any profiling. Nuff said.
Danno Ferrin responded to pinderkent and makes the point in another follow up:
"The stock answer to this is always true: "bad programmers abuse the Event Dispatch Thread." Seriously, whenever anyone wants to start programming Swing someone else needs to get a stick and beat them until they write in blood the oath "I will not do data processing in the Event Dispatch Thread." "
Which is exactly my experience. It is possible to create snappy, responsive Swing apps - but the moment anyone does some heavy processing, or a database call, or file operation from a listener - you’re wading through mud. Maybe that’s an extra point for my framework wish list: "Makes using worker threads instead of the EDT the path of least resistance for heavy operations."
Danno Ferrin’s main point is that Groovy would be a more suitable layer for Swing than JRuby.
The argument is that Groovy is closer to Java and it would mean developers wouldn’t have to learn all of Ruby’s weird syntax and "ugly PERLisms". Maybe. I have to admit I haven’t had any exposure to Groovy. Ruby isn’t difficult to pick up though, and the syntax arguments are really just a matter of opinion. What I believe makes Ruby ideal as a DSL/wrapper API layer is the level of meta-programming Ruby affords to achieve things that are impossible in Java. I’m talking about things like stupidly easy model-view binding. In ruby you can do something like
model = Person.new(’Julian Doherty‘, ‘julian@example.com‘) name_label = JLabel.new name_label.bind_to model, :name email_field = JTextField.new email_field.bind_to model, :email
And have the text label and field bound to the model so changes on either side are automatically replicated to each other - all without a single line of event listener glue code. I’ve got some sample code showing this working, and will write something about it soonish. I’ve already written about Transparent Property Change Listeners for Ruby bean-type classes, which shows part of the solution.
I don’t know if Groovy gives you that or not. If it does, great. If not, then that’s a reason to consider JRuby over Groovy.
Homework for me: grok Groovy so I’m better informed on this
Daniel Spiewak posted a rebuttal of Joshua Marinachi’s original “why Swing Sucks posts” that I reposted.
It’s a good post and A lot of his points were on the money (which I won’t discuss much except to say I agree): his discussion of layout managers (GroupLayout etc); native feature integration; and Swing’s bad perception from a troubled past.
A few didn’t quite stack up with me though.
In arguing that Swing GUIs are just as easy to construct in Java as JRuby, Daniel Spiewak provides an overly simple UI consisting of a label and three buttons - implemented both in JRuby and then Java. The two versions are almost identical, and there is no difference in code complexity or length (how surprising!). Problem is, the examples didn’t have anything done in the real world: no advanced layout, no event handling, no model/view interaction, no validation. It’s a weak straw man argument that really doesn’t tell us anything.
A more interesting example would be to compare a straight Java implementation of a reasonably complex application (including any cool 3rd party libraries) and a JRuby framework based implementation (using all the Ruby black magic possible). My guess is that the JRuby version would come out ahead.
Daniel Spiewak then says that a reasonably complex UI could be coded in a few hours by a himself, and half that by Romain Guy.
So what?
It’s a pretty arbitrary metric which still doesn’t say anything. What would be interesting again is the difference between Java and a JRuby framework implementation. Maybe JRuby only takes one hour or maybe it takes five? I don’t know. My guess though is that again it would take far less code, would be easier to test, and would be finished quicker in JRuby by the same developer.
Daniel Spiewak also questioned whether using XML to store the GUI config is a good idea. I AGREE! XML is horrible and is abused in Java land (I actually said to use YAML in the original post as it is a bit more human friendly). I wasn’t advocating to use XML/YAML to create the whole GUI - just as a mark up to separate the layout from the component instantiation and move layout out of the view code.
My opinion is that code is good for expressing view logic, but not visual layout. That would be better served by some separate markup.
One of the main beefs I’ve got with Java/Swing and one that Daniel Spiewak’s touched on, is the difficulty maintainability of Swing apps. He says that main problem with bad Swing apps is that bad developers don’t do a good job - which I totally agree with! It is definitely possible to structure a good Swing app and develop it in a nice clean way, but to do things the right way is a lot of work. The path of least resistance is to take short cuts and just get it done (especially when deadlines are pressing). Yes, Swing has a nice MVC architecture, and best practice says you should build apps that way - but it’s just too much work to use properly in the real world.
I liked a quote from one of Danno Ferrin’s other related blog posts “Groovy, Verbosity, and Swing:
“I think that the greatest problem with the swing APIs are not that they are too complex or too poorly explained. The biggest problem I see is that to do simple things the correct way, it can get quite verbose. Kind of like reliable file I/O, but you get far fewer urgent-1 bug in the GUI than in core I/O routines. Perhaps the best thing isn’t to change the Swing APIs, but to add more syntactic sugar.”
Which is exactly what I was trying to get at with my original post. Swing is a great low level API, and provides the developer with a lot of power to do things. Problem is, the path of least resistance is to produce ugly crud that barely works. Where as something like Rails provides a path of least resistance that results in elegant and well structured code.
Every API acts like a multiplier for developer productivity, and has a response curve of varying slope. Some frameworks make good developers amazing while making mediocre developers passable (Rails springs to mind).
Swing seems to do the opposite though. It makes amazing developer’s work merely good, and mediocre developer’s work unacceptable.
Steve said…
I agree with the sentiment, but not to craft yet another solution.
Why don’t we just call this Eclipse or NetBeans RCP?
Really these things have been done, what we lack is people understanding and using them.
There is a JSR on the table for a Swing framework too - JSR-296, this will help quite a bit.
Good points. I have to plead ignorance on exactly what the Eclipse and NetBeans RCPs provide (more homework for me!). However one of the benefits of JRuby is all the meta-programming that is either impossible or overly verbose in Java. They also both smack of the whole Big Java philosophy (XML configuration and all!) which a lot of developers are getting disillusioned with. As for JSR-296 - it’s definitely a good thing, and any framework should build on top of it, not replace it.
Anonymous said…
Groovy already has a SwingBuilder, which I suppose you could duplicate in Ruby… but most of these are done arleady.
Good point, but layout is just a small piece of the puzzle. My understanding is that SwingBuilder just helps you with the layout and still leaves everything else (binding, application structure etc) to you to implement
I’m keen to experiment with some of my original ideas from JRuby Can Save Swing. I’m trying to pick a small/medium, low-risk project to roll a basic JRuby Swing framework for and see how it goes. So far I’ve been doing a few little demos that show off some of the basic concepts (will post some examples soon!). It’s definitely promising, but it’s hard to tell from anything that small.
Stay tuned
Last Friday I attended a packed breakfast seminar to hear Martin Fowler speak. The event was put on by Enterprise Java Australia. After filling the original venue, it was moved to Melbourne Town Hall. All up there must have been around 300 people who dragged themselves out of bed early to eat bad food, drink bad coffee, and sit in uncomfortable chairs for 2 hours to hear Martin speak.
Disclaimer - the following is all based on my early morning, caffeine-deprived memory of the talk. Any resemblance to actual events or persons alive or dead is purely co-incidental
The event was titled “Software Design in the 21st Century”. Martin started by explaining that this was an intentionally vague title that would let him talk on whatever he felt like on the day.
The talk opened with Martin talking about how far Java has brought us over the last 10 years (in spite of any short comings, which were discussed next…). Both in terms of the language and platform, and in terms of the greater community.
Martin then did a round up of the audience to get the perception of pain points in Java, (and added a few of his own).
Martin said he didn’t claim to be a futurist, and preferred just to talk about recent and current trends and only look at the near term. This was the bulk of the talk, and was the most interesting section.
All up an interesting talk. Nothing ground breaking, but most of it fitted with my thinking on Java’s direction - especially the discussion of Rails type frameworks, which is exactly what I was getting at in my last post on JRuby Can Save Swing.
I expected Martin to be American for some reason, he’s actually English.
As part of a project to write some nice Ruby APIs for creating Swing GUIs, I’ve been a little frustrated with the exceptions from JRuby in the Java code that calls it - particularly getting stack traces, and error messages.
Say you’ve got some code like this:
try {
new ScriptEngineManager().
getEngineByName("jruby").
eval("raise 'foo is too bar'");
} catch (Exception e) {
e.printStackTrace();
}You’ll get output that looks something like:
javax.script.ScriptException: org.jruby.exceptions.RaiseException
at com.sun.script.jruby.JRubyScriptEngine.evalNode(JRubyScriptEngine.java:376)
at com.sun.script.jruby.JRubyScriptEngine.eval(JRubyScriptEngine.java:138)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:245)
at Borked.main(Borked.java:9)
Caused by: org.jruby.exceptions.RaiseExceptionNot very helpful. How are you supposed to know what went wrong where?
After a bit of poking round with the debugger, it turns out there is more information in the exception you get back. You just have to work to get it. The following code will grab the Ruby exception message and stacktrace and spit it back out in the same style as native Java exceptions are output.
try {
new ScriptEngineManager().
getEngineByName("jruby").
eval("raise 'foo is too bar'");
} catch (Exception e) {
RaiseException re = (RaiseException)e.getCause();
System.out.println(re.getException().getMetaClass() + ":" + re.getException().toString());
RubyArray rubyStackTrace = (RubyArray) re.getException().backtrace();
for(Object stackLine : rubyStackTrace) {
System.out.println("\tat " + stackLine);
}
}Here’s the output from some code I’ve been working on
ArgumentError:unknown key:foo
at /development/wring/classes/wrung_test.rb:17:in `each'
at /development/wring/classes/wrung.rb:43:in `populate_defaults'
at /development/wring/classes/wrung_test.rb:17:in `add_comp'
at /development/wring/classes/wrung_test.rb:17
at :0:in `require’
at :0 Which is pretty much exactly what a Java stack trace would look like - except its for the Ruby code running inside JRuby called by Java.