Evan Summers's Blog

July 2007 Archives

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.

Gooey Bean Proxy

We expose a "presentation model" bean using an interface, used to create a dynamic proxy, with a backing Map of property/values eg. for GUI prototyping, or otherwise a java.bean.

Code Snippet

We expose the properties of the presentation model using an interface as follows.

public interface PersonInfo extends GObservableBean {
    GProperty<String> username();
    GProperty<String> firstNames();
    GProperty<String> lastName();
    GProperty<String> displayName();
    GProperty<String> email();
    GProperty<Date> birthday();
    GProperty<Date> lastLogin();
    GProperty<BigDecimal> score();
    GProperty<PersonTitle> title();
    GProperty<PersonGender> gender();
    GProperty<PersonMaritalStatus> maritalStatus();
}

In this case, we can use "dynamic proxies" (from java.lang.reflect), to access our bean properties, rather than looking them up using string literal references eg. via BeanInfo. Our proxy object will use the Method name to look up the property.

Also, we have the option of not creating a backing bean for starters, which lends itself towards rapid prototyping, since the above property interface is clearly quite concise.

Half Baked Beans

public interface Property<V> {
  public void set(V value);
  public V get();   
}

where its implementation wraps a java.bean.PropertyDescriptor.

Now baked beans...

public interface BakedBeanInfo<B> {
  public Property getProperty(String propertyName);
}

where its implementation wraps a java.bean.BeanInfo, and constructs a collection of the bean's Property instances.

Now the trick is we expose our bean/properties as an interface...

public interface PersonInfo {
   Property<String> username();
   Property<String> displayName();
   Property<Integer> age();
   ...
}

where we use dynamic proxies to create a bean, and/or bean info, without worrying about the implementation (eg. QBeanInfo presented in Gooey Bean Info et al).

   PersonInfo personBean = GBeanFactory.createObservable(PersonInfo.class);
   ...
   GTableModel<PersonInfo> tableModel = new GTableModel(PersonInfo.class);
   GForm<PersonInfo> form = new GForm(PersonInfo.class);
   ...
      logger.info(tableModel.getSelected().displayName().get());
      form.set(tableModel.getSelected());      

where we bind to a backing bean instance (eg. Person.class) ie. a POJO/java.bean with accessors/mutators - or not eg. just use the proxy instance as our presentation model.

Lemme repeat... For prototyping, we might not worry about creating a Person.class, but just use the bean info interface to create our observable beans (via dynamic proxy), with built-in PropertyChangeSupport.

Our Property implementation might let us specify (default) presentation properties (eg. label, display width, format et al) of that property, and attach validators, as in Gooey Bean Form.

waddaya think?!

PS. The next installment on Gooey Beans is immiment at last, about JTable's, since i got the demo working, as in the following sneak preview, woohoo! :)

  (PirateWarez , 150k/500k, unsandboxed, Java6)

Notice how the selection works, eg. click on the search icon to select the pirate, and enter a blank booty barcode to select some booty! Later i'll look at a popup finder for entities, rather than switching tabs as it currently works.

Before all that, i'll implement and write an article on the above baked beans, to publish this month in Gooey Beans - and then publish the TableModel article in a coupla of weeks, before i set off on my travels to UK, Russia, Nepal, Ireland et al - Eet's nice... very very frikkin nice! Woohoo! Mmmmm.... Planet Earth...

My usual blah blah blah

In The future of Windows should be open source, the author suggests that "the desktop is becoming obsolete." This always gets my back up! (If you ever want to get a rise out of me, just say exactly that!) My comment was a regurgitation of what i always say on this subject, which is getting so frikkin boring, that i'm boring myself to tears, but since i wrote such a long comment, i thought i would cut and post it, and here it is again. I know, gutting.

iTunes is a desktop/internet app. Expect to see more such apps, ie. "internet apps" which are also "desktop apps" - that run outside the browser rather than within it. If you think it's possible to implement the rich Office experience using HTML/Ajax... you're stupid, no offense ;) What about an IDE as an ajax web app - ouch!

One can try to emulate desktop apps with web apps, but you'll never get a richer, more responsive user experience, with the same multitude of features - and of course OpenOffice, Kontact et al are improving all the time. And broadband means... click-and-run (and auto-update). Download times are a rapidly diminishing concern...

We have great opensource desktop software like OpenOffice, KDE, GNOME and all their apps - to suggest that we are just going to throw all that away and be left with a single app, the web-browser, as a single full-screen window, with all our apps running inside it, ie. supplant the likes of KDE and GNOME with just Firefox on X, is just silly.

And why even try to supplant great opensource apps with half-baked web apps full of ads?! Rather make the opensource apps like OpenOffice more "webby." Cos why can't apps run outside the browser? Why does everything have to run inside the browser - including Office, email et al - that's just silly!

The web browser (eg. Firefox) will never match the abilities of the OS/desktop (eg. Linux/KDE/GNOME) in terms of managing resources, processes, application windows, eg. tabbing, switching, minimising, exposing, etcetera, etcetera. Why try to turn a cute 5Mb browser into the 100Mb gorilla of a full-blown graphical desktop environment, when the likes of KDE and GNOME exist?

No one will ever again develop a graphical desktop environment, from scratch, that can catch up to KDE and GNOME, or would want to... MacOSX is NextStep legacy underneath, and Windows is also legacy proprietary rubbish underneath.

So to summarise, rather than desktop apps going away, desktop apps will become more leveraging of the internet and leveragable via the internet, eg. launch from the internet, persist settings et al to the internet eg. using REST, ie. be everything that is good about web apps. Desktops apps already auto-update from the internet which you might have noticed, so... onward and upward!

PS. With the advent of internet retailing, eg. amazon.com and the like, people started falling over themselves saying, "This is the future! Bricks-and-mortar retailers will surely all close down!?" Well they didn't. They took what was good about the internet, and added it to what they already had, which was good, and they got better all around. I'll warrant it's gonna be the same with the desktop. Life goes on much as before, just better.

PS. So I think the category "web apps" should make space to include both "browser apps" as well as "webby desktop apps" eg. Webstart Swing apps that use webservices, and not the local filesystem (except for caching and cookies, like a browser).

My checklist for the next year

Things to Streamline

I recently started writing a Swing feed reader (FeedTrove.dev.java.net) - which i was on my checklist, so that's ticked - but i have still more things to do there...

• Rather than using an HTML JTextPane, i want to try to render all the stories on a canvas, to get full control, anti-aliased font's, etcetera. Another option would be to use Flyingsaucer, but that is quite big, and quite a few jars which confused me when i wanted to give it a try. Anyway, it's a Swing app, so i guess i should be using Swing graphics rather than XHTML/CSS!?
• Ditto, for the console. I have an HTML JTextPane console in QuiteGooey - but i wanna try using Swing to render LogRecord's using beautiful fonts and colors and layout. I need this for other Swing apps too, eg. cute RIAs like a chat client...
• Add more components into the app, like a JTable (showing feeds), and form (with JTextFields et al, for settings and options) - just for the sake of rounding off the framework i'm spinning out of it (called Gooey.dev.java.net, which is an AppFramework-based minimalist rehash of QuiteGooey - which i am also currently refactoring and simplifying on it's own, so all quite confusing, innit?!)

More Swing

Besides a feed reader, i have a few other "small" swing apps i want to write (desperately!)

• A simple chat client, which may be the beginnings of a Swing-based social network RIA type application?! (Hey, I want to a billionare too! ;)
• A calendar/reminder "desklet" - a name i'd like to "coin" for Swing desktop apps that are launched from the internet ie. WebStart, and interact with an internet server using REST, rather than the local filesystem - ie. they are "stateless" on the client-side, in the sense that a web-browser is stateless app.
• A workflow/bug/issuetracking app, like the numerous web-based ones, but in Swing, using REST to backend servlets.

Wheels to Reinvent

Even though i know the future of web development is JEE/JSF/Seam, because it's standardised, i like interesting approaches like Wicket and Echo2, ie. using Java code (rather than XHTML et al) to build user interfaces ie. a hierachal composition of components. So i started a research project (divlet.dev.java.net) to experiment with that. Having done the basics, I still have two or three big issues to solve in my mind and implement in my svn, but no rush.

1. Composition of pages ie. templating.
2. Componentisation, eg. flexible, extensible InputText, DataTable components.

Things to Finish

The "Gooey Beans" series on aptframework.dev.java.net has temporarily stalled because of two many things on my plate! But i want finish that off in the next few months - with an article per month - including this month! So I got back into it this week, after a few months' neglect. Actually it'll never be finished, but i want to solve some "big" remaining issues for me...

1. data bean bound JTable's
2. Componentisation of lookup fields, eg. for entering/finding persistent entities, eg. using a combination of a JTextField, "search by..." dropdown, maybe high-volume auto-completing JComboBox and/or popup JTable et al for high-volume multi-column scanning, with JLabel to display the selected entity after all that, all as one "field" eg. PersonFinderField, to plop onto all your forms were a Person has to be specified, and use as a JTable cell editor, and similarly for every entity you have!

Also "outstanding" but much less of a priority for me is "Hyper Beans," where i want to address describing a printable/viewable document using java code (rather than XML), in order to produce HTML, Excel and/or PDF output - using iText and Apache POI. And after that, ODF. This is for business "documents and reports" eg. invoices and such, and also the results of database queries and such, innit.

In the "Jelly Beans" series, i got so many things i want to do, i won't even start! OK, i'll list some of them quickly....

• write about JPA (which i've eventually starting using in the past few weeks for a JEE/JSF/Seam web project)
• build a transactional REST server servlet backend framework for (my) Swing client applications
• implement a new experimental ORM, and using property "objects" rather than annotations, to enable native queries, ie. no strings attached, as in the previous blog entry
• implement an in-memory engine for the above, ala Prevayler

un-Java-ish Things to Do

• Visit friends and family in UK, Ireland, and Russia.
• Cycle from Dublin to Cork, via counties Wicklow (beautiful mountains), Carlow (visiting a friend), Laiose (my relatives). I might then cycle up the West Coast to Galway! I've done much of these routes on two earlier occassions, and want to do it again!
• Trek in the Annapurna in Nepal, and visit Tibet.
• Cycle from South of France, over the Pyrennes, taking the French Way of St James, a traditional pilgrimage across Northern Spain. (Very overdue!)

Now that my goals are set, i begin the task of trying to achieve them innit! But before i start, it's time for me to cycle around Cape Point, for the third time this week, it's nice! Which reminds me, my other blog is called "Getting Fit, Aiii".

Because, yes it's true, i'm not really a Java professional. Actually right now, I'm trying desperately to break into the fitness instructing field - much less deadlines and zero stress - and you get to exercise while you work!

The position i'm applying for (spinning instructor), requires you to "work" zero or otherwise 45 minutes a day, yeah baby, yeah! And you are encouraged to shout out things like "yeah baby yeah" at the top of your voice every minute or two, which is another perk! ;)

The other seven hours of the day... Actually I would like to be building a real Swing app for real people, using Netbeans 6.0, AppFramework (not aptframework), WebServices and/or JPA - so gimme a bell if you got simple requirements and plenty of bucks!

Trip and Tick: svnserve on linux et al

I spotted this handy blog entry and so decided to give it a go, on a brand new $15 linux VDS. Here are my notes, which are consequently a rehash of that blog.

useradd svn

Let's decide that svnserve will run as user svn, and access repositories off its home directory ie. /home/svn.

So we create the user svn with useradd, which creates its home directory /home/svn.

# useradd svn

svnadmin create

We create repository using svnadmin eg. /home/svn/aptframework.

# useradd svn
# su - svn
$ svnadmin create aptframework

If this host is aptframework.net, then this repository's URL will be svn://aptframework.net/aptframework.

vi svnserve.conf

In the svnserve.conf for our repository, we uncomment as follows.

$ vi /home/svn/aptframework/conf/svnserve.conf
anon-access = read
auth-access = write
password-db = passwd

We might want to have anon-access set to none eg. for private stuff.

In the specified passwd-db file, we add usernames and passwords for ourselves.

$ vi /home/svn/aptframework/conf/passwd
evanx = sshssh 

If we want to use a common password file for multiple repositories eg. /home/svn/passwd, then...

$ mv /home/svn/aptframework/conf/passwd /home/svn/passwd
$ vi /home/svn/aptframework/conf/svnserve.conf
password-db = /home/svn/passwd

where we specify the absolute path for password-db in svnserve.conf.

xinetd

We add an svn config for xinetd in subdirectory /etc/xinetd.d/ as follows

# vi /etc/xinetd.d/svn
service svn {
  port = 3690
  socket_type = stream
  protocol = tcp
  wait = no
  user = svn
  server = /usr/bin/svnserve
  server_args = -i -r /home/svn
}

where svnserve runs as user svn, and serves repositories off /home/svn.

We restart xinetd for the changes to take effect.

# /etc/init.d/xinetd restart

svn checkout

Now we can checkout a "working copy" of repository using svn://aptframework.net/aptframework URL.

Let's add and commit the standard (although optional) directories trunk, branches and tags.

# cd /tmp
# svn co svn://aptframework.net/aptframework aptframework --username evanx
# cd aptframework
# mkdir trunk
# mkdir branches
# mkdir tags
# svn add trunk
# svn add branches
# svn add tags
# svn commit -m "" --username evan

svn import

Finally we can import our source as follows, eg. from /projects/aptframework/src.

# cd /projects/aptframework
# svn import src svn://aptframework.net/aptframework/trunk/src -m "" --username evanx

Or for the whole shebang, eg. src, lib and what-have-you...

# cd /projects
# svn import aptframework svn://aptframework.net/aptframework/trunk -m "" --username evanx

We can do a test checkout to a tmp directory to make sure it looks ok, eg. we checkout just the src directory as follows.

# svn co svn://aptframework.net/aptframework/trunk/src /tmp/aptframework-src --username evanx

And again

When things don't go as planned, we just recreate the repository from scratch as follows.

# su - svn
$ rm -rf aptframework
$ svnadmin create aptframework
$ vi aptframework/conf/svnserve.conf
$ vi aptframework/conf/passwd

To re-import source, we'll need to search and destroy all those .svn hidden directories eg. in our src, innit.

Conclusion

Setting up and serving a subversion repository is quite trivial. We create an svn user, configure svnserve in xinetd, and use svnadmin to create repositories.

A Short Note About Properties And Politics

Another reason why we need properties in the language is ... for "native" database queries, eg.

Person warMonger = createQuery(new WhereLikePredicate(Person.name, "G.W. Bush"));

where Person.name is a property, ie. Person.class has an accessor getName().

In this case, our JPA queries are refactorable, yippee! If you have a real query, it's more obvious (no offense), eg.

      SelectQuery query = createSelectQuery();
      query.setTitle("Fido's in region %s", regionId);
      query.selectAll(dog);
      query.selectExclude(dog.address);
      query.select(organisation.organisationId, organisation.organisationName);
      query.join(dog, organisation, region);
      query.whereEquals(region.regionId, regionId); 
      query.whereStartsWithIgnoreCase(dog.dogName, "fido"); 
      query.whereIsNotNull(organisation.organisationName); 
      query.whereIs(organisation.active, true); 
      query.orderBy(organisation.organisationId, dog.dogName); 
      query.limit(100); 

as presented in the SQL Objects precursor to the Jelly Bean series.

Having JPA queries in strings (and any references in strings) is something that i hope people cannot tolerate going forward!? ;)

This work is licensed under a Creative Commons License.