Java Devs Face MetaData Agendas in 2004
Java devs could get at least two metadata reference implementations to play with early next year. The JCP has said it would have an early release RI for J2SE 1.5 (Tiger), and BEA has said they are gearing up for an early release of an RI for its JSR 181, whether or not it has full JCP approvals by then. IDN spoke with Onno Kluyt, Program Director at the JCP, to get a feel for what may be coming, and how devs can keep a straight head -- and maybe even put in their own comments.
IDN spoke with Onno Kluyt, Program Director at the JCP, to get a sense of what may be coming. While Kluyt deferred any comments on specific technical approaches to the metadata spec leads at the JCP, he did share his "general observations."
IDN: What can you tell us about the current state of Java support for metadata and the various JSRs related to the topic?
Kluyt: Metadata is a hot topic within the JCP over the last couple of months. Quite a number of other JSRs depend on the plans of the metadata JSRs. You may have noticed a couple of JSRs submitted over the summer that form the basis for the next version of J2EE and JDBC. They all plan to make use of the metadata JSR 175 to work on the theme that we call "ease of development."
IDN: So, metadata will be important to most Java developers, J2EE and J2SE, in 2004?
Kluyt: One of the focus areas, or themes as we call them, that will be shared by both "Tiger" for next version of J2SE and J2EE 1.5 (the next version of J2EE) will be [our] trying to provide hooks and high-level APIs to make it easier to develop logical applications.
IDN: Just how does metadata support or JSRs tie in with ease of development?
Kluyt: One [area] comes from the large tool vendors, who can use metadata to provide innovations and such in APIs that tool vendors can use to do "nice things for the developer, " as Craig Hamilton, one of the [Java] architects, likes to say. Metadata is very much used by IDEs and tools to understand what the developer is trying to do, such as building specific kinds of web services or servlets and so on, and then adjust itself and provide appropriate functionality for the developer.
IDN: Are the metadata JSRs on track for 2004? While you're right about there being a lot of intensified interest in metadata for Java lately, progress on the topic seems to be slow. For example, the BEA JSR  has been tied up for more than 18 months now.
Kluyt: There is so much interest in metadata from so many other expert groups that the thinking now is the core metadata JSR better get it right. In the past, many JSRs that talk to the Java programming language directly (such as JSR 14 generics) typically take a bit of time because they affect everybody. A language change affects everybody, whether you're developing for the desktop or the server -- it doesn't matter where, you are affected. Those JSRs are typically very popular and close to developers' hearts because they affect their daily life, so they're important to get right. .
IDN: Without getting into specific technical details that you're not comfortable discussing, let me ask this: Does the JCP membership at this point know enough about what Java-friendly metadata needs to look like so we can move forward with metadata JSRs?
Kluyt: There have been a lot of independent minds looking at this, and so some of the initial research has already been done. A bunch of this work has come from BEA's work in Cajun, but there has also been research from IBM, Borland and Sun on what needs to be done.
IDN: With all this vendor-driven research, does the Java community yet have a single vision for metadata?
Kluyt: In my view, the right balance is here. A lot of primary research was already being done to have an idea of what would be appropriate to standardize.
IDN: Which JSR(s) reflect this widespread work on metadata?
Kluyt: There are 2 directly related to metadata: There is the MD JSR for J2SE 1.5 and the J2EE-related one led by BEA. Together, they provide the core metadata functionality for Java, if you will. What you can expect to happen is enterprise devs and tool vendors will provide additional functionality through metadata descriptions, if you will, on top of these core functionalities.
IDN: How would you envision that this added capability will be used by developers?
Kluyt: There's an analogy between what's set to happen with metadata and what we've seen with Java Server Pages; there was the core JSP and then there were tech libraries. In this example, JSP provided the core definition, if you will, of what a "Java Server Page" is, and then there are the additional libraries that provide sets of tags that are used [by developers] to describe and label your JSPs.
IDN: So, procedurally, do you expect these 2 metadata JSRs to be sufficient?
IDN: What will it take to start seeing some faster movement on these JSRs? After all, as we said, the BEA work is approaching two years.
Kluyt: I think they are moving at the appropriate pace. The metadata JSR for J2SE is scheduled to go into Tiger, so basically [that group] has until summer ['04] to finish up its work. So it's going with the appropriate pace for a J2SE 1.5 release.
IDN: What about speeding up JSRs or related work for the added functionality?
Kluyt: I can't comment on that part, because I'm not readily up to speed on all the exact activities and development cycles involved, but what I would I expect is that in a couple months' time there will be an early-access version of Tiger coming out, and that will have an early-access metadata implementation for developers to play with. After that release, then, I think, you'll then see a lot of that stuff happening.
IDN: So, it's fair for developers to expect that an early-access version of Tiger could still include metadata features based on that JSR, even though the JSR may not be formally adopted by the JCP until summer?
Kluyt: Let's be careful with terms here. The early-access implementation of Tiger will also be an early-access version of the metadata JSR. The JSRs that are part of Tiger have all basically passed [JCP] community review in the August/September timeframe. Also, most of them are reasonably close to going into public review.
The idea would be that developers could see that the early access of Tiger reflects those draft JSR specs, and so it would be like we were saying, "Here is a draft implementation of those draft specs, so you can go play with it. And, here's an additional tool for you to review to see if we're going the right way." So, in short, we'll show developers the draft specs, and draft implementation of those draft specs, and then we'll ask for feedback. Then, later, the mandatory stage of the JSR is public review where anyone with Internet access can review that specification.
IDN: What about metadata JSR for J2EE?
Kluyt: JSR 181 [BEA] hasn't passed community review yet. And 181 depends on JSR 175, which is the foundation for all metadata-related functionality in J2EE.
Other Java Metadata Resources
In his position as JCP Program Director, Kluyt said he couldn't discuss technical particulars of JSR175 or JSR181. However, IDN will bring you an update from JCP technical leads. In the meantime, here are some notable comments from other Java players on the status of metadata for Java. :
JSR 175 status comments -- Sun Distinguished Engineer Mark Hapner is quoted from a recent chat session at java.sun.com. "The JSR-175 expert group seems to be making good progress, and I know they're looking carefully at the XDoclet facility as one source of inspiration. The group itself has a broad background; take a look at its member list (see earlier link). I expect them to make a significant contribution to Java ease-of-development."
BEA plans reference implementation of JSR 181 -- After more than 12 months inJCP committee review, BEA execs confirmed this week that they plan to release a publicly downloadable reference implementation for JSR 181 for use as what they call "a blueprint in developing like frameworks," to workshop for web services deployment.