Skip to main content

Fragments of Memories

Posted by editor on May 25, 2006 at 9:32 AM PDT


Desktop guys need persistence too

Joshua Marinacci makes a pretty strong statement in today's feature article:

However, the sad fact of client software today is that as every application gets bigger, it eventually needs a database. From the largest billing system to something as simple as an address book, almost every application needs a database

Thing is, he's probably right. Productivity apps, loosely defined as those where your data is more valuable than what (if any) the application provides, are often well-served by having a database to sort, search, and organize your data. A database is critical to for wrangling thouands (or tens of thousands) of songs in an MP3 player, and when I look at how iChat has saved all my instant-messaging sessions in separate files -- 3,800 of them now -- it occurs to me that this app would be well served by a database to organize all those old conversations.

Thing is, most desktop developers don't get a lot of face-time with an SQL command-line and many aren't enthusiastic about working with databases. Says Josh:

I've been a professional software engineer for close to ten years now and I don't know anything about databases. Sure, I can write a simple SELECT call, but if you ask me to do an double outer join with foreign keys or convert my schema to 18th normal form, I'll simply get lost and give up. I don't know databases. In fact, I hate databases. I'm a client guy. To me, a database is simply a box to store stuff. I don't know how they work and I don't want to know.

So, how do we get client-side developers hooked up with database persistence without pulling them away from their pretty GUI's and making them look at database diagrams?

In today's Feature Article, Josh suggests using the new Java EE persistence API. In
An Introduction to Java Persistence for Client-Side Developers he shows how a lightweight combination of Hibernate, HSQLDB, and the JPA can make saving address book entries a snap.


A post-JavaOne reality check tops today's Weblogs.
In State of Java ME development, John O'Conner writes:
"Having just returned from JavaOne, I'm excited about the talk about Java ME development. There's just one problem...my cell phone service provider and device manufacturer are completely clueless, unable to help me."

In
Gosling Goes Real-Time, Janice J. Heiss writes:
"At the JavaOne Conference Friday morning keynote, 5/19/06, James Gosling talked with Sun Distinguished Engineer Greg Bollella about Real-Time Specification for Java (RTSJ)."

Finally, Kirill Grouchnikov grumbles about
This little HTML renderer in my head:
"If there is one implied skill in Java development positions, it's the ability to read HTML tags and see the layout..."


In Also in
Java Today
,
Michael Feathers says It's Time To Deprecate Final: "Here's the problem: When you use final pervasively, you make unit testing nearly impossible. Believe me, I know. I encounter enough teams who are in that situation. Have a class A which uses a class B that is final? Well, you'd better like B when you are testing A because it's coming along for the ride... The problem with final (and a couple other language mechanisms like it) is that it is too coarse a tool for what it does. It prevents everyone from subclassing or overriding. What we really need is selective access, or maybe just convention."

"'Real Time" doesn't mean "real fast'." In Peter Mikhalenko's Real-Time
Java: An Introduction
, the author takes a close look at the Real Time
Specification for Java (JSR 1) and a recent implementation from Sun.
"Real-time Java offers a much more reliable and predictable scheduling
mechanism, memory handling methods, different memory models, a more
predictable threading and synchronization model, asynchronous event
handling, and high-resolution time handling. It makes predictable
execution the first priority in all trade-off decisions, sometimes at the
expense of typical general-purpose computing performance measures. This is
what real-time means."


In Projects and
Communities
,
Scott Violet writes about the approval of JSR 295: Beans Binding in his blog Ease of Swing Development - Beans Binding. "Beans Binding aims to make it easy to bind two properties of two objects together. Taking the slider example, you might be able to bind the two together with the following code: bind(slider, "value", selectedObject, "foo");"

The goal of the Sun Grid Developer Community's Neurona project is "to create a prototype of an AI system which can work as a sole entity formed by neurons or 'brain cells'." The approach will use distributed computing "in order to have several computers working independently, saving and restoring 'memories': text, images, sounds, video and any kind of information available."


In today's Forums,
Juan Gonz