Evan Summers's Blog

Gooey Goals

So i gave this talk, discussing the following stuff:

• JSR 296
• JSR 295
• Swing - "the State of the Nation" according to um, Me!
• The Problem with Strings
• Gooey (my upcoming thingymajig in the near future)
• Meme (my upcoming thingy in the far distance)
• Technical writing
• Opensource

JSRs 295 and 296

I gave an overview of what and where JSR 295 and 296 are, with special emphasis that both have public java.net sites with active mailing lists, where all the excitement is happening, and open to everyone to join the fun, which is "A Very Good Thing" :)

"It's the way of the future, It's the way of the future, It's the way of the future..." (Howard Hughes' character in the Aviator, loosing it.) I used to say that incessantly to my niece to irritate her. Then i left somewhere for three weeks, and returned, lapsing immediately into "It's the way of the future, It's the way of the future..." as soon as she entered my vicinity. Heh heh. No, i hadn't been mumbling it for three weeks! ;)

I suggested that JSR 296 was well scoped to address basic good practice of Swing development, namely Lifecycle, Resource Injection, Actions/Tasks, and Session State.

I suggested that i wasn't sure about JSR 295's scope, because on the one hand it is designed to be "beans binding for everything" ie. to bind one property to another property generically, and on the other hand it is implemented specifically as "beans binding for Swing components." I think it might be layered as such, eg. basic property-to-property beans binding (and groups of bindings), and building a Swing layer on top of that, or next to that, which might reuse/extend some basic interfaces, but otherwise is very specific eg. to JTable et al. I've lost track a little bit there, with all the frenetic activity :)

Swing

I suggested that Swing is onwards and upwards at the moment :)

• Netbeans is shaping up very nicely, eg. with Matisse, and next up, JSRs 296 and 295 support in Netbeans 6.0.
• WebStart is a potentially fantastic technology, and hopefully it's shortcomings (eg. scalability, i'm told) will be ironed out, so that it can deliver on its awesome potential.
• Swing potentially fits in very well with the JEE juggernaut, eg. using WebStart, webservices and/or JPA et al.
• Consumer JRE, perhaps prompted by JavaFX, will benefit Java/Swing too, and other languages on the platform, eg. Groovy/Swing et al.

Strings

I was banging on as usual about the problem with string references eg. for properties for binding, JPA queries (in strings), component names for resources, et al - they're not toolable as in refactoring, auto-completion...

I suggested that software naturally degrades, and without refactoring, a broken window left unrepaired will lead to a horribly run-down building before very long.

Test coverage is meant to address this ie. to make refactoring feasible. But what about maximum assistance from the IDE, eg. auto-completion et al, when it comes to referencing properties, resources, XML elements, in JPA queries, et al!?

In an ideal world, the language together with the tools will enable totally safe refactoring on one hand, as well as maximum productivity on the other, ie. prompting, auto-completion, and error highlighting. And of course we always want compile-time errors rather than runtime ones eg. caused by unresolved string references.

Gooey

After a year so in development, i'm getting to stage where i want to whip this dodgy framework of mine into some kinda state, to release on gooey.dev.java.net. My goals are to address my requirements as follows ;)

• A "container for worksheets," ie. a frame with a menu bar, tool bar, status bar, and main tabbed pane, with lifecycle support eg. for launching worksheets as new tabs. (See Framewarez altho out-of-date - Gooey Frame due in coming months.)
• Simplistic beans binding, as in a "presentation model" approach for forms, and tables. (See Gooey Bean Info et al.)
• MVC architecture, where Netbeans is used for the View, ie. designing pretty forms, but our controller is the main event, and has no generated uneditable code. (See Gooey Beans Form.)
• For forms, we use bound "input component adapters" to enable the controller to control components in the View, eg. setEnabled() and what-not, ie. via delegation. These are bound to the Model beans on the one side, and the Swing components on other ie. in the View. (See Gooey Beans Form, and upcoming Gooey Table Model in August.)
• Support for basic automated layout eg. of beans-bound forms, for rapid prototyping, while fully expecting to switch over to Netbeans' designer at a moment's notice when things get real. (See Gooey Beans Form, and Group Layout Therapy.)

Meme

This will be an experimental ORM using meta entity objects, and entity property objects to reference "tables and columns" for queries, ie. so that entities are refactorable, without fear of breaking queries. (See the Dog House article.)

Technical Writing

I do technical writing as a design exercise. When you write about code, you notice areas for improvement. It's like a self review mechanism, innit. Aiii.

Also writing reinforces my "Simplicity through Multiplicity" principle. The more classes, and the more methods, the better. If it's easier to explain, then it's probably easier to read and understand too.

Opensource

I discussed the difference between the GPL and Apache licenses, and suggested that people license frameworks and such-like under Apache, so that companies can reuse their code, without having to track what they're changing - which potentially makes it impractical to assimilate your framework into their code-base. "If you love something, set it free." ;) It's counter-intuitive that it's best to surrender control, but invariably that turns out to be best option, in hindsight.

Comments

• That's a great sum-up of the good and bad on the horizon for java. So can I paraphrase you?! :)No-one knows what the deal about JavaFX is, but the Consumer JRE will be great, EL for properties sucks, Matisse is pretty cool and Swing usability is improving with these tools and those JSR's and WebStart needs to be an INSTALLER that makes deployment easy.
  Keith
  

  Posted by: commanderkeith on July 27, 2007 at 12:37 AM

This work is licensed under a Creative Commons License.