Skip to main content

Skinny Rails and All

Posted by editor on February 20, 2007 at 10:56 AM PST

What's the right response to Ruby?

Sorry about the lack of an editor's blog yesterday -- we've had some problems with the blogging engine that were not resolved in time for yesterday's editor's blog to get posted. Because of this, yesterday's front page didn't get archived, so today's blog will highlight everything on yesteday's page as well as today's.

In a short but thoughtful discussion-starter on InfoQ, Desktop Java Live author Scott Delap asks Must Java Have an Answer to Rails? He notes that there are two trends playing themselves out in the Java community in response to Rails. The first is running Ruby on the JVM, with JRuby fast approaching full compatibility with Rails. The second is trying to recapture the "secret ingredients" that make Ruby and Rails so appealing, such as simplicity and convention-over-configuration.

What Scott doesn't address in his write-up is the title question: does Java even need to try to adopt some of Ruby and Rails' traits? In a comment, Javier Paniza makes an interesting point:

About Ruby, I personally prefer Java simply because it's a strong typed language, in this way the compiler is always our friend. Remember the the real problem of software is not in the initial development. Remember the Meyer's words about Eiffel vs Smalltalk (a 80s debate).

This statement of strong typing reminded me of something very interesting in a blog comment. Replying to Daniel Jalkut's claim on the Red Sweater Blog that C Is The New Assembly, former Apple Java team member Jens Alfke made an interesting comment about the suitability of loosely-typed scripting languages for building GUI's:

One problem I suspect will bite people using scripting-language bridges is the lack of type checking. Yes, I've read all the propaganda about "duck typing" and how the lack of type checking makes you more Agile. For small quickie bits of code, I tend to agree. However, in a full app, type errors will bite you in the ass. A lot.

Now, if it's a web app, being obsessive about testing can save you. You use tests to drive development, you use all the cool Rails features to write test cases that drive your whole app to test out every single feature, and so on. Fine. So you make zillions of type errors, and the compiler won't catch them, but your test cases will, and you run the test cases every five minutes.

But in my experience, GUI apps are orders of magnitude harder to test than something that's linear and stateless and driven by a single command pipe. GUI apps have huge amounts of state, and all kinds of weird timing issues, and simulating real-world interaction in a repeatable way is very hard to do. I have never known of a real-world GUI app that got most of its testing from some kind of automated process. Rather, the vast majority of bugs get shaken out by actual users doing actual stuff with the app, in unpredictable ways, and filing bug reports.

So Jens (even though he rather prominently bailed on Java a while back) is making the same argument that Javier is: that strong typing and catching things at compile time is your friend.

All of which might explain why we don't see a lot of activity binding scripting languages to GUI frameworks. It seems like it should also be an argument in favor of using Java for desktop development. So what's the hold-up there? Don't assume it's some variant of "Swing sucks". Far from it. Another blog cited on the front page argues that "Java Swing is currently the best GUI toolkit - by a long way - if you want to build cross-platform user interfaces. Incidently, it's also the most popular, too." Responding to the much discussed Hybridizing Java (in which Thinking Java author Bruce Eckel advocates Flash/Flex based GUI's over Java clients) Simon Brocklehurst asks Is Bruce Eckel Right? Maybe Not.. His argument is that the difference is not in the GUI libraries at all, and that Flash applciations are popular "because they're so easy to deploy reliably. That's it. It's an application deployment issue. Plain and simple. Java Web Start doesn't cut it - it asks the user too many 'hard to understand' questions before running (that means it's fine for experts, but regular people just get confused), it looks ugly at start-up, and, even more importantly, people want applications that run inside the browser."

So there's some ideas to chew on, and some action items to take: Java's strong typing is actually an advantage, but where it could do the most good (the desktop), Java is held up by other problems (deployment). Do you buy this line of thinking? Do join in the comments below.

Also in Java Today, the Mac Java Community page notes that
a pair of updates have just been released for Java on Mac OS X 10.4 (Tiger) and 10.3 (Panther). The Java for Mac OS X 10.4 Release 5 "adds support for the latest Daylight Saving Time (DST) and time zone information as of January 8, 2007, and delivers improved reliability and compatibility for Java 2 Platform Standard Edition 5.0 and Java 1.4 on Mac OS X 10.4.8 and later. This release updates J2SE 5.0 to version 1.5.0_07, Java 1.4 to version 1.4.2_12 and improves SWT compatibility for J2SE 5.0." The Java for Mac OS X 10.3 Update 5 updates Java 1.4 to 1.4.2_12 and "addresses a problem where some Java applications fail to launch."

Java SE 6 was the first release in a while to offer a significant number of new features explicitly for the desktop developer. In the SDN article New and Updated Desktop Features in Java SE 6, Part 1, Robert Eckstein starts to look at some of these in depth, including splash screens,, access to the system tray, a fix to the "gray rect" problem, sub-pixel anti-aliasing on LCD displays, look-and-feel improvements, and more.

In episode 24 of the NetBeans Podcast, Roumen Strobl interviews Geertjan Wielenga, a technical writer on the NetBeans team, based in Prague. Topics include the various NetBeans platform tutorials, Geertjan's update center, and his upcoming NetBeans book.

The mobile & embedded community is running a poll to assess interest in a certain style of tool. "A href="">recent
discussion in the phoneME Advanced forum touched on JavaCheck, a
now-stagnant technology that lets you test an app's compatibility with a
specific Java API and the devices that implement it. href="">Take our poll and
let us know if you would find value in such a tool."

Today's Feature Article, revives the not-so-stupid question series with the sensible query What's the Difference Between Wildcard Generics and no Generics? In other words, "What is the difference between specifying a wildcard for a genericized type and not using the generic notation at all?", since you can omit the generics altogether, and thereby replace something like List<?> with just List. Have a look at the question and its example, and feel free to join in the discussion.

This week's Spotlight section links to the wiki pages for JavaOne. The Community Corner wiki is where you can check out the posted mini-talks, or sign to present your own mini-talk, providing a title, speaker, and abstract. The latter is important, because we'll copy-and-paste it into the podcast feed, meaning it'll help listeners around the world decide which talks to listen to. Also on the wiki, check out our overall JavaOne wiki page, in which we'll be keeping track of technical session and BoF's presented by members (once they're announced), along with other activities during the week.

A thread in the Forums started recently, in response to a two-year-old blog that makes the argument that making Java available on Windows hurts Linux and therefore Sun should stop making Java for Windows.
podlesh rejects the argument in
Re: Java has harmed Unix but helped Windows win:
"Sorry, I think you are just wrong. I understand the feeling, I'm UNIX guy too (although younger one, almost the "linux" generation). Windows and their environment is something new, strange, different, sometimes just twisted. Unfortunately, most people out there consider Windows as THE operating system and environment. This "new linux thing" is just "new", "strange", "different" for them. And most decision makers are from this category. Removing Java from Windows would be just major blow to UNIX. Programmers will NOT rush to install Linux/Unix on their PC to continue working: they will be forced to install Windows."

barz26 would like to slim down GlassFish in
Minimalistic GlassFish V2 Installation possible?
"Hi is it possible to reduce a GlassFish installation by doing the following: - turn off Sun MQ at all (neither local/remote/embedded config) and remove the IMQ dir? - remove all JBI stuff (disabling the JBI lifecycle module und removing the references to it doesn't seem to work as I get a startup exception and the admin app doesn't work anymore get rid of all references to JavaDB/derby by removing the javadb dir and all config references like timer jdbc pool. The rationale is to prepare a standard setup for a corporate environment where people should be restricted to use plain JavaEE(no JBI) and use the corp standard products for jms providers and databases"

hepler has some suggestions in
Re: Project Looking Glass, whats next....
Just wondering if the Sun Secure Global Desktop might provide a solution to this request to run Windows based programs in Looking Glass. It should be able to display any application in an X based environement. Maybe the people working on the Secure Global Desktop would be willing to do the interface to Looking Glass? Maybe the server and client would run on the same system. Maybe you guys could get together with them but not take on more than a few days of work in order to orient them to the project. This could result in the ability to display any program in Looking Glass that the Secure Global Desktop can handle (IBM Mainframe, HPUX, ...).

swpalmer seems to be hitting an undocumented barrier in
Desktop.mail(URI) what are the limits?
"I've found that with Java 6 on Windows XP ( running Outlook email client) that the body size included in the URI provided to Desktop.mail(URI) can cause the API call to fail with a"Error: Access denied") Is there any way to tell what the limit is at runtime? (Other than re-trying with different length URIs until you cross the boundary.) I noticed this first when I was making a simple bug reporter that emailed stack traces and found that the method would fail depending on exception being reported."

Marco Sambin is dealing with applet-only memory issues in
[JAI] JAI, memory usage and Java applets:
"I am experiencing some stange memory problems with my JAI and JIIO - based Java applet. This applet is able to load, display and process sets of medical images. Within a single execution of my Java applet, everything's working really fine: I am able to load very large sets of images (thanks to JAI's pull model), even multiple times in the single execution without problems. The problems begin when I exit from the applet without closing the web browser (for instance, I browse to another web page), then I return back to the applet and load another set of images. If I do this 4 or 5 times, then upon loading a given set of images I get an "out of memory" exception."

Meanwhile, pepe reports a curious case of
inconsistent cpu use:
"I am testing multiple platforms for support of the application i am currently working on. I get very inconsistent results from one to an other. For example: on a P-IV D 2.8Ghz (dual core, cores enabled), geforce7300 GS, CPU is around 18% at 50hz. on a p-IV 3Ghz (hyperthreaded, HT enabled), intel 82945G (!!!), cpu is around 0-4%.. Both machines have latest drivers, both run flawlessly and cycletime is set at 20 on both. This is very troubling."

Among the recent Weblogs, Alexey