Friday August 11, 2006
Validating Data Validation
Filed under: javase7
The rites of passage of a JSR are at times exhilarating and terrifying. Scary expert group rebellions, unending debates about API naming. The excitement of dozens of expert group applicants, the thrill of release of a public draft.
But did you know that the most important moments of a JSR are the three occasions it has to come before the venerable JCP Executive Committee for a vote ? Once at the start, once in the middle, and once at the end. This elected body, on which I serve (with, surprisingly, some of the nicest people), takes a vote to make sure a new JSR is not treading on the toes of anyone else's JSR, and that an existing JSR is doing what it said it would do. Many pass unscathed through these hoops of fire, some singe a little hair along the way. And occasionally EC members have even been known to forget to vote. But many a spec lead's heart skips a beat or three at the gruesome prospect of joining the charred remains of others less fortunate.
A fascinating new idea recently survived round one of this triplicate torture. One of those good ideas, one wonders, in the long lifetime of Java, that no-one had thought of making a standard API of before: a general purpose framework for Data Validation. One measure if its usefulness is the number of other technologies that could make good use of it. So when I asked around to find out who from within Sun would like to sign up for the expert group, expecting to have to twist a few arms and call in some embarrassing favors that I couldn't possibly talk about even with you, I was surprised that I had to beat them off with a stick.
From web applications
that need to check validity of the return date of your flight, to the persistence
layer double checking someone's age before it serves up a
byte-stream containing something unmentionable, to desktop
application verifying the format of the telephone number you
entered. Not forgetting the IDE that automagically attaches these
checks into any reasonably
formed component, this JSR offers the possibility of specifying and
enforcing these data validation checks easily, and hopefully in an
easily reuable way.This JSR I think will build on some great experience, and it looks like it will have a lively expert group. Good luck with the next rite of passage, Jason.
Posted by dannycoward ( Aug 11 2006, 12:33:36 PM PDT ) Permalink
Friday May 26, 2006
Simplifying a Swing Application for Dolphin
Filed under: javase7
You heard about the two new Swing JSRs, each of which aim to make developing Swing applications easier, right ?
The Beans
Binding JSR promises to simplify that large chunk of your Swing
application concerned with hooking up a GUI component to the data it
represents. This code is always concerned with keeping the data and the
GUI in sync ("do I really have that
little money in my checking account ?"), and usually its doing
type conversion ("uh, my paycheck is
in dollars, not pennies thankyou very much") and validation ("Error, you have entered an amount
exceeding your current balance. Please rethink your plan to chuck it
all in and sail round the world") as well. Scott's
blog has much more on this new work.Hans' Swing Application Framework JSR is aiming to provide standard API support for some of those chunks of code that keep popping their heads up in most all Swing applications, you know, the part that manages user preferences, or that remembers application specific state across sessions, or that preps things like databases on startup and cleans such things up on exit.
Ease of development has been a big deal for Java EE. In case you had your head in the sand, Java EE 5 is done, blossoming with a newly revamped programming model which focuses on ease of development. (Check out the before and afters from JavaOne - slides). There are of course as many opinions on ease of development as there are working styles. And working style can be a fraught area for us developers. We have on occasion been known to lose our cool in discussions thereof, particularly when personal styles become a public matter. When engaged (or occasionally enraged) in the activity of developing an application or system, our process is often very interior, solitary and introverted. While what we produce at the end can be a thing of functional or even aesthetic beauty, comparatively little of the process by which we got there remains. Were we sculptors, the floors of our studios would be waist deep with scrapings, chippings and discarded previous efforts. Were we musicians, we might laugh up our sleeves at us developers who think that 'doing our thing' in pairs is an extreme measure, or puzzle at the idea of an orchestra of soloists.
My only point being that ease of development is often an electric issue. However it appears that the main activities of development: learning, prototyping, designing, developing, enhancing and maintaining, benefit a majority of developers when they are kept brief and simple. That happens best when technology takes on some of the load, respectful of our attachment to style, for us.
I have high hopes these new JSRs will take some of the load of developing Swing applications for Java SE 7 'Dolphin', making the applications themselves shorter and simpler. And in a style that I hope will work for most everyone, not least because Scott and Hans will be joined in these efforts by some really expert luminaries of the Swing community.
That should ease development.
Friday May 19, 2006
Mastering Mustang, Developing Dolphin
Filed under: javaone javase6 javase7
Here are the slides for the presentation Mark and I gave on the upcoming and future release of the Java SE platform here:
Mastering Mustang, Developing Dolphin (PDF, 2.4mb)
Enjoy !
So as the last orange backpack leaves Moscone, we see the end of another JavaOne. Something odd happens each JavaOne, despite all the best efforts of the presenters and attendees to control the messaging, what ends up being memorable takes on a life of its own as the week progresses. For me, the two stars of the show were both technical (yay), and were
- the Ugly-Duckling-to-Swan story of Java EE 5 (which Bill
describes here)
- the activities bringing scripting languages onto Java SE (which I
have talked
about before)
Friday April 14, 2006
Java SE Language: Eadem Mutata Resurgo*
Filed under: javase7
Part of the reason working in the Java SE group is so interesting is the diversity of the developers using the technology. As developers, we're writing a wide variety of applications in a wide variety of different domains. Java SE may only be a part of the software stack we're depending upon. Often we're working with Java SE within a Java servlet, or EJB container. Java language changes are of special interest to us in the Java SE group, because wherever we are as a developer in the software stack, additional features we add to the language make a different to us all.
Curling the Chip
There was a story in The Economist a few years ago about innovation. I hate to paraphrase such a good article, but that grain of golden sand appears to have crept to the deep. One of the points was to contrast product innovation for new products and for established products. A wholly new product has no customer base. No commitments or expectations. The successful innovations tend to be big new ideas, or a disruptive application of an old idea in a totally new setting. Like the Sony Walkman was. Innovation for established products is arguably more difficult: you have customers who already like your product who you want to keep. There are teams of people building, delivering and selling your product that would be difficult or expensive to change. So your ability to innovate is much more constrained. But the article gave the example of a company making potato chips that were popular, but not popular enough. Rather than invent some wholly new potato based snack, they put a curl at the end of each chip. There was minimal disruption to their production processes. Customers didn't notice anything new till they opened the bag. There are two happy endings depending on your perspective. One happy ending is that people loved them because they could shovel more dip onto them. The other is that people loved serving them because there was less spillage of dip after the party was over. Either way, sales jumped dramatically.
Java SE Language Changes
So to some extent, with a successful technology like Java SE, good things to look for on the horizon are the metaphorical curls in the chip. Non-disruptive innovations that have widespread consequences. Given that many Java developers are Java EE developers, its no wonder that the use of annotations has been such a big hit. As Graham's been explaining, that curl in the chip has scooped up a big wobbling dollop of complexity out of the EE deployment descriptors and programming model.
Here's a selection some of the possibilities I've been thinking about. Doubtless you recognize some of them.
Property support
This would be a language syntax to support short handing the variable foo, getFoo(), setFoo() pattern. Definitely a pattern that is routine and dull to keep replicating by hand.
Method References
Writing and wiring event listeners is a frankly a bore. For example, implementing and wiring a button to call the updateLastName() method on your AddressBook object when clicked gets old if you have to do that kind of thing a lot.Wouldn't you prefer something like button.addDelegate(delegate updateLastName) and get it over with ?
Block Closures
A block closure is a group of statements defined within the context of...another group of statements. So block closures are statements within a statement ! (A Dream within a Dream. My entry found its theme.). Inner classes are the poor man's version of this: they are hobbled because the only thing they can do with local variables is read those that are final (why is that ?). Plus some people think they are plain ugly. Block closures could be an enormously powerful way make code very compact. But is there a syntax that pairs brevity with readability ?
Partial Classes
Unlike the esoteric predecessor, this is just the ability to deposit the source code for a class in various different places, like separate files. The most familiar usages are by tools that auto-generate parts of a class for you, perhaps a GUI builder tool, leaving you to fill the rest out in fear of the warning comments bespattered around the source file. With a partial classes mechanism, the machine generated part could live safely in one file, and the bit you work on in another. Simple and tidy.
Finally
So I wonder which of these, or the many other potential language changes could be the next curl in the chip for Java SE 7 'Dolphin' ? And in particular, which could be used by the Java EE platform with powerful consequences ? And keep to our principles ?
* So what's with the title this time ? Of course, Eadem Mutata Resurgo means "I shall arise the same, though changed" which is relevant to the topic. Plus my brother read my blog and gave me some typically fraternal feedback ('excruciating' was one word he used :-) ). So the title is also his college motto. You've got to throw the non-engineers a bone now and again.
Posted by dannycoward ( Apr 14 2006, 12:21:21 PM PDT ) Permalink Comments [5]
Thursday April 06, 2006
Modularity on the Java SE horizon
Filed under: javase7
I have confined myself thus far to talking about things in Java SE that are within hands reach. I thought it was time, especially with JavaOne coming up, to take a peek further ahead, see what's on the horizon for Java SE beyond Mustang.
For a technology that has found the range of venues for deployment that Java technology has, it still amazes me that under these competing demands, Java the language and Java the platforms have remained so consistent. But in places, the signs of age and stress are showing. In order that Java can continue to be many things to many people, its natural to look to ways to flex under the stress, rather than snap. And with an industry depending on the technology, in an evolutionary, not revolutionary way: Modularity.
So where are the stress points, and what can we make out on the horizon ?
1. Packaging and Deployment Modularity
The JAR format was first introduced in JDK 1.1 as a way to package application classes needed by an applet. Now its used as a general purpose format for deployment, packaging, caching, execution and distribution. On view on the horizon is the Java Module System JSR. Its vision is that instead of a tangle of JAR files (some needing a diet) of unknown versions secreted in various places, strung together in hope by a complicated classpath checked only at runtime, organization will be brought to application packaging and deployment in the form of a neat repository of medium sized code archives quietly expressing detailed and fully resolved dependencies on one another. Easy to manipulate, easy to distribute.
Easier to bring some much needed help 10% of PC users ?.
2. Language Modularity
Of course, as I mentioned last time, this is about supporting your other favorite language rather than turning Java into something it isn't. OK favorite within reason: dynamic ones. Maybe if your favorite language is c we'll need to talk. As I'd mentioned, quite close to hand is the Scripting for the Java Platform JSR makes a start by providing a basic facility for layering an interpreter on top of the JVM, enabling applications to mix Java and other languages.
But the compilers for dynamic languages are difficult to write well. Why is that ? Well, its a bit like doing your taxes without either an accountant or TurboTax.
Its about form filling: The main problem for writing a dynamic language compiler that creates Java bytecode that behaves optimally at runtime is that the Java VM depends on finding the method parameter and return types of a method call in the class file of the object making the call. The whole point of dynamic languages is that you don't know the types at the time you make the class file i.e. compilation. So todays dynamic language compilers usually employ complicated schemes of generating interfaces on the fly to represent unknown types, just to provide the form filling required to make a class file. It makes them slow, and when the developer changes code and recompiles, those magical interfaces need to checked and/or generated.
So on the horizon, the newly approved Supporting Dynamically Typed Languages on the JavaTM Platform JSR aims to remove that beaurocratic barrier to to dynamic language support by adding a new slot in the bytecode format. A slot not used by the Java language ! (not yet...)
Relief for the dynamic language folks ?
3. Application Code Modularity
Java already has various tools for decomposing and organising program code. At the small scale, classes to organise related functions and operations. OK so far. At the team, larger program scale, packages. But packages are a little stressed out too.
Let's say you want to publish a data model you wrote representing players in a tennis league. So you make the relevant classes and methods public. No harm in anyone picking up the code to do that. Like the developers of your tennis club's website. As the code evolves, you find yourself adding some interesting data exporting methods to help you interface to a database. Great, better make all that public for your database developers. Now your web developers and your database developers have exactly the same view to your code. Oh dear. The web developers are confused by the database related methods and some are using them by mistake. Better move that to a different package. But didn't you want it in the same package because its all related ? And, sigh, now you have to turn some of the package-internal classes public so the classes in the new package can still use them. Now the crazy web developers are using those classes, and they are asking what the new package is for. Double sigh !
Replace tennis club with insurance brokerage and a few thousand lines of code with a few hundred thousand and you probably already got the point.
Gilad amongst others has been toying with a few ideas here which I hope will come into range soon. Think 'friendly' packages, think 'organized' packages.
So, some interesting things on the horizon. Come to JavaOne, or stay tuned here - if I squint I can see a few more things out there...
