WebObjects and Questions on Versions
There has been a bit of confusion or consternation about the recent Xcode 2.3 release and the version of WebObjects it contains.
It is understandable that things are unclear. With the recent change to WebObjects, which made it ship as part of Xcode and not as its own product, some big issues were clarified. But there is also some follow-up work that needs to be done. WebObjects is, in important ways, a bigger product than Xcode. It is certainly older. Fitting the multi-colored, day-glo-painted WebObjects bus into the back seat of the Xcode two-seater sports car has been a challenge.
Some things are being done which are not designed to have externally visible effects and this is causing some of the versioning issues that people see.
It is recognized within the developers at Apple that "Xcode", as it is now, is not the monolith it might have been at one point. Information on versioning of Xcode needs to be provided at a finer granularity. Exactly when this might be done is not known.
Developers should realize, though, that WebObjects ships with Xcode. To be more precise, it ships inside the Developer Tools release of which the Xcode application is the "flag ship" signifier.
So, the label "WebObjects 5.3.1" has less meaning than it used to and it definitely has less meaning than some developers seem to think it does. From a technical perspective, it is not clear what meaning it has. Does the meaning of the version have marketing value or technical value? I do not grok marketing, at all, so I do not know.
In my view, the "version" of WebObjects on a machine is derivable from this procedure:
- Execute:
find /System/Library/Frameworks /System/Library/PrivateFrameworks /Developer/Applications/WebObjects /Library/WebObjects /System/Library/WebObjects -name version.plist
- Find all of these that are installed by WebObjects. This is, um, left as an exercise for the reader.
- Get the union of the keys in these plist files.
In a very real way, though not in a very user-friendly way, that is the way to precisely determine the version of a WebObjects system.
I think that we want to give developers the kind of information that will provide them with the information that they need to understand what a particular release means to them. I believe that we want to provide information about a particular release that explains the benefits and risks of a given release.
All I can say is that this is hard to do. We are open to suggestions, but the WebObjects team also has to follow the rules placed on them by the corporation. And that means lawyers. But that is the world we live in. It is not going to be possible to make everyone happy. Some people want a depth of information that an enterprise products company would provide. Apple is not an enteprise products company. It is Apple.
JavaOne - The Mid-Week Hump, a Little Late
Sometimes a week can seem like a really long time.
There is a certain simplicity to going to an out-of-town conference. You get on a plane, and you go. It is a bit like the "gathering of the tribes" that used to happen among the tribes on the Great Plains. Except we do not bring our kids, our wives, our horses and our houses with us. We call room service.
JavaOne is a little too close to home for me. I still need to get the kids to school in the morning. I think it makes the conference a different kind of experience. I cannot get the really concentrated information dump that some people get. I cannot wait to get a bean bag chair in the main hall. I need to keep trying to find the part of the conference where the wireless network actually works. Thankfully, it is Firday and Moscone Center is almost networked enough. Who would have thought that so many JavaOne participants would want wireless connection? Certainly not the people who set up the wireless here.
But I also do not get that washed-out, spiritually empty feeling that can come from being out of town at a conference. A conference can be a beautiful thing, a forum for talking about those things that bore most people we know. And most of us get it. But it can also be like coming off a bad meth jag. Too much of the wrong kind of food, too much time in a bar with people you really do not know, and there you are. You know what I mean.
But this is turning out well. I like the fact that they show most of the keynotes in the hall. It is nice to be able to see it, see what they are saying and, yeah, it is still a lot of marketing and you can walk away. And that part of the conference is fast approaching. The part where everyone walks away.
First, I would like to mention one of the technical talks. I went to the talk on Generics. This has been around a while. There has been lots of press on Generics. I have read some of this and most of the time I feel as though not much has been explained. Really, there is not much there. Generics are not a large shiny feature, but they are nice. Could you take them or leave them? Yes. But on the other hand, if you work on frameworks, they can do some nice things.
If you use Generics, it can be really nice. One can stop casting so often. Every time, every single time, I cast an object when bringing it out of an
NSArray or from a
key-value-coding call, I remember the guy who said that in a real type-safe language, one should not cast. I do not remember his name, but I remember what he said.
If you use Generics, you stop casting so much. Going back to casting then feels even stupider. Can't we get past this already? Perhaps we can. We'll see.
JavaOne - First Day
I had not been to a JavaOne for a few years. They are usually scheduled at the same time as Apple's WorldWide Developer Conference and I usually have to present at that, or do other work for the conference.
Yesterday was good. There was good energy and a lot of interested people. Asking random people what they worked on almost always got people going about this and that, usually with a lot of passion. There were a lot of internationals, inclusing a recent grad from Brasil who won a ticket and a gentleman from South Africa. There were some suits who had some behemoth app for some insurance company and they want to make sure their behemoth can keep chugging along. But there really were not too many of those. And you cannot get rid of these people completely. After all, they usually have money.
The session I most wanted to go to was the Concurrent Collection talk by the guys at Sun who brought you
JSR 166 and all that great stuff.
Most of the talk was a walk through the classes. It was useful to hear the rationale and the "canonical use case" for a given class. It is always unclear, at these talks, if one could have just more completely read the web pages and got the same info. I think some of this was not just "stuff from the web".
For example, looking at
BlockingQueue and the
SynchronousQueue, I do not think I would have seen this. Brian Goetz explicitly called out that the SynchronousQueue was not like the other BlockingQueue sub-classes but was most usefully thought of as a pipe for producer-consumer situations.
Another class was the
Exchanger, which was described as being one of the "Syn chronizers". I think that "Synchronizer" is a casual term. I do not see it in the classes. The use case for this as, again, a producer-consumer situation where one wanted to swap an empty arrow for a full one, for example. The other synchronizers namred were
Semaphore,
CountDownLatch, and
CyclicBarrier.
It always seems to me that some of these classes are just random bits of "hey this might be useful" stuff, but when such smart people are doing the classes, then I think that their random bags of "just stuff" are probably worth working with. We'll see.
There were a couple of things that I had seen but that I now want to look at more closely.
One was the
Future interface. Brian described it as a thing to hold the result of a call that might occur in the future, might have occurred already, or might never occur. It gives you a way to decide whether the result is still expected and deal with the fallout from that. This is certainly an interesting way to approach the abstration.
The other is the
atomic instances. These were described as being like volatiles but better, as one had atomic operations on them.
I do not know if this made it to the documentation or not. It was said that the
Lock interface was useful in J2SE 5.0, but might not be so useful after that. Apparently, the
synchronized keyword support in later versions of the VM is much better. It was said that the performance gains obtained through the use of the Lock interface became less notable after the fixes to
synchronized. This is probably a good thing to know.
I'll try to update this every day and find some of the things that are not hype. I do not try to go to a lot of sessions. I find one learns more by talking to people, keeping one's ears open and like that. One also has time for a few sessions with the new first-person shooters in the Games Lab. Not that I hang out there overmuch. Yeah, of course not....
If you're at the conference, I hope you are having fun and remember, if you can see them in your scope, you might already be dead.
