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 beatthem 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 somegreatexperience,
and it looks like it will have a lively expert group. Good luck
with the next rite of passage, Jason.
You heard about the two new Swing JSRs, each of which aim to make
developing Swing applications easier, right ?
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 expertluminaries of the Swing
That should ease development.
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
I also sensed people having more fun both at the conference and in
their approach to the technology this year than in past years. Ya, that
for me was the highlight.
Part of the reason working in the Java SE group is so interesting is
the diversity of the developers using the technology. As developers,
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,
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
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.
been explaining, that curl in the chip has scooped up a big
of complexity out of the EE deployment descriptors and programming
Here's a selection some of the possibilities I've been thinking about.
Doubtless you recognize some of them.
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.
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 ?
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
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 ?
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.
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
\* 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
('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
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.
Of course, as I mentioned
last time, this is about supporting your other favorite language rather
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.
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
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...