But that's not good enough -- if you're going to be there you ought to count more.
The final decision maker in the JCP is the Executive Committee (EC), one for ME and one for SE and EE. Each EC has 16 members, and here they are.
You can see that the EC for J2EE has two actual individuals. J2ME has none. So as individuals you have (maybe you've already done the math) 2 of 32 members. While this is a nice, comforting pair of powers of two, it tells you where you are.
This is fundamentally broken. It is broken in two major ways:
In political terms, this is an oligarchy, a governing system where the final decisions are in the hands of an elite. This is further reinforced by the selection model. Sun gets one seat. Five seats are elected. The other ten are nominated by Sun and ratified (or, theoretically, not) by members. In other words, these ten are chosen by one-candidate elections.
Or to put it another way, if the individual members rose up in unison, we could elect, at most, five of sixteen members. For the rest we would have to vote down company after company, or person after person, until Sun nominated them someone we wanted.
Or, more simply, it's "You discuss, we decide."
As individuals we should join, but the JCP needs a more open system that allows all stakeholders, not primarily the largest, a part in the final decisions. More members should be elected. Equally important, it should be people on the EC, not companies. Yes, people should be elected to represent commercial interests. A person with good understanding of the telecommunications industry, say, could be elected, and while they might be employed by one company, they should be expected to represent a set of commercial interests that elect them, not just that one company.
The Jini Decision Process has many different requirements so is probably not simply transplantable. But it has a system that has individuals elected by both commercial and individual blocks. This gives it a structure that represents more stakeholders at the top.
Politically, the technical term for this is "representative democracy".
Or, as it is commonly known, "The worst form of government. Except all the others." It is time for a less worse form of governance in the JCP.]]>
I suppose for marketing reasons this might be a good thing to say because the market has ignored this. And Graham is right that extending the VM to support other kinds of languages is a very good thing to do. But let's not forget the actual state of the world.]]>
Every year they don't start this on time, and every year I show up on time anyway. Every year they do something interesting with the music. Sometimes more interesting than music, but this year definitely not. World fusion (isn't all music these days?).
I want to know their freakin' name.
I'm particularly bad at names, but I know I'm not the only one who needs the help. This is why conference badges traditionally have names on badges that are large enough to be read from a few feet away, sometimes even across a room, and occasionally are readable from low Earth orbit. This allows you to be reminded of someone's name when they greet you without peering in way that at best makes your memory failure obvious, or at worst will get you slapped.
This year's badges have print you can only read by grabbing the tag and pulling it up to your eyes, or by getting your nose closer to some folks than is actually healthful.
Whoever designed the badges needs to be forced to put their noses close to all the attendees until they get the point.
This is not a problem based on technical disagreements. It's a fundamental language design problem.
Any feature added to any system has to pass a basic test: If it adds complexity, is the benefit worth the cost? The more obscure or minor the benefit, the less complexity its worth. Sometimes this is referred to with the name “complexity budget”. A design should have a complexity budget to keep its overall complexity under control.
Generics are way out of whack. I have just finished (well, nearly) my work in the fourth edition of The Java Programming Language. I am glad to say that David Holmes, not I, was the one who covered generics. Just reviewing it and reading the specifications was enough to put my brain through a cuisinart stuck on “pulse”.
We went through that chapter multiple times, consulting with several people who wrote the specs and are otherwise experts. We were only able to cover the highest level in the book, and it's still pretty hard to understand (although David exceeded himself in making it as comprehensible as possible).
Learning to use generified types can get very complicated. It's hard to understand why you cannot do some things without casts, for example. But writing generified classes is rocket science. Here's one that showed up at the very last minute: It's a bad idea to declare a type that returns an array of a type parameter. That is, you shouldn't do this:
interface Holder<T> {
T[] toArray();
}
Why, you ask? Well, the problem is that T might itself be a generic type. That is, someone might declare a Holder<Set<String>>. And, ... uh, hold on, I'm trying to remember the issue here...
Actually, I'm only mildly embarrassed to say that I've forgotten. But I remember that it took a few back-and-forths between David and the advising expert so that David — remember, David is the guy who has been writing a chapter on generics after several months of experimentation and research and over a year of thinking about how to approach it — could understand the problem. So our book recommends against it because it isn't good.
Although there is an exception. It's okay to do this if the method takes as a parameter an array of T or a Class<T> object:
T[] toArray(Class);
That's OK to do.
Which brings up the problem that I always cite for C++: I call it the “Nth order exception to the exception rule.” It sounds like this: “You can do x, except in case y, unless y does z, in which case you can if ...”
Humans can't track this stuff. They are always loosing which exception to what other exception applies (or doesn't) in any given case.
Or, to show the same point in brief, consider this: Enum is actually a generic class defined as Enum<T extends Enum<T>>. You figure it out. We gave up trying to explain it. Our actual footnote on the subject says:
Enum is actually a generic class defined as Enum<T extends Enum<T>>. This circular definition is probably the most confounding generic type definition you are likely to encounter. We're assured by the type theorists that this is quite valid and significant, and that we should simply not think about it too much, for which we are grateful.
And we are grateful. But if we (meaning David) can't explain it so programmers can understand it, something is seriously wrong.
So now we know it's complex. But if it really saved your programming butt a lot it could be worth it. So what does it save you? It saves you making mistakes, like putting a String in a list that should only contain Longs, or attempting to pull out a String from such a list.
But we have a demonstration proof that we can live without it, namely that we have for nearly a decade. Of course there are such bugs in code, and if you generify a bunch of code you might even find one or two that were waiting to bite you (unless that code is actually orphaned). But I have yet to find someone who believes this to be a major source of error in their code, compared to other problems.
So we have a feature whose complexities are high, whose learning curve is steep, and whose benefit is limited. And add to that the feature is ubiquitous -- with Java 5 it is nearly possible to write code that doesn't interact with generics.
The complexity of Java has been turbocharged to what seems to me relatively small benefit. I don't see that the value is there to justify the cost. Not that we can change things, but I think we should at least view it as an demonstration proof of the value of an explicit complexity budget against which features must be justified. Without such a budget, it feels like the JSR process ran far ahead, without a step back to ask “Is this feature really necessary”. It seemed to just be understood that it was necessary.
It was understood wrong.]]>
By now it's much more staid. After all, Java isn't this amazing new thing, it's a well-established part of the programming field. Then, finding someone with six months Java experience was really amazing, and that was almost certainly "playing with it because it was interesting". Now it's just another language that pops up on resumes everywhere The price of success, of course, is that you are now established.
For those who enjoyed the whirlwind, though, you have to dig harder. There are still a lot of really cool things that are being done. Some are just cool because they're cool, no matter the language. Others are cool because Java makes them possible. There are still things that Java does that other languages just can't do, or can't do smoothly, mostly having to do with mobile code, security, and nearly complete platform transparency.
I'm going to be looking for those. Plus, of course, looking for folks I meet only here, once a year. Frankly they're more interesting than a lot of the sessions. While it's nice that someone is presenting the current draft of version 1.3 of the JSR 9,324 spec on adapting to .... [snore]. Hey, it's probably important to someone, and if it's right up my alley I'm there, but generally I'll find out about this stuff when I need to, and faster by using online docs.
But the arguments in the hall about Jini vs. JXTA are not online docs. The folks at tables by themselves, who you ask to sit with and then get to know -- they're not online docs, either. The people who are still nutty enough to be running around causing a fuss without being paid to are online nuts, but they're not online docs, at least not ones you're going to run into. (Paying people to cause a fuss is pretty pathetic, and has always looked pathetic, yet marketing folks keep trying it, which is even more pathetic.) The unknown ideas that show up that get you thinking a new way? Who is going to point you at those online docs?
Which is why the BOFs are often more interesting, more vital in both senses, than the talks. Look around. Find a couple you not only don't recognize, but that look like they might open to something new. If you haven't been to two or three BOFs like that, you've wasted your trip.
After ten years of JavaOne it can't be the exciting innovation it once was, but it still has exciting innovations. So post up the sideways things, the interesting things you're going to look at. Let's help each other find the good stuff, the stuff you might not put into your trip report, but that you regale others with over coffee or beer. It can't be all spark anymore, but let's keep connected to the spark anyway. ]]>
What I always look for, though, is the new version of the Unicode book. In about 1,000 pages of technical text, one can find out amazing things about various languages and writing systems. Our book already has an exposition on title case (which is a third case beyond lower and upper case, used in Croatian). Case again rears its head for Georgian which has an upper case, but the upper case is considered archaic, so while toLowerCase will translate any upper case Georgian letter to its lower case equivalent, toUpperCase will not do the opposite.
And so it goes. One of my favorites is \u09F8 (which looks sort of like a backward N). This is a Bengali currency symbol that means “one less than the denominator” in a fraction. I don't know what this is really for, but I've always assumed it was the way that Bengalis did the equivalent making things look cheaper by pricing things for $19.99 instead of $20.00. So instead of writing “19 31/32” or “19 15/16”, they just made a mark that meant “Doesn't look as expensive as it really is!” Saved a lot of time and trouble, no doubt. Maybe it means something else, and I may be just about to find out from some Kind Reader, but I've thought sometimes that we ought to extend Java that way: Allow \u09F8 in expressions such as “\u09F8 / i” to mean “figure out what i is, subtract one, and then divide by i”. How useful!
Well, today I finally got my copy of the Unicode 4 book, and I've opened it right up to the choicest bit: \u2600 - \u26FF. That's where they put the “Miscellaneous Symbols”, and they are quite a miscellaneous lot. This is where you can find the hammer and sickle sign for communism alongside the peace sign. Want a snowman in your text? Try \u2603. Writing a horoscope? Here are your astrology symbols, right next to the religious and political symbols, such as the one for Iran (\u262C).
I've always figured that some of this got here as pranks. Maybe in each version the leader of the group or the person who wins the karaoke contest gets to add one personal symbol. I don't know, but it might explain why, tucked in between the card suits and a set of basic Western musical notations, is a symbol for “hot springs” (\u2668).
Well, this version's karaoke star was a recycling nut, I guess. There are 12 symbols for recycling added. And maybe this year's drunken evening was at the casino because now we have images for all sides of a six-sided die. (Not D&D players, clearly, as we have no images of 20- or 12-sided die sides. Maybe next time.)
Of course, Unicode 4.0 is not just about adding a second kind of umbrella symbol (\u2614, which is just like the existing one except that it has little raindrops above it; for versimilitude, I guess) or a steaming coffee cup (\u2615, so you can have coffee in your hot springs). That's just where groupies like me go to look at the seamy underbelly of character encodings.
No, it was mostly about adding new entire character sets, such as Mongolian, Osmanya (Somali), and Canadian Aboriginal. Many added sets were historic. Unicode is not only for modern languages, but also provides standard ways to encode ancient languages. So Linear B (an ancient Greek script) is available, as are Runic and Ogham (old Irish). They also added Deseret and Shavian, scripts desinged for writing English phonetically (Shavian was designed by playwright G.B. Shaw. Mark Twain also invented such a system, but his dropped redundant letters (“c” can be written with “s” or “k”) and then reused them. This had the advantage of not requiring an entirely new typographic system, or a new Unicode block set, so he remains unrecognized by the Unicode committee.)
The really neat thing about this is that these are all characters. I mean, real actual characters to Java. You can write your identifiers in ancient Irish or Scandanvian Runes. Although it raises some interesting questions, such as: What would Homer name a loop index variable? Or, Should you use Shavian instead of ASCII for English variables to help the reader pronounce the names correctly? Or if you name identifiers using Ugaritic, which is a cuneiform system, do you need to be able to print out your code on clay tablets?
Unfortunately Java does not (yet) allow you to write numbers in non-ASCII scripts, but if we are fortunate, we could someday be able to write our constants using ancient Aegean numbers.
Time to start lobbying!]]>
One phrase I am known for repeating is "You're thinking too hard." I use it to mean that someone is looking for a complicated, subtle meaning instead of a simple one. Often it seems that if you pretend the solution is simple, it becomes so.
So I have to say to PJ: "You're thinking too hard." Here are her concerns (quoted from her blog):
This is the level of precision of most legal standards. These words are then interpreted by judges to apply to particular instances, which nails it down harder and harder. But the word "trivial" (or the phrase "trivially obvious") fits into the structure quite nicely.
As for prior art, I would say a patent is "ludicrous" if it steps on prior art "widely known to those normally skilled in the art." In our current poster child, I would say that finding folks who have heard of "not equal" operators for comparing objects, pointers, or references would be pretty damn easy. It's probably hard to find normally skilled folks who haven't.
Liability is even easier. Those who are in a position to profit from the fraud are liable. Typically this is the patent's actual owner, who may or may not be an inventor. In our particular poster child, this would be MicroSoft. I use the phrase "actual owner" because people who are clever should not escape their responsibility by hiding the patent in a shell company or something. Like with any other fraud, you cannot escape liability easily. If you buy a patent, you buy the risk. So don't buy a patent that is likely to be ludicrous.
Others have worried about the new lawsuits involved. First, remember that if you file a claim on a ludicrous patent, you only get paid if you win. This is real incentive to avoid that. And there are protections in the legal system against frivolous suits, which would equally apply here. Remember, the idea is to leverage the existing systems to address the problem, not invent an entirely new system. Standard safeguards and rules apply. We're just defining a new form of fraud, based on existing standards for fraud and patents. Once we've set up the language reasonably, most things should just follow naturally.
I don't declare for or against software patents here. We can leave that for some other time. But politics is the art of the possible, and I think that this suggestion actually is slightly near possible. And I think it would make a difference. And, like PJ, I like the idea of someone getting legally smacked for being "ludicrous". That alone would be worth it.]]>
So here's an idea that actually gives some major players a strong stake in the outcome and could have a big impact: Declare that ludicrously obviously invalid patents are a form of fraud. And enforce that by giving anyone who proves patent fraud by ludicrosity gets paid triple their costs as a reward, plus any damages they can show were caused by the issuance of the patent.
As a starting point, I would define a "ludicrous" patent as one that any practitioner normally skilled in the art would recognize as having prior art. MicroSoft's is our most recent poster child, who seems to be seeking a patent on an IsNot operator that checks if two pointers point to the same place in memory. In other words, it's like C's "p1 != p2" where p1 and p2 are pointers. Uh, hello? Can we say prior art, like almost any machine instruction set? And can we say "obvious" as in "done in almost any language you can name that has pointers or references"?
I model this on "whistle-blower" laws that encourage private citizens to ferret out fraud against the government by giving successful ferreters a chunk of the recovered money. This means that the gov't itself doesn't have to do anything to ensure that a bunch of investigators are always looking for fraud against it. If someone has a good case, the perps pay the investigator. And it also keeps the number of frivolous fraud suits down, because a frivolous fraud suit gets you nothing.
Here we create a herd of patent lawyers who will invest their own money knocking down patents that are ludicrous and collecting bucks. Sometimes they'll get a nice payment from a simple letter that shows the holder that they will lose the case. Sometimes they will win big bucks when someone defends one of them.
It also creates a liability for filing ludicrous patents, which (beyond filing costs) there is none now. It helps protect every major player who isn't using patents as offensive weapons. And another set of major players -- the patent lawyers -- have new ways to make money.
To be fair to those holding patents the predate this rule, I would give holders one year to voluntarily void any patents they hold, but after that, all unexpired patents would be fair game.
So what so you? How about we pay the lawyers to sue the lawyers to keep the pool cleaner?]]>
One approach is to think that software patents are just plain wrong. Maybe so, but this isn't obvious to me. Patents have protected other technologies, and they might be able to handle software. Software patents as currently done are broken, dangerous, and frankly f'ing insanse, but maybe it's fixable. Or at least we can lower the temperature of this hot tub in Hell.
Any mitigation must start with the basic problem of knowledge: Almost nobody with actual authority in software patents is competent to understand software. Patent examiners (I'm sorry to say) are not our best and brightest. The Patent Office doesn't pay enough to attract or keep top level folks. Juries (like the one in this case) are picked from the normal jury pool. Imagine trying to explain the difference between (say) virtual memory with paging vs. an on-chip CPU cache to mother. And then remember that your mother is smart enough to avoid jury duty. Not to mention that the judge is a lawyer, most of whom have only the most basic scientific training.
In short, everybody who has the power to make judgements is almost certainly unqualified to do so.
My favorite solution would be to fire all the examiners and replace them with 25 actual experts, and let them grant (say) 30 patents a year (with maybe a unanimous vote for adding more).
But we could also require that the "jury of peers" be peers of computer people. Those of us who are computer folks could join that jury pool and be exempt from other jury duty. Then maybe the jury deciding this kind of stuff might have a chance at having a clue. This would be especially good because patents are only supposed to cover thing not obvious to your average pracitioner in the field. Who better to judge besides a jury practiioners in the field?
We could also make software patent grants provisional for 6 months. They get published and the outside world has a chance to throw prior art at it to see if it sticks. A lot of companies would be highly motivated to try knocking patents down before they cause any damage. It would be a way of drafting highly competent technical folks from these companies into the process of weeding out the idiocies.
These are just some ideas, but it's a pretty depressing situation and we oughta do something...]]>
What's going on with RFID itself is also interesting. We're getting to the point where tracking objects -- real objects -- will be a major focus of computing. When you can know where every piece of paper is in your files we will have a new scale of relationship modeling. (Well, new to most -- in the past anyone dealing with this much specific information was using large-scale systems that were very hard to build.) I think there will be a lot of interesting work in figuring out how to correlate all the information in a timely fashion.
Tomorrow's candidate for "Most Likely to be Wow" is the Orbitz talk. Ever thing you book on Orbitz runs on a Jini backplane.]]>
The folks who do Java stuff out in the world have ranged from intrigued to fanatic about Jini and JavaSpaces, but those who set the schedule always seem to have something else to talk about. Somehow the Jini/JavaSpaces stuff is always "new". It's been "new" for over six years now. Last year it was part of the emerging technology track over five years after it emerged. This year it's apparently "unexpected". I kid you not: The track it's in is "Intruiging and Unexpected: New and Cool".
Let's get real. Jini is in mission critical web sites (this year's talk by Orbitz might get your attention, for example). Companies have been run for years on its software. Sun itself is betting its RFID strategy on Jini. Large scale systems use JavaSpaces, starting with its introduction six years ago as a show-wide demo, and including (this year) a a large grid-computing system by a major investment company to follow on from last year's talk by Freddie Mac, among others.
The one talk you must go to if you have any doubts is the overview of where the whole technology stands. Your head will spin as you are whirlwinded through a survey of what's actually happening in the marketplace, both in industry leaders and startups. Then make up your own mind.
But to Sun this stuff seems to be perpetually arriving. New. Every year it's new. Which is unexpected. You'd think Sun would have noticed by now that it isn't new, that Jini and JavaSpaces are being used in ways where, if they didn't do the job, they would be chucked out before the company failed. Intruiging, isn't it?
For many folks at Sun there are two kinds of Java: J2EE and J2ME. Everything else is just baggage. And these folks seem to control the agenda for JavaOne. The number of rejected talks by big projects using Jini, JavaSpaces, and other Java technologies is pretty amazing.
The Jini community -- inside Sun and out -- keeps sticking to it, thank goodness. This year, as in the past, we'll just make our own conference-within-a-conference. Your primary resource for this is probably Frank Sommer's summary of what's shaking with Jini and JavaSpaces at JavaOne this year. There are a lot of things going on, and more things happening informally. Keep your eye out for the Jini folks, both from Sun and otherwise. There will be many around.
Maybe it's time we started passing out "Ask Me About Jini" buttons. Start our own pyramid scheme. If Sun won't bother to make Jini and JavaSpaces visible -- even squelch them in this most public Java forum -- we'll just have to make it happen ourselves. Join in, or at least give the overview talk a listen to see whether you ought to care. I think you'll be surprised how this perpetual newborn is already a responsible (if cool) adult.]]>