Joe Nuxoll's Weblog
Tuesday November 22, 2005
Java Properties and Events Graham Hamilton recently posted an entry on his blog requesting suggestions for future Java language innovations. I work with Graham, and have had the opportunity to talk with him about a wide range of Java subjects. One place where we haven't seen exactly eye-to-eye is the area of language-level properties and events. I personally believe this is the #1 missing ease-of-development feature in the Java language (and platform, for that matter).
Adding properties and events to the Java language itself does more than eliminate common boiler-plate code, as is often used as the primary pro argument. The more important benefit of adding these concepts to the language itself is that it promotes the notion of "component library" instead of "class library" when designing new APIs and systems. Component-based development is what makes learning and developing with some "other" software platforms so much easier. The Java language is still very focused on the notion of "class library", which was long ago supplanted by "component libraries" in other platforms.
JavaBeans has been around for a long time. It was the *original* move toward component-based software for the Java platform. The notion of components promotes a plug-and-play method of software development where the common interfaces between components and an application are well defined. This makes it very easy for visual tools to aide in application design and building. It also makes it very easy for new concepts to be introduced to the end developer. A developer is handed a set of JavaBeans which they can study and poke-around with until they learn the new concepts implemented by the suite of JavaBeans. The only problem is... JavaBeans is just a conventional pattern, and not built into the language itself, and therefore completely ignored in most APIs. New technologies and APIs rarely use JavaBeans patterns, and the JavaBeans patterns themselves have gaping holes where tool vendors have had to fill in the gaps.
If these component-oriented concepts were in the language itself, they would be used across the board for new technologies. Any new API (or JSR, etc) would provide a set of components for a developer to use, as opposed to defining a set APIs to implement or leverage. Things would just be easier - both for tool vendors - and for end developers.
I have compiled my thoughts into a document that outlines how this might be accomplished. Please comment!
( Nov 22 2005, 08:18:30 PM PST ) Permalink Comments [4]3-D glasses anyone? Anyone?
Okay, so I'm a big fan of the TV show "Medium". I watch it every Monday night at 10pm, or soon after via TiVo. Last night was a big deal because the show contained a bunch of 3-D stuff, and you had to have a set of 3-D glasses (one eye red, one eye blue) to see the effects. The latest TV Guide magazine contained a set of 3-D glasses for the big event, so everyone apparently rushed out and bought up all the TV Guide magazines. All of them. I went out last night around 9:30pm to get my lady and myself a pair so we could settle back and watch the keen effects that we looked forward to all weekend.
No such luck! All gone. Everywhere! Each store I went to immediately responded when I said "Hey, do you guys have any TV Gui..."
"We're all sold out of TV Guides, sorry! No more 3-D glasses! You're the 10th guy to stop by asking."
It was bizarre. I figured I was one of the very few that actually watched the show, but last night was a very powerful reminder of the scale of network television and advertising. Apparently the whole neighborhood was out looking for glasses, and those that were'nt already got theirs days earlier. I actually tried SIX different places with no luck.
Sigh. I guess I have to order some 3-D glasses from a catalog and keep them in a drawer in waiting for the next blockbuster TV moment. Luckily I have TiVo, so I'll get to watch the show afterall - but not until I find a pair of those darn popcorn goggles.
( Nov 22 2005, 01:32:21 PM PST ) Permalink Comments [6]
