Keith Bennett's Profile

While it is true that Swing event handling must all be done on that thread, it is not necessary for creation or starting of the initial Swing component needs to happen on that thread. Swing programs routinely have their first setVisible called on the main thread. I don't know if I'll be able to insert a link here, but here is an example on Oracle's site that launches the GUI by calling setVisible on the main thread: http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/uiswing/examples/components/BorderDemoProject/src/components/BorderDemo.java

Make sure that:

• you're running it in JRuby (sorry but it happens ;) )

• you've called require 'java'

• you've called java_import 'com.dockyard.PgArrayParser'

• you've compiled the class using javac

• the .class file, or a jar file that contains it, is in your classpath at runtime

• if the class is in a class file, rather than in a .jar file, then it will need to be in a com/dockyard subdirectory of a directory in your classpath.

-- Keith

Ryan -

Nice presentation, and thanks for getting the word out about JRuby. I think it offers a lot of possibilities to supplement MRI Ruby.

Regarding using JRuby to write Swing apps, if anyone's interested in seeing a small but nontrivial JRuby Swing app, check out my Game of Life Viewer at [https://github.com/keithrbennett/life_game_viewer], blog article at [http://www.bbs-software.com/blog/2012/09/05/conways-game-of-life-viewer/].

Also, in many cases you can eliminate JRuby's JVM startup times by using Nailgun (blog article at [http://www.bbs-software.com/blog/2012/09/15/hello-nailgun-goodbye-jvm-startup-delays/).

And, for more information to supplement this JRuby screencast, you can check out [http://www.bbs-software.com/blog/2012/09/04/jruby-presentation-northern-virginia-ruby-user-group/].

I worked with Java Swing for several years, several years ago, and have some comments and suggestions for those who want to take it further than the basic example you provided:

In my experience it's better practice not to call setVisible(true) when the frame is instantiated (that is, inside the class definition), but instead make it visible after it has been created. There may be other initializations you want to perform between the creation of the frame and the displaying of it, especially if it's happening at startup time.

An alternate way of instantiating a JButton is to pass it an instance of an Action class. This offers a cleaner separation between the visual button object and the business logic it executes. In addition, a single Action instance can be shared by multiple UI components. This comes in handy when you want the action to be triggerable by both a button and a menu item, for example. The UI components set themselves up as a listener to the action so that changing the enabled state of the action enables or disables all UI objects that use it.

It's a little cleaner to use Ruby-like property setter notation in the class, but make sure to preface the property with self. or else Ruby (any Ruby, not just JRuby) will consider it a local variable initialization. For example:

self.visible = true

# instead of:

# visible = true

# or:

# setVisible(true)

Normally it's necessary to call pack() on a JFrame after you've added all the components to it so that the frame will lay out its components properly. I guess it's not necessary with a single button.

You mention that in Java you would normally use an anonymous function for the behavior of an action listener, but I think you meant an anonymous class.

Using the JOptionPane show methods by themselves in a script without running a full fledged Swing program is a really great idea that never occurred to me. Thanks!

Cheers,
Keith