Eclipse Irritations: .classpath and Phantom Ctrl-Shift-T

At work, the de
IDE is Eclipse. It
seemed like a good idea to check in the .classpath file
— where Eclipse stores all the JAR dependency information for your
project — and there haven’t been that many problems.

Checking in .classpath Stinks

However, when .classpath problems do happen, things
blows up big time. My advice is don’t check that bugger in:
the path system in it isn’t general enough to be group-usable, and CVS
conflicts are just annoying to deal with when they happen.

Loosing Ctrl-Shift-T

Needless to say, I had some .classpath problems today,
and in the process of “fixing” it, I must have re-jiggered some
internal source indexing in Eclipse. As a consequence of whatever I did, I
lost the ability to use the “Open Type” functionality over my own code
base: you know, that nifty little “open up the source for this class”
dialog that you get when you do Ctrl-Shift-T. Sure, all the classes
from my JARs were in there, but none of my project’s high quality code!

To fix it, I closed the project, and then re-opened the
project. Then, when I did Ctrl-Shift-T once again, Eclipse seemed to
be building back up it’s index, and everything was hunky-dorey.


In closing, yes, I know: if I used only emacs or vi or Notepad or
JEdit or NetBeans or whatever your super-dope IDE is I wouldn’t have
any problems. I’d also have fresh butter churned up for me every 30
minutes. I just don’t have the need for that much butter.

JBoss-Sun Drama

The JBoss Group, the Atlanta, Ga.-based company that controls the development of the open source JBoss J2EE server, has been embroiled in a year-long dispute over the certification of JBoss. Sun would like JBoss to be certified as J2EE compliant, but the JBoss Group says that Sun’s certification process is expensive and ultimately unimportant to their customers.

“Do our customers say, ‘We need you to be certified’? No,” said JBoss Group Director of Sales and Business Development Ben Sabrin. His company is still in discussions with Sun about J2EE certification, he added.

I was mentioning the whole JBoss-Sun stink-up yesterday at lunch,
this is a concise article
on all the drama.

Liscov, Note for Later:

What is wanted here is something like the following substitution property: If
for each object o1 of type S there is an object o2 of type T such that for all
programs P defined in terms of T, the behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T.

Also, froman article by Robert C. Martin:

It is only when derived types are
completely substitutable for their base types that functions which use those base types can
be reused with impunity, and the derived types can be changed with impunity.

Re: Intranet Weblogs

Consider: Every business needs to know what its employees know. Companies are crammed with experts on various topics whose knowledge goes to waste — because nobody knows what they know. Now give these workers an internal corporate blog, and encourage them to use it. Let them natter away on every topic that intrigues them. Harvest and index the results. You’ve mapped your workers’ brains.

. . .

”We’re not saying, `We’re going to give this to you, now go off and talk about whatever you want to talk about,’ ” Regan said. He tells his bloggers to focus on computer and networking topics, so they can share information about the problems and solutions they’ve found throughout the state’s computer systems. ”So far we’re pretty happy,” Regan said.

As this article will be erases from the ‘net after a few days, I archived a copy on

Code Reviewing

Dave Thomas has an interesting code reviewing exercise as his most recent Kata. At work, we do review before check in — all code is reviewed before checking it into the repository. I still haven’t figured out if this is ultimately better or worse than allowing developers to freely check in code, but it tends to force you, as a coder, to perform Thomas’s Kata each time you check in code…or, just find a lax reviewer, but never mind that.

Back in Austin

I got back late last night: the leg between Pheonix and Austin was kind of bumpy. Nonetheless I finished off the first part of the JMX book I’ve been reading. It’s a good book, and an exciting technology.

My plan to cancel my $130/mo. cable and cable modem bill looks like it’s going to work out too: I just got the SBC Yahoo! DSL modem all setup and rigged up to the router: old silverpants is scootin’ all over the internet via the Airport EXTREME! card now; I don’t see why even boring-ass networking equipment has to be EXTREME! now-a-days.

Airport Hijinks

At the security gates of the SF airport, there was a guy who walked through the metal detector with his hands up and a grin on his face. He wasn’t told to, of course: he was just making a little joke that was actually kind of funny. I mean, they had us take our shoes off and put ’em through the xray machine. It’s just getting fucking retarded.

There was another guy, who flew all the way to Austin, who had a big sticker on his luggage, which he checked, that said “NOT YOUR BAG” I guess someone had mixed up their bag with his one to many times.

JavaOne: Generics in Tiger (J2SE 1.5)

Adding Generics to the Java Programming Language (TS-3063)
, Gilad

Everyone likes generics, as the packed hall can attested. I know
Kinman’s waiting for them. I didn’t “grow up” in the C++ world, so I
probably don’t have as great a longing for them (templates, in C++
talk) as some, but more compile type checking is always good.

Bracha’s got to be the smoothest Java guy there is. Gosling may
be The Java Guy, but Bracha must be the suave Java Guy. He’s
svelte, wears a well cut, double breasted suit, and he has a smooth,
laid back delivery style.

It should be noted that Bracha really only talked about using code
that has generic methods and field: he didn’t really address designing
APIs with generics. That’s a hairy topic touched on lightly below,
then more when I type up some other notes I have.

What are Generics?

Most people probably have a good idea,
but we’ll sum it up real quick anyhow. Simplistically, generics transform this, non-generic’ed code,

List someList = new LinkedList();
someList.add(new Integer(5));
Integer myInt = (Integer)someList.iterator().next();

into this, generic’ed code,

List<Integer> someList = new LinkedList<Integer>();

someList.add(new Integer(5));
Integer myInt = someList.iterator().next();

The points of difference are bolded.

Also note, that another Tiger feature, autoboxing would remove the need
for the new Integer(5) wrapper; you could just pass in 5. More on that in another post.

I’m not really going to spend anymore time on syntax as it’s pretty
straight forward, and not 100% finalized yet. There’s additional
syntax, but that’s the meat of it. As usual, the commentary is as
interesting as the actual technology, e.g.,

An inordinate amount of conversation occurred about square brackets
versus angled brackets. Square brackets didn’t parse for some reason,
so here we are.

Typing to Catch Errors

While the amount of typing required
isn’t really reduced (you have to type the stuff instead
of casting), the main benefit is compile time type checking; that is,
you can have the compiler help you avoid runtime

ClassCastExceptions in many cases.

Bracha made a little joke on this point,

This allows compilers to catch errors earlier. Some say you don’t
need this: if you’re using Java to fly an airplane, just bring your

Catching errors early on, i.e., when compiling, is one of the best
arguments for strong type checking (see Guido’s remarks at
about Python’s loose type checking and unit tests for another
view). Astute readers will, of course, note that it’s also one of the
most hampering things to deal with in more run-time dynamic settings,
like most of J2EE, e.g., JMX.

More Meaningful Code

Also, there’s fact that the code
becomes more readable, and, in a sort of metaphysical sense (or is it
ontological? I always forget the distinction), more meaningful. A
non-generic’ed List is really a holder for

Objects: you may happen to put Integers into
it, but it’s “meaning” is to hold Objects. A generic’ed
List<Integer>‘s “meaning” is to hold integers;
there’s no confusion or ambiguity.

As Bracha put it, a generic’ed Collection is “telling
you something about the variable at the declaration point. That’s 90%
of generics right there.”


There was a lot of time spent going over how
migration concerns drove the requirements for generics. The problem in
a nut is that once you enable generics, you want your legacy code to
retain the same meaning as it had before; you can’t screw up legacy
code. Apparently, the “Global Software Tax Convention in Redmund,” as
Bracha called It, was ignoring this problem.

Desires for Migration Effects/Tasks

  • no duplication of code needed – must ship J2SE 1.4 and 1.5 libs.
  • no release coordination needed – you have to wait for a lib you
    depend on to go generic before you go generic.
  • migrate when you want – not forced to migrate your lib to
    generics at any given time because you upgrade to 1.5.

Essentially, we need backwards compatibility. To get this, we allow
the following type of code…though, it produces a compiler

public String loophole(Integer int) {
  List ys = new LinkedList();
  List xs = ys; // we loose the generic typing here
  xs.add(int); // warning, type is ambiguous
  return (String)xs.iterator().next(); // run time exception

As always, “don’t do that.” Bracha said that out of the million-odd of
lines of code in the JDK, there were only a couple of migration
problem spots: something having to do with
"".compareTo(Object), but I didn’t quite catch/understand
what he was saying.


There’s early
access code available now
; though, from the Bloch and Grafter’s
Thursday night BoF, many of the implementation details are still being
ironed out. For the more production code minded among us, it’ll be in
Tiger, J2SE 1.5, which is supposed to be released in about a year.

Designing APIs with Generics

I’m going to have to spend
some serious time mulling over the generics information I got from the
Grafter an Bloch BoF
; there are some major conceptual
hurdles to get over when it comes to coding generics properly in
APIs. Bloch said the nut of it is,

An Integer is a Number, but a

List of Integers is not a List
of Numbers.

I believe the two relevant terms are “variance” and

In the mean time, there’s a good article on
on using Generics. Sadly, it doesn’t cover API design
with generics. More on that later.

JavaOne: Thursday Language Fest

Eric left me a voice mail saying, “today’s sessions were the best so far,” and I’d have to agree. It’s probably because most of the sessions were about the language itself — Generics, J2SE 1.5 features (which I didn’t go to), writing better performing code, and the evening BoFs about Metadata and how Tiger features will affect some of the code in the JDK.

The two BoFs with Joshua Bloch — along with Grahm Hamilton and Neal Gafter, in the first and second, respectively — tonight really delivered. At the bottom of my notes for the first session I wrote “Wow,” and I stayed for a good hour or two after the second listening to Bloch and Gafter talk to the circles of folks around who stayed after. They basically gave an indepth discusion and Q&A on Generics, Metadata, enums, and varargs…all things that making coding in Java easier, but which are all difficult to code up. Changing the language is always a hot topic, as people start to get hissy; and, to a degree, as Sun and the JSR process seems to cherry pick from already successful 3rd party apps. But, “students copy, but the best artists steal,” etc., etc..

I’ll be flying back to Austin tomorrow in the mid-afternoon, and checkout is at noon, so I don’t if I’ll be going to any of the sessions. Most of them don’t look to hot anyways — some web service stuff, some marketing type stuff, and some really small niche stuff — and there’s only 2 or 3 hours worth anyhow.

I’m hoping to spend the time digesting and typing up notes instead. I’ve got over half of a 50 page notebook scribbled up, so there’s plenty to play around with. We’ll see how naive my ambitions are.

JavaOne: Quick Thursday Notes

The technical sessions are over for today, so it’s that odd time between them and the BoFs. There’s a couple BoFs here at the Mascone I want to be sure to get into tonight — Metadata for Java (as was demo’ed in the keynote, this is something like XDoclets on steroids) and How Tiger [J2SE 1.5] Language Changes Affect Your Favorite APIs. Both have Joshua Bloch involved, so it should be worth it just for that.

The problem, then, is what to do about dinner…

Eclipse T-Shirt

I decided I should go check out the competition, so I went over to the HP booth and listened in on an a booth guy talking to a Sun person about OpenView; later I got him to show me a little demo, though, they were only showing the Java related stuff. It was pretty snazzy, actually. While I was waiting there, an HP person came by and handed me a black Eclipse t-shirt. It’s pretty nice, esp. as it doesn’t have a bunch of weird marketing stuff on it: just the Eclipse logo and the list of Eclipse members on the back. I don’t really wear t-shirts, but it’s always good to have more dorky t-shirts.

As Kim once said, long ago after looking through my laundry, “Hmmm…most people have old high school or college sports shirts…but you have programming shirts…you’re such a dork!”

Tech Sessions


I went to Adding Generics to the Java Programming Language first. Gilad Bracha is a suave presenter: he’s got that vague European accent and that well-cut suit thing going along with subtle sarcasm spontaneously laced throughout his presenting. Most of the info given is probably available on-line, e.g., the syntax, but it was fun to hear Bracha’s commentary as he presented Generics, e.g.,

If I’d have known how long this’d take [to get into production Java], I’d never have got into it.

I have my notes about halfway typed up; hopefully tonight I’ll be able to polish them off.


With my new like of JXTA, I thought I’d check out another facet of it:
JXTA for Small Devices Using the J2ME
. Eh…it was interesting, but not worth talking too much about. The main point was that there’s an incredibly small (which is good) and easy to use J2ME API for JXTA. However, the “trick” is that you need a proxy running on a real machine to do all the “heavy lifting” (another phrase people like using around here).

I’m interested in the idea of using JXTA to link up embedded and other small devices, but as I’m not an eeky type of hardware guy, playing around in that sphere could start to get expensive. I do wonder, though, if J2ME could be used to create small footprint apps running on desktops: putting that together with JXTA could start to get interesting. But until the small device market can do more than take pictures of toilets in Hong Kong, I’d rather stick with desktops.


I really liked JMX: Recent Changes and Ongoing Applications. There’s mucho notes to type up. As Eamonn McManus, the speaker said, most JMX books out there are about JMX 1.0, so his overview of the new features in JMX 1.2 was interesting. As with the Generics presentation, his commentary on design decisions and constraints in the API was interesting too.

The best feature — from a coding perspective — in JMX 1.2 was the use of Proxys to get rid of the need to do crappy shit like,

mBean.invoke(mBeanServer,"methodName",new String[]{arg1,arg2},...);

That is, coding reflective invoking manually. With the use of Proxys, you can just do something more like,


You still have to get a hold on the MBeanServer, but it makes calling operations much cleaner to code and easier to read.

Still, there wasn’t a good, concrete example of using JMX. I’ve been thinking of stopping by the Quest both to see if they have something; maybe Mercury — I could kill two birds with one stone, check out the competition and all.

This session was packed: I think JMX is one of the big interests in JavaOne this year, but there’s only 2 or 3 sessions about it. I bet developers are going to be wanting lots of JMX in the upcoming year: it has a good sales pitch; we’ll have to see how well it delivers.

Brazillian National Health Card System

It seemed like a boring topic, and I only went into it to make sure I could get into the OS X session after it, in the same room, but this session was quite enlightening.

The pilot project covering 44 cities in 11 states of the federation with a population of almost 13 million inhabitants and about 2,200 health care providers, most of them primary care units are presented emphasizing the actual implementation status.

That’s damn impressive.

Java on OS X

I thought I’d treat myself to something non-work applicable, so I went to
Doing Serious Java Development on Mac OS X
. It was mostly just a laundry list of development tools the speaker had tried out. He had a list of all them in the PowerPoints which will be online sometime somewhere, so I won’t bother to list them.

There wasn’t anything about actual programming, just tools and IDEs. Kind of disappointing on that account, but I guess if I’d have read the description I’d have found out: going off the titles of these things isn’t the best way to select ’em.

Well, it’s 7:27 PST here, the BoFs begin at 8:30…I better round up some grub before my mind starts to go nutty.

Yeti the Dog Miscellany

I’m sure all of you are thinking, “JavaOne, yeah, yeah, but what about that damn fine lookin’ dog of yours?”

Well, thanks to the wonders of e-mail (have you heard of it?), I have these updates from the lovely Kim Skotak:

  • Yeti likes peanut butter. He likes apple slices. He likes peanut butter on apple slices!
  • Yeti is getting to like The Crate better. Kim went out tonight, so it was crate time. When she came back, he was asleep in the crate. We’ll see how receptive he is to getting into it next time. The crate’s good as he’s a 4 month old puppy who’d probably rip a bunch of stuff when we’re gone. We’ve also been lead to believe that dogs kind of like crates: it’s their own personal space.
  • Kim and Yeti went to the Crown and Anchor and he was quite sociable and nice. He made friends with a Golden Retriever. Apparently, he’s quite the babe magnet. Tom has already made plans to “baby sit” him sometime. A fellow large dog owner — who said his Mastiff loves those orange constructions cones — said, “seeing [yeti] is the best thing that’s happened all day.” People like the dog.
  • The vet says he looks OK. He’s probably loosing some teeth, which makes eat his kibble painful.

JavaOne: Other Bloggers

JavaOne: JXTA

Project JXTA: Open P2P Architecture Platform (TS-2915)
, Tuesday

As I said earlier, JXTA has been
the most interesting thing so far. The Tuesday session was presented by
Bernard Traversat; I believe he’s the JXTA bigwig at Sun.

As a pronunciation note, everyone seems to say “Jux-tah,” not

What is JXTA?

In short, JXTA is a framework and standard
for creating virtual peer to peer networks. Put another way, it’s an
abstract network layer to drape over other, physical networks to
enable networkable devices to talk to each other and manage their own
network interactions.

Sounds pie in the sky, right? Well, here’s a concrete example from
one of today’s (Wednesday) sessions, Building
Robust Distributed Applications with JXTA

Soft Teams of Sensors

BBN, the TS-1297
speakers (see below for more on that session), work with/for the US DoD. The DoD wants to reduce the human
involvement in “soft teams,” and use a bunch of robots instead. “Soft
Teams,” now are largely special ops folks, like SEALs, that go behind
enemy lines, setup a bunch of monitoring equipment, and then stay
there for days maintaining the sensor network, filtering the data (?),
and sending it back.

Loosely quoting the speakers, “the DoD wants to just drop in a
bunch of sensors, let them sort out networking with each other,
gathering information, and nominate one of them [or several] to send
the data back to the satellite.”

So, in this example, you have bunch of networkable devices that
need to talk to each other – in the most simplistic example, comparing
notes about what they’re sensing to double check each other – and we
certainly don’t have a physical network pre-installed and ready to
plug into.

You have the need, then, for an ad hoc peer to peer network:
you need the devices to discover each other, share
information, establish their own network, and provide fail-over
handling should any peer go down.

These are essentially the requirements that JXTA satisfies. It
doesn’t provide the implementation of the network (the underlying
layers do that), but it provides the structure of the network and
services the peers use for access to the network.

The astute among you, dear readers, will immediately recognize this
as the Sun pattern for design: don’t create the implementation,
create the design and framework to layer on top of the
implementation. From what I’ve seen, though, this is a choice one.

Comparison to Traditional Networks

The traditional
(current) network is basically hubs/routers and clients (compared to
the first generation, client-server): clients talk to each other, but
all their traffic goes through routers. At home, if I want to print from my
laptop I have to send the print job through my
router, which sends it to the printer. If the network was peer to
peer, the laptop would just talk directly to the printer.

The hubs-clients network, as the internet has proven, is actually
very good for many uses like web browsing, email, simple desktop apps, etc.
The problem, however, is that you must have your
network planned out a priori (some old philosophy speak that
several speakers like using which, in this context, basically just means “before hand”).

Using the example above, if I just put my laptop, my printer, and a
router in a room together, they still won’t be able to talk to each
other: they need me (or some really smart software) to tell each of
them how to talk to each other (usually over Ethernet/WiFi and
TCP/IP). Each device also needs to be told about each other.

JXTA networks don’t need this additional setup: devices
discover and figure out how to talk to each other. Of course, on a
deep code level, you’re really just auto-magic’ing all the
things you were doing in the hubs-client model. As Mark Pilgrim says, “a lot of
effort went into making this effortless.”

Enough with all that explanation. All of you probably know what a
p2p network is anyway.

Back to JXTA

First, JXTA is free and open source. As
Traversat said several times and emphasized over and over, Sun
realized that anything that’s going to be an infrastructure technology
(networking) must be free and open to be successful.

JXTA, like many things now-a-days, has an XML protocol; which is to
say that unlike, for example, SNMP which BER encodes data (making the
data unreadable to humans until it’s decoded), the
data is in “plain text.” Though, as many of you know, XML protocols
are often unreadable themselves.

Key JXTA Abstractions

  • Peers – the networkable devices.
  • Virtual Networks – the network, which doesn’t have to be
    “physical,” that the peers form through JXTA. One important point
    about the virtual network is that peers are given logical

    addressed, not physical. addresses. I take this to mean that a
    peer can move from device to device. Through this, peers could
    something along the lines of the anthropomorphic idea of viruses and
    : a piece of software/application that moves from machine to

  • Advertisements – XML descriptors of the peers and what services
    they provide. I assume that these “adverts,” as one of the BBN people
    said, can also serve as generic envelopes for any
    type of meta-data. Every ad is assigned a lifetime, and there’s some
    grounds keeping handling for dead ads.
  • Decentralized Resource Discovery – there are several types of
    peers (see below); those that help route traffic are called Rendezvous
    peers. These “RDV”‘s facilitates looking up other peers; that is, they
    act as “ad servers,” do caching, and even provide indexes. RDV’s help
    keep track of “where” edge peers are, and what they provide. Even
    better, if the RDV doesn’t know what you want, it helps you find
    other RDV’s.
  • Ad Hoc Peer Groups – peers can be grouped together to
    create logical sets. Peer groups are used to established different
    policies (about routing, searching, access, etc.). If I recall and
    understood right, the policies are represented by ads.
  • Pipes – “very similar – in concept – to UNIX pipes.” A JXTA pipe
    is just a generic conduit for peers to exchange data. If I
    understood right, a pipe will follow a peer through it’s logical
    address. That is, if peer A is talking to a peer through a pipe, and
    peer A switches to a different machine, the pipe will follow the peer
    to it’s new physical location.

Tyes of Peers

  • Edge Peer – the classic client that produces and consumes data.
  • Relay Peer – virtual routers; “landmarks,” that is, other peers use Relay Peers as known points in the network, e.g., “If you want to talk to me, talke to the landmark Relay Peer X.”
  • Rendevous Peers – ad servers, caching, and indexing. This is different than Relay Peers in that actual network topology and information is stored in these peers…I think.

Those are essentially the main points. Despite my disjointed
writeup, it’s actually quite simple. JXTA doesn’t seem like much at
first, but it opens up new ways for apps to use networks and interact
with other apps over the networks (like BBN’s self organizing and
co-operating “soft team” of sensors above).

JXTA 2.1

As a final note, JXTA 2.1 was released not too long ago. It’s
“primarily a bug release,” but there’s some new “metering and monitoring”
features as well.

Building Robust Distributed Applications with Project JXTA (TS-1297)
, Wednesday

This was presented by some folks from BBN who’d been doing research and implementations for the DoD, the Coast Guard, Homeland Security, and a “Western regional airport.” Their main interest was using sensors to do security and detection, which makes their “clients” interest obvious. Their jobs sounded real fun, despite the chill of Big Brotherism that could sneak up on you.

For those not working on perimeter security, it’s important to think of “sensors” more broadly: anything that collects data and (to be useful) provides collected data to clients can be thought of as a “sensor.”

The core nugget of this session is summarized above with the “soft team of sensors” example. Here’s some interesting notes and quotes:

  • Dana Moore recommended and “The Rise of the Stupid Networks”, which was cool to hear at such a big conference. I thought they were just obscure, late night surfing reading. He recommenced them, I’m guessing, because they help you get an idea of the type of “world” that peer to peer networking could enable and the business rules that exist in it, e.g., “All the nets value grows on it’s edges.” They’re good essays: read ’em!
  • Along the lines of the stupid networks, Moore said, “transport is guided by the needs of the data, not the network’s assumptions.”
  • JXTA is quite interoperable: there’s C implementations, Perl, Python, Java, etc. The protocol is in XML, so interoperability is possible, vs., for example, RMI.
  • Traditional sensor either send too much dumb data, burying the info you’re interested in, or send too little data. Moore gave an example of too much dumb data: net admins looking at system output on 10 vt100’s trying to detect a network intrusion.
  • “Hypotheses” – it took me awhile to figure out the exact meaning of this old term in the JXTA context. The sensors/peers in the network have hypothi that roll up to global hypotheses. A “hypothesis” is something that a sensor thinks is true (according to the input it’s getting), e.g., “a vehicle just drove past me.” Each sensor/peer creates tons of these hypothesis, and tells it’s peers about them. Then, at a higher level, you programmatically compare all the hypothesis, and verify which ones are true; presumably, you run some business rules like, “70% of the sensors must have the same hypothesis for it to be ‘true.'” This was an interesting concept for verifying multi-source data about one event.

p2p Inseption and Elaboration Design Considerations

Lastly, here are some architectural considerations to sort out when doing p2p network/app design:

  • Deployment constraints – e.g., physical terrain, like mountains and expected up time, drive requirements for hardware and power. In a more applicable setting, the type of network you’re deploying into might drive the policies and practices you establish: can your peers roam around the network as they please? Is the network reliable and stable? Does data need to be real-time? Etc.
  • Anticipated operation sequences – though JXTA can enable a lot of synergistic interactions and lifecycles for your apps/peers, it’s still good to plan for chains of events that will commonly happen and what you’ll need to put into your peers, or even the way the peers interact to enable those “operation sequences.” For example, I’d think, if you were going to have a bunch of DB access, you might assign some peers the role of DB accessors, and you might make a policy that RDVs always know where a DB accessor peer is so that looking them up is fast. In the OO sense, this is the behavior of your network.
  • Info processing paths – synchronous or asynchronous? That is, how will the information flow through your network? In the same way that anticipated operation sequences can drive the design, the how/where/what of the data can drive design. As always, from a high level, data and behavior are not so different.
  • “Scalability, Scalability, Scalability.”


  • – main JXTA site.
  • SPIDAR – the BBN JXTA application.
  • COUGAAR – recommended, and used, by the BBN guys.

As with an earlier
, here’s a fun quote to end with:

“Is there going to be a way to do all that Web application descriptor
crap [in RAVE]?”
“‘Web application descriptor crap’…I love that phrase.”
–Q&A at TS-3730

Mac vs. PC Style HTML

I have this theory that the design of your HTML is largely driven by the platform you code your HTML in. Now that I have a Mac, I’ll see if my style subtly changes over time. My pages definitely render differently on my PowerBook than my PC’s.

JavaOne: Wednesday Quick Notes, Cont.

I couldn’t get into Measuring J2EE Application Performance in Production, it was packed. I guess that’s a hot topic. Instead I popped into
Performance Monitoring for the Java HotSpot Virtual Machine, which was basicly an overvierw of using and interpreting data from several tools available from Sun. As performance monitoring and management is essentially the raison d’etre of BMC, I figure I should goto as many of these as I can.

I also went to
Building Robust Distributed Applications with Project JXTA
and The Commons Inside the Firewall: Lessons Learned from Large Enterprise Development, which were both quite good.

The Cifreo’s and I are probably going to goto to dinner somewhere. I might skip the BoF’s tonight, though there is an interesting looking one of JMX and then a Joshua Bloch one on collections.

JavaOne: Wednesday Quick Notes

I’m inbetween sessions, so I thought I’d post a couple remarks. I had to skip the last half of a JXTA session to eat the sandwhich I got earlier. As Kim would say, I’m Starvin’ Marvin. I still have pages and pages of notes to type up, but I’ll just pull out some interesting info.

. . .

I just chatted with a guy who sat down at my table about the G4 laptop — there’s no way to do page down without holding down the Fn key, damn! — so I have no time now: I gotta dash to the “Monitoring the Performance of J2EE apps” thingy.

What I wanted to say is this: JXTA is by far the coolest and most applicable to my job thing I’ve learned about. It’s fucking awesome, I never realized p2p stuff could be so cool and have so many uses beyond MP3 stuff. It’s definitly something I’ll have to spend lots of time fiddling with…

Oh, I just overheard a commander cell phone type yell something about PATROL, that’s kind of nifty.

Well, more later, dear readers.

More JavaOne Bloggers

JavaOne: Tuesday Technical Sessions and BoFs

Well…the first day of technical sessions is over. I think my
brain has melted to a little black nugget with the influx of
information that went through it…abstract…enterprise…abstract…API…

The first day has been good: the content of the presentations is interesting, and each presentation has a theme of
“we’re here to make the developer’s life easier” running through them
that’s refreshing after having dealt with Java for so long. (See
Bruce Eckel comments on why he likes Python in part one of that Artima

Here’s a writeup of my notes and my own scriblings on the first session I went to. It’s about 1:05AM here in SF, so I think I’ll skip typin’ up the other 3 sessions and the two BoFs I went to until tomorrow, or later…

Introduction to Java BluePrints

I’m always nuts for 3 things when it comes to programming: frameworks,
methodologies, and best practices. Admittedly, my first choice for this
time slot was the JSF (JavaServer Faces) Intro, but it was
marshal packed
; but, “TS-2473” proved interesting (actually, I
did see the last 20 minutes of the JSF one, see below for more).

Local vs. Distributed.

In the J2EE world, one of the first architectural requirements you
have to iron out is if your code will need to be distributed, or if it
can all be done locally. By “locally,” of course, we mean that your
app will run on one box, in the same memory, and probably all in the
same VM.

If it’s all local, you don’t need to worry about
networking up your app, or really anything that might fall under the
category of J2EE. The advantages, of course, are that you don’t need
to spend time designing and implementing distributed stuff into your
app. This means you can (usually) have a more simplistic

An interesting corollary (?) to this is that it tends to promote the writing of non-reusable code. That is,
because you’re not “forced” to layer your application or spend lots of
time designing how all the components would communicate with each
other over the network (the presumption being that for distributed
apps you need all this), you can get lazy and not do enough design to
help enable re-use.

The main draw back of distributed systems, then, is that it
increased the complexity of your app from initial development, to
deployment, to maintenance: there’s more moving parts, so it gets more
complex. Presumably, from the re-use comment about localization, it
promotes more re-use.

At this point, the speaker gave the “highlight piece of
advice” (all the conferences tend to have one piece of advice that,
when they give it, is prefixed by “if you remember only one thing from
this presentation, remember this…”): when in doubt about doing local
or distributed, go for the simpler design.

This is Ockham’s Razor and all that, but it’s recently been
re-expressed best by the XP folks, “do the simplest thing that could possibly work,” the last part being the most important.

Advice on the Web Tier.

Use MVC (JSF, Struts). Use JSTL. If you don’t need overly complex DB
wrapper — EJBs — use RowSets. Again, “when in doubt, go
for the simpler design.”

There was an overview of MVC, with the most interesting thing being
the phrase “user gestures” to describe user input.

More on RowSets.

“in memory representation of
the DB.” Not part of J2EE 1.3, but available.


“It’s really tempting to use command line
tools…but an IDE really helps you a lot.” I liked that he used

Web Services Blueprint.

The blueprint is, in a way, very
similar to MVC:

   |    |
  |     |

The client uses SOAP (that’s really what everyone means when they
say “web service” around here) to do something, like get a customer’s
information. The Interaction layer is part of “your system,” and it
handles all the SOAP requests, delegating to the Processing
layer. That is, the Interaction layer translates the SOAP stuff into
the Processing layer, and translates the response into SOAP for the
client. The Processing layer is just your business logic: Java code.

The goal, of course, in classic Sun abstractionism, is to make the
layer that does the crunching not have to know anything about the
client that’s requesting the crunching. This makes everything
flexible, agnostic, and not susceptible to changes in other
layers, blah, blah, etc., and so forth…

“Keep the processing layer independent of the interaction

More importantly, as we’ve long learned in GUI and then
web app development, you want to get your business logic as far away
as possible from your presentation logic. At least, you want to try to
keep it as far away as possiblem, to re-purpose the XP saying.


I saw the last 15 minutes of this one, basically the Q&A. I believe
Craig McClanahan answered all the questions.

Struts and JSF.

“JSF will replace where Struts is now, but
not where it will be.” Which, of course, is interesting, because it means there’ll be more Struts development, but what?

“…likely to look at templating in JSTL 1.2 time frame.”

He says that one of the big problems with Struts is that there’s
just “one big configuration file.”

Should we use JSF, or Struts?

If you’re going to be deploying
(deadline) in less than 6 months, just use Struts. If it’s greater
than 6 months, consider JSF. More importantly, the license you
download JSF with/under is for evaluation purposes only.

I also went to
Servlets 2.4 and JSP 2.0

Project JXTA: Open P2P Architecture Platform

Optimizing Web Services Performance

Real-Time Information Integration with J2EE and XML


J2EE-Based Projects That Fail: What Can We Learn from Them?
…but I’m too tired to write all that up, much less make it coherent.

JavaOne: Tuesday General Technical Session

I just walked out on the first technical session to get me some
wireless access upstairs in the “game area.” There’s a bunch of old
video games setup here, and some bean bag chairs and, finally, a
wireless network that doesn’t require a password.

The first part of the technical session was an overview of “Tiger,”
Java 1.5 and J2EE 1.5 developments and plans, presented by Graham
Hamilton. Here are my slightly edited notes.

  • Trashes on COM being complex, requiring IDE that generates lots
    of spaghetti code. This is the first of many mentions of Microsoft
    (though, he only ever says “VisualBasic”) developer mentions.
  • Meta Data. Tools understanding JavaBeans and other
    non -compiler enforced coding conventions. This is, basically, like xdoclet, except done by
    the compiler, and done inline instead of in JavaDocs.

    So, for example, if you wanted to use a tagging interface (like
    Seralizable), instead of having your class implement an empty
    interface, you’d do something like:

    public @fred int x;

    He called these “annotations” and described what they do as
    decorating the code. If anyone is allowed to interpret these
    “annotations,” a whole new type of coding and tools could spring

    Later on, we find out that this Meta Data stuff is going to be
    used to do many J2EE deployment descriptors inline, instead of
    requiring them to be maintained in a separate XML file.

  • Generics. Instead of having to worry about casting from
    collections, 1.5 will have something like
    HashMap, which means “the key is
    String, and other is Mamels.” Generics get a huge round of

  • Better Iterating. Instead of having to use those damn
    Iterator and, in older code, Enumeration,
    1.5 finally picks up on one of the best control structures from the
    scripting world:

    for ( String object : collectionInstance) { ... }

    That is, the block of code iterates over all the members in
    collectionInstance, and sets object to the
    current member. I forget if he said, but I think the generics and
    autoboxing (see below) will take care of casting.

  • Enums. There’ll be compiler support for doing enums, for example,

    public enum Coins { heads, tails }

    Would create an enum with two possible values. Nowadays, you have
    to use homegrown stuff, or something like (my favorite “hammer”),
    the Commans lang Enum.

  • Autoboxing. You have “big primitives” (aka wrappers) and “little
    primitives” from big primitives to little primatives, e.g.,
    Integer and int. As languages like Perl and
    Python demonstrate, having to "manually" convert between the two is
    just stupid. 1.5 fixes this. Thus, you could have:

    Integer bigInt = new Integer 5;
    int lilInt = 5;
    int value;
    value = bigInt;
    if (value == lilInt)
      System.out.println("Now it's a little easier to code.");
  • C-style sprintf. 1.5 will sprintf (or
    is it just “printf“? This is all built into
    java.text. There wasn’t comment on i18n, but I
    assume/hope you can pass in Locales.

  • Scripting. Hamilton says “scripting languages are our friends.”
    JSR-223. They’ll be using PHP as the reference implementation
    language, and setting it up in Tomcat.

That’s it for now. I’m going to an intro session of JSF at
2:15. Hopefully it won’t be too hookey, or focus on VisualBasic

Here’s a quote from the conference to end with:

“You don’t have to be sarcastic, just wear it. If you don’t like it, you
can leave.”
–conference center security guy telling a Chinese attendee that he
must wear his badge at all times.


I arrived in San Fransico earlier this evening. The Cifreo’s and I had dinner down the street at an Italian place. It’s chilly here, but in a comfortable way. First thing tomorrow is the keynotes, but from what I’ve heard, the keynotes aren’t very good. And, anyhow, I’ll probably have to spend the morning tracking down my registration packet since it never arrived back in Austin.

Tonight I’m just trying to sort through all the vittles of the conference. There’s no good fotes yet, but I’ll upload them as they come.

Update: here’s the list of all the sessions and BoFs that looked interesting to me. I seriously doubt I can take in all 52, esp. as there’s several conflicts, but I might as well try.

Missing Weapons Of Mass Destruction:

There are two main possibilities. One that something is seriously wrong within the Bush White House’s national security operations. That seems difficult to believe. The other is that the President has deliberately misled the nation, and the world.

You, my dear readers, know that I usually avoid political
mucking on this weblog…but this missing weapons of mass destruction stuff is too easy.

Along with being being a reasonable article, there’s a good collection of quotes from Bush on the topic.


British Prime Minister Tony Blair is also under serious attack in England, which he dragged into the war unwillingly, based on the missing WMDs. In Britain, the missing WMDs are being treated as scandalous; so far, the reaction in the U.S. has been milder.

New York Times columnist, Paul Krugman, has taken Bush sharply to task, asserting that it is “long past time for this administration to be held accountable.” “The public was told that Saddam posed an imminent threat,” Krugman argued. “If that claim was fraudulent,” he continued, “the selling of the war is arguably the worst scandal in American political history – worse than Watergate, worse than Iran-contra.” But most media outlets have reserved judgment as the search for WMDs in Iraq continues.

Note that the reference to reports about Wolfowitz saying the war was all about oil was later found to be untrue.

Great Pyrenees

'Bumble,' the Great Pyrenees

If all goes as planned, the Coté and Kim house should have a new member by tomorrow. We haven’t decided on a name, but our short list so far includes “Tiny,” “Oso,” “Mouse,” and something along the lines of “Montana” or “Dakota.”

“Bumble,” as he’s called now, is 4 months and 3 weeks old…and he already weighs 50 lbs! When he grows up, he’ll be huge and furry, but sweet and gentle like most all large flock dogs.

There’ll finally be someone in the house hairier than me,

The Pyr sheds. A lot. Those who cannot abide the thought of tufts of white hair floating through the house twice a year should consider another breed. On the other hand, those who fancy exotic knit accessories may find the Pyr right up their alley. The dog’s fine undercoat can be collected when shed and spun into yarn used to make sweaters, scarves, afghans, and other items.

Python and the Programmer

They say you can hold seven plus or minus two pieces of information in your mind. I can’t remember how to open files in Java. I’ve written chapters on it. I’ve done it a bunch of times, but it’s too many steps. And when I actually analyze it, I realize these are just silly design decisions that they made. Even if they insisted on using the Decorator pattern in, they should have had a convenience constructor for opening files simply. Because we open files all the time, but nobody can remember how. It is too much information to hold in your mind.


Silver Smallpants

12.1" PowerBook G4

The G4 arrived safe and sound.
I got Firebird up and running, it comes native with emacs and Java. An OS that ships with emacs has my heart from the get-go.
Now I just need to dump Eclipse, Tomcat, JBoss, python, and
a few other dork tools on it and I’m ready for the year 3000.

It’s going to take me awhile to get
used to the Mac interface, esp. the track pad. And this font anti-aliasing is killing me.

If anyone has “tips,” shoot ’em my way. So far, I haven’t figured out how to:

  • Delete things with one click
  • Cycle through all my open applications (Alt-Tab in Windows)
  • Find a list of all applications I can run.
  • Turn off all this damn anti-aliasing.
  • Have it make toast and eggs for me.

What Exactly Are Obidos?

All of the servers at Amazon are given names of cities along the Amazon river. Obidos is a port city on the Amazon river in Brazil, and the name of the [] machine that runs the book database. Simple as that.

Fixing Venture Capital:

The fundamental reason is that VCs do not have goals that are aligned with the goals of the company founders. This creates a built-in source of stress in the relationship. Specifically, founders would prefer reasonable success with high probability, while VCs are looking for fantastic hit-it-out-of-the-ballpark success with low probability. A VC fund will invest in a lot of startups. They expect about seven of them to fail, two of them to trudge along, and one of them to be The Next Netscape (“TNN”). It’s OK if seven fail, because the terms of the deal will be structured so that TNN makes them enough money to make up for all the losers.

. . .

VCs try to speed things up by spending more money. They spend it on PR, and then you get problem 3 (“PR grows faster than code”). They spend it on employees, and then you get problem 4 (“too many cooks”) and problem 2 (“high burn rate”). They hire HR people, marketing people, business development people. They spend money on advertising. And the problem is, they spend all this money before anyone has had a chance to learn what the best way to spend money is. So the business development guy wanders around aimlessly and accomplishes zilch. You advertise in magazines that VCs read, not magazines that your customers read. And so on.