Is Sun getting the component religion?

JSR 277 is to define

    "a distribution format and a repository for collections of Java code and related resources. It also defines the discovery, loading, and integrity mechanisms at runtime."

… which sounds a lot like components to me. In particular, they’re hitting a lot of my "hot buttons" regarding the use of Jar files when they write in Section 2:

    Java Archives (JARs) are widely used as both the distribution and execution format for Java applications. The JAR format dates back to the mid-1990s, and it has not scaled particularly well in either of these roles. JAR files are hard to distribute, hard to version, and hard to reference in general.

Amen to that, though I would take issue with the idea that they’re hard to distribute–a bit more verbose and/or less compact than we’d like, perhaps, but not a killing blow. The lack of versioning and references between Jars, though, that hurts.

    Distributing a simple Java application is considered to be a complicated task by many developers because it often involves creating a native installer to package multiple JARs into a distribution unit, and it sometimes involves converting the application into a Java applet or JNLP (Java Network Launching Protocol) application for web-based deployment.

Oh, sing it loud, sing it proud. Doing standalone/"rich client" Java application installations has been "Unzip this .jar file" for far too many years. (In truth, it’s a testament to Java’s standalone versatility that we could get away with that for this long, but we certainly could use something a bit more robust and standardized.)

    There is no built-in versioning support in the JAR format. There is no reliable mechanism for expressing, resolving, and enforcing the dependency of one JAR upon another. Referencing a JAR, moreover, involves specifying it in the classpath. Since the path of a JAR may change during deployment, developers are forced to fix up all the references to the deployed JARs as part of the deployment process.

Yes! But let’s be careful here, too, as one of the leading candidates for Java to model itself after (.NET) has it’s own share of issues in this space, too, and simple referencing of modules (as I guess they’ve decided to call them) isn’t necessarily going to solve all of our problems, either. It’s a good start, though….

    Developers also find it quite difficult to deploy installed Java extensions (a.k.a optional packages) because they can easily run into issues like versioning conflict and namespace collision. Java extensions can currently only be installed into a specific Java Runtime Environment (JRE); it is basically impossible to arrange for an installed extension to be shared across multiple JRE installations.

This is one of the first areas I disagree with the proposal thus far; the ability to set extensions on a per-JRE basis is one of Java’s strengths, in my opinion, and helps avoid some of the versioning/side-by-side issues that are currently plaguing the .NET crowd, specifically those who are at work trying to integrate SQLServer and .NET 2.0 together. (Microsoft’s recent pullback from "lots of managed code in the OS" stance for Longhorn is a testament to the concern over the problem, since–as it’s been explained to me–the concern is essentially one of how to version the .NET runtime without breaking Longhorn code in the process.) One of Java’s strengths is its multiple JRE stance–let’s not do anything to essentially break that.

    The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:

        A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
        A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
        A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
        Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
        A set of support tools, including packaging tools as well as repository tools to support module installation and removal.

This is awesome. This is exactly what Java’s needed for years. I wish it had been there from the beginning, but I guess 10 years later isn’t too bad, as major improvements in the environment go. And make no mistake about it, this is about as major an improvement to the platform as you can get without significantly rewriting the ClassLoading scheme from the ground up.

Now if we can just get the Isolates JSR back off the ground….

If you ever needed convincing that Java generics are badly done…

… might I suggest Ken Arnold’s recent blog post on the subject. My favorite quote from the piece:

    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.

Now, I can’t be certain if he’s criticizing generic types in general (meaning he would be equally distressed at C++ templates–which admittedly are far more confusing than Java’s generic mechanism–or .NET’s generic types–which, while simpler than C++ templates, can still be somewhat confusing, as ex-DM and still-currently-friends buddy Joe Hummel points out), or the Java implementation of them, but either way, it stresses an important point: approach genericizing your code with care, regardless of your language, be it C++, Java, or .NET. The complexities can sneak up on you when you least expect it.

JAX-WS and Indigo RC Interop

The Java/.NET integration story keeps getting better and better every day–two tidbits in particular stand out thus far.

From Eduardo Pelegri-Lopart’s weblog,

    I knew MTOM support was already implemented in recent JAXB 2.0 builds but I had missed that the full integration with JAX-WS 2.0 was also working. I just talked with Rajiv and he tells me that last night Simon and Rags got it working between the Indigo Beta RC and the JAX-WS 2.0 EA2 released last week. I hope I won’t jinx by talking about it, but Simon and Rags will demo it during their session this afternoon. … The session is TS-9866, "Advanced Web Services Interoperability", 2:45-3:45 in the Yerba Buena Theater.

And Simon echoes a similar story (though he did it with WSE 3, not Indigo) on his weblog:

    In my JavaOne session yesterday I showed (what I believe to be) the first MTOM Interop demo between .NET and Java using publicly available toolkits. For those that don’t know MTOM (Message Transmission Optimization Mechanism) is the new specification for optimizing the transmission and/or wire format of SOAP messages. Primarily this means that we have a new standard that allows the sending of attachments over Web Services – one that the industry agrees on, and one that is composable with the other WS-* specifications.

I still have to touch base with Simon to find out if there’s also an Indigo demo with JAX-WS* that he and Rajiv did, as I’ll want to steal… um, I mean leverage… it for my Indigo/Java talk for TechEd Europe in a week or two. 🙂

Better yet, in other news,

    You know who you are. We have finally publicly announced it; we will have a new JDBC driver for Sql Server 2005.

Microsofties at JavaOne

I’ve been cruising through the MSDN blog posts, and I’ve been surprised by the number of Microsoft FTEs (Full-Time Employees) who are at JavaOne this year, it seems. Most interestingly is their thoughts and opinions about being at JavaOne; not a single one (thus far in my reading) has recounted a negative tale about being at JavaOne, meaning that it sounds like they’ve been given a pretty warm reception. Or, perhaps it would be better to say, they’ve NOT been given the cold shoulder, something I genuinely worried about.

What strikes me most of all, though, is wondering how much of actively being exposed to the Java space is going to affect the .NET 3.0 ("Orcas") release–for example, CyrusN makes this comment (which I’ve excerpted from the longer post):

    I got to go see the BirdsOfAFeather talk with Josh Bloch concerning the new collection in Java1.5 (which you can read about: here) and the upcoming collections they have planned for the future (which you can read about: here). I’ve long been a fan of the java collections and i’ve found that they’ve normally held a good balance between simplicity and power. It’s actually a case of "Goldilocks and the Three Bears" for me. stl is too complex and painful to use, .Net is too simplistic and limited in power, whereas java get’s it just about right. It’s not perfect, but it’s flexible enough to handle almost anything you’d ever need. I always found the deep use of abstractions to be enormously helpful for writing your own special collections while only writing 1/10th or evern 1/100th of the code necessary to implement the full interface. It’s also not cluttered with a gazillion interfaces like i’ve seen in other packages which isn’t especially helpful in a language like java which doesn’t have unions.

What struck me is that if the Collections API seems to be "just right", can we expect a richer .NET API–one that closely mirrors the Collections API–to come in Orcas? Believe me, I would be the first to vote for that; I’m with Cyrus on this one, I love the Collections API’s approach, and have actually suggested to .NET developers to have a look at it for ideas for their own collections classes.

Now, the interesting challenge will be to see if any (and how many) Sun and/or other Java-developing companies or individuals show up at PDC this year to start… um… leveraging more ideas from the .NET space in return. 🙂

Looking for FreeBSD 4.7 ISOs

I’ve been meaning to do this for a while now, and now that I have some room on my laptop I want to create a FreeBSD 4.7 VMWare image so that I can show Rotor’s cross-platform nature (such as it is). But, to make a long story short, I can’t find the ISO images for FreeBSD 4.7. I can find 4.9, 4.10, 4.11 (none of which are officially supported by Rotor) and of course the latest 5.3/5.4 images, but not 4.7. Anybody happen to know where I can find archive releases of FreeBSD, so I can download them?

That, or teach me how to Google better…. 🙂