Four JSRs had their Community Drafts approved by the community.

JSR 175 (Metadata)
Community Draft Ballot Results | JSR Home Page

Everyone who voted, voted yes, however a couple of vendors made some comments.

IBM was concerned about the removal of the previously proposed standard API for "arm's length" retrieval of annotations. They want this addressed, either in this JSR or another as they feel it is important for tools. They also state that the vote is based on technical merits, NOT on the licensing terms (where there is some concern for open source)

BEA said that their vote is based on the technical merits too, but are concerned that the packaging is tied to J2SE 1.5, and hope that there is a way to get it out there for J2SE 1.4.2 users.

JSR 201 (Enumerations, Autoboxing, Enhanced for loops and Static Import)
Community Draft Ballot Results | JSR Home Page

Again, all votes were positive (of those who voted), and there were only a couple of comments. IBM gave their speil on licensing, and Caldera said that, although pleased that auto-unboxing is now included in part 5 of this JSR, the description of the autoboxing/unboxing change still suffers compared to the other four parts: no examples, little motivation, just lots of JLS-ese. This description should be improved before Public Review.

JSR 215 (Java Community Process, version 2.6)
Community Draft Ballot Results | JSR Home Page

BEA stated: "While we view this as a small step in the direction we need to take the JCP to ensure continued success, we nevertheless endorse these changes as positive, if insufficient."

Nokia said: "We welcome the increase of transparency of the EG progress, which this JSR enables. Some clarifications though are still needed before public review of this JSR, such as whether a JSR can be placed for final ballot only after RI/TCK is ready for all platform editions referred in the JSR or for one platform at a time. Also the TCK requirements language might need some adjustment."

JSR 202 (Java Class File Specification Update)
Community Draft Ballot Results | JSR Home Page

No comments other than the IBM one that you can guess.

Still wish there was a dynamic component of JSR 175. Let me give an example, let's say you were using JSR 175 to declare J2EE transaction semantics. It would be nice if you could do both

@NotSupported void someMethod();

as well as declare it in ejb-jar.xml

And yet, from with the J2EE server implementation, access the metadata from the same API.

This also helps for frameworks that use metadata, but don't necessarily want to allow the declaration of it at compile time. Meaning, they want some obliviousness to apply metadata.

Bill

Bill:
Still wish there was a dynamic component of JSR 175. Let me give an example, let's say you were using JSR 175 to declare J2EE transaction semantics. It would be nice if you could do both
And yet, from with the J2EE server implementation, access the metadata from the same API.


Not sure what you are asking for. The JSR gives you a standard API to access the metadata. The fact that it could also be specified in some other way than annotations clearly doesn't belong in the specification but in third-party tools, since there are so many ways you can specify these external annotations (XML, property file, command line, etc...).

All these third party tools need to do is generate Java classes that conform to the class layout defined in JSR 175.

Or did I misunderstand you?

--
Cedric

> Still wish there was a dynamic component of JSR 175. Let me give an example, let's say you were using JSR 175 to declare J2EE transaction semantics. It would be nice if you could do both
> And yet, from with the J2EE server implementation, access the metadata from the same API.
>
>
> Not sure what you are asking for. The JSR gives you a standard API to access the metadata. The fact that it could also be specified in some other way than annotations clearly doesn't belong in the specification but in third-party tools, since there are so many ways you can specify these external annotations (XML, property file, command line, etc...).
>
> All these third party tools need to do is generate Java classes that conform to the class layout defined in JSR 175.
>
> Or did I misunderstand you?
>
> --
> Cedric

Maybe you misunderstood...

I'm saying it would be nice for the lookup and storage of metadata to be in one place, but the declaration of metadata could be anywhere. From with Java itself, XML, property files, whatever. The above was a usecase of this. That the J2EE container queries metadata about transactional attributes from the Class itself rather than having a deploy time thing of reading both class JSR 175 metadata and ejb-jar.xml and writing to a proprietary repository.

Another point being that you can't obliviously attach JSR-175 metadata to a class, you have to do it within code. That there is no way for a third party format/tool to specify metadata. For the same reason you have obliviousness for aspects in AOP, you might want the same for metadata. I don't see a way to do this with the current JSR-175 metadata.

Bill

Mmmh, still not getting it.

JSR 175 defines the following things:

- Standard way of specifying annotations in the code
- Standard way of storing these annotations
- Standard way of accessing these annotations

If you want more flexibility, you can write a tool that will generate either annotated code or class files with bytecode annotations. And the number of ways this can be achieved makes it unrealistic to include this in JSR 175.

Granted, JSR 175 doesn't *specify* what you are asking, but it certainly doesn't make it *impossible* for you to write the missing piece.

--
Cedric

>
> JSR 175 defines the following things:
>
> - Standard way of specifying annotations in the code
> - Standard way of storing these annotations
> - Standard way of accessing these annotations
>
> If you want more flexibility, you can write a tool that will generate either annotated code or class files with bytecode annotations. And the number of ways this can be achieved makes it unrealistic to include this in JSR 175.
>
> Granted, JSR 175 doesn't *specify* what you are asking, but it certainly doesn't make it *impossible* for you to write the missing piece.
>

Impossible to add metadata at runtime without reloading the class and without writing your proprietary metadata format and lookup mechanism to wrap around JSR-175.

Admit at least, that it would be nicer.

Now what is the reasoning behind not being able to add/modify/create metadata at runtime? You left that part out.

Bill

\Bill Burke\
Impossible to add metadata at runtime without reloading the class and without writing your proprietary metadata format and lookup mechanism to wrap around JSR-175.
\Bill Burke\

Metadata in the JSR is primarily about declarative programming - giving you the ability to declare extra-language information about a class. The intended effect is to mimic declarative language level terms like synchronized, static, etc for specialized uses outside of the language. As the first two sentences in the JSR request says:

"There has been a growing trend towards annotating fields, methods, and classes as having particular attributes that indicate they should be processed in special ways by development tools, deployment tools, or run-time libraries. We call such annotations metadata."

The intent is that they mimic static class/field/method-level attributes (as oppposed to object instance attributes).

What you're proposing, I suppose, comes out of JBoss AOP's ability to tack on metadata arbitrarily at runtime to either a class or an object instance. This isn't in the JSR because it wasn't something the group was trying to achieve. You don't turn "synchronized" on and off, you don't have a method that's sometimes REQUIRED_NEW, sometimes SUPPORTS, and sometimes NEVER. There's no technical reason why you couldn't do what you propose, but it's a complete mismatch conceptually from the goals. It also would add considerable complexity to the spec and implementations - complexity which would be rarely used, and often abused.

I also suspect most people would say "you want dynamic behavior, write your own config system or add an instance variable to the class".

    -Mike

Impossible to add metadata at runtime without reloading the class and without writing your proprietary metadata format and lookup mechanism to wrap around JSR-175.

Admit at least, that it would be nicer.


It was considered at the very beginning but was quickly discarded because

- Nobody could come up with a convincing use case
- It was at odds with a lot of core concepts connected to the immutability of the class file
- It would add a tremendous amount of complexity to the spec for unobvious gains

Mike just explained this in more details better than I could (were you eavesdropping on the mailing-list, Mike? :-))

--
Cedric

\Cedric Beust\
Mike just explained this in more details better than I could (were you eavesdropping on the mailing-list, Mike? :-))
\Cedric Beust\

Actually no - the docs are just written well enough that any reader can quickly grasp what the JSR's trying to achieve, what's in-scope, and because of that it's pretty easy to divine what's outside of the requirements.

I personally believe that JSRs should be as limited in scope as possible, and it's better to leave out then add in. The "yeah, let's add this thing, it's simple and so cool" mentality is powerfully attractive, but the end result often seems to be more like entity EJBs 1.0 than something comprehensive, internally consistent, and useful. Because once you let the cat out of the bag, it's tough to get it back in again (says the man with three cats :-). If something overblown gets released into main stream Java, it's extremely difficult to try to take it back or fix it. On this JSR, I'm glad the goals were kept modest, and the resulting spec can probably be highly efficiently implemented, and useful at the same time (and not shoot us all in the back sometime in the future).

   -Mike

Any ideas if EJBGen, QDox, or XDoclet will offer JSR-175 functionality anytime soon?

Andrew:
Any ideas if EJBGen, QDox, or XDoclet will offer JSR-175 functionality anytime soon?


EJBGen will definitely provide support for JSR 175 as soon as the spec is final. We've had some encouraging comments from the community review, the next step is public review.

--
Cedric

Not surprisingly, I find myself agreeing with Bill (again) on this one. But time will tell. Nothing prevents it from being added later should convincing use cases be presented, or (heh!) should Microsoft do it first (runtime modifiable attributes).

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

It's an interesting concept, but I have a few concerns:

  - Do dynamic metadata constructs make sense compared to, say, adding an
    instance variable to your class? There's clearly some overlap between
    meta-data and regular class stuff, the question is "where do you draw the
    line?".

  - Cedric pointed out concerns about classes being inviolate once loaded.
    There are alot of implications that go along with them - and many of those
    are _good_ implications.

  - Class footprint, performance. What's the overhead in allowing dynamically
    modifiable meta-data?

  - Effect on running code. What happens if you're modifying meta-data that
    a thread is actively using? Synchronization issues alone may kill
    performance

Note that, just like with AOP, you can fiddle with a class and add/remove meta-data at will before it's loaded (or just as it's loaded), so all sorts of pre-processing can be made in a "just-in-time" manner for static attributes. The
only issue here is loading a class and instantiating objects with one set of
attributes, and then effectively changing your mind mid-stream and changing
those attributes at runtime. Does this _really_ make sense? Could something
as simple as adding an instance variable to your class (perhaps static) solve
this "problem"?

    -Mike

The background that I'm thinking "from" is related to what Microsoft used to call "Ambient Properties". Maybe the class designer didn't intend objects of the class (or the class itself) to have such properties, but the container (for example) needs to. Using attributes could provides a means to handle a certain category of "class (or 'vm-structure') properties" that are typically read-only at runtime but that one could find uses for having *not* read-only. Obviously, making it mutable does not have to imply a "free for all". Even System.in and System.out can be changed, for example, but don't try to do that on a hardened system ;)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

I think I hear where you're coming from, but I don't see a convincing case for it.

The point of meta-data, as I understand it, is that a developer encodes properties/attributes/meta-data/whatever-you-want-to-call it directly into a class. This information becomes available to whoever wants to use it to treat the class specially in one way. As a side effect (sort of), this information is available is a very well defined location (the meta data of the class).

Today, you can specify properties/attributes/meta-data outside of a class quite easily - XML/properties files/whathave you - that are keyed off of things as simple as a Map.

A runtime system can also easily build up extra information on its own, often with something as simple as a Map (you may have heard of Maps, Cameron :-). For something like a container, I'd imagine such a Map would be available to everything in the container. You can obviously do similar things with something like ThreadLocals to perform a similar function in a per-invocation-context manner.

The part that's missing is a centralized & standard access location for data that may come outside of a class, or be mutable. The key is the "centralized & standard" bit - you can plainly annotated any class/object in a myriad of ways on your own, but they're known only to you.

Anywho, you'd need to find a situation where runtimes, which are not aware of each other, need to access the same sort of meta-data/properties/attributes at the same time, and mebbe change them.

Runtimes controlled by a single source don't need any of this - as JBoss AOP demonstrates. They do meta data per class, per object instance, or per invocation thread on their own quite handily. But - this information isn't exchangable with other runtimes that aren't aware of JBoss AOP.

So you might come up with a use case for disperate systems, unaware of each other, which need to see the same information (the same _exact_ information) which did not originate in the source class (and may be mutable). To a small extent, this again can be done post-compile time, right up to load time, in the class meta-data itself. So, again, you end up with a situation where two or more systems are trying to add/remove/change meta-data _which they share_ for reason.

That, IMHO, is a bit of a stretch. Take away the "sharing" part, and the argument falls apart. Take away the mutability aspect, and it falls apart. Maybe there is some value here that someone could take advantage of, but it seems pretty tenuous from where I sit.

     -Mike