Otaku, Cedric's weblog

I just posted some ideas on this at TSS:

http://www.theserverside.com/home/thread.jsp?thread_id=21872

Sandeep.

what about :

import javax.ejb.annotations.*;

@Session(
ejb-name = "statelessSession"
)
public class TraderEJB implements SessionBean {

@Remote (
transaction = Required
)
public void buy(String stockSymbol, int shares) {
// buy shares
}
}

If you have struts/AOP/Hibernate annotations, you _are_ tied to hibernate/AOP tool/Struts.

tags or no tags.

You will likely have some imports from those , and will need the jars to compile.

a lot of the annotations supported by ejbgen,xdoclet etc will be a standard part of j2EE 1.5 so the common case will always compile

...or we could just forget this silly static typing of annotations and use the Javadoc method that's worked well for everyone for several years... I guess something working in the real world is a mark against it in the JCP world :-)

I never even thought about that. rather it didn't occur to me this is how it would happen. i like Jason's idea. can we just forget about it.

Yes , that sounds like a plan, chiara and jason you just forget about it.

>>silly static typing of annotations
And javadoc comments are somehow typed?

Yes javadoc has been flexible enough to provide a limited form of compile time meta data for tools like Xdoclet etc, but it was always a limited subset of what a metadata facility should provide, and the runtime should support.

Have a look at the way the CLR / .NET class libraries take advantage of a similar facility.
look at the design of atrributes , and how they are used.

J2EE 1.5 + metadata will render the javadoc based tools obselete, and will make doing the simple J2EE things ( stateless session beans, mdb ) simple as they should be ...

I hope we see WL innovate by providing a comprehensive set of annotations in addition to the standard ones.

It doesn't NEED to be statically typed... If there was a standard facility for querying metadata attributes defined as javadoc, then what would you need this ugly class-like structure for? I liked the ideas behind Commons Attributes, it just never went anywhere. It was going to give you the powerful runtime support for metadata you're looking for without this messed up class-structure-to-create-a-macro thing that is JSR-175.

Make no mistake, although they try to deny it and play down this aspect, what they've really created with JSR-175 are statically typed macros. I asked what one would have to do to implement an Attribute, and was told it would involve creating a code template to be included when the attribute is applied. This is a macro, plain and simple.

Come on Jason, you are being silly now.

Please take a look at what's out there, and more specifically

1) How annotations work on Win32
2) Where and when they are used

Then a lot of JSR 175 will make much more sense to you and you will realize you are missing a huge part of the big picture.

--
Cedric

>>you are missing a huge part of the big picture.
Hear Hear.

Jason, you can start here :
http://tinyurl.com/qwfl

So this is a case of "me too", and we have to do the same thing as .NET did?

That's always been my suspicion about JSR-175....

So how is this silly? I sat in a BOF about JSR-175 and they got VERY defensive when someone asked how this was different from a macro, which makes me think that they KNOW that this is what they've built.

And you should have SEEN some of the horrendous ideas they had as examples... The worst was an example where you tag a field in your class as being an ejb (say something like:

private @ejb(...) service1;

)

and it would then AUTOMATICALLY look it up in JNDI and get the component interface for you! Explain how that's not a macro?

Why the need for meta-data inlining? Why not implement a .meta extension for all class definitions. This would allow for the least amount of instrusiveness with meta data.

Plus, inlining meta-data is a problem in terms of application lifecycle. As an example:

@DataSource(
jndi-name=myDataSource
database=TESTDB
username=myuser
password=mypassword
)

Now, without a variable replace mechanism in a build, you're going to have to do a cut&paste when you move from test>stage>production in your source code. Plus, if you do have development partner relationships with different toolkits, a separate .meta file would isolate problems without impacting the core sources. In addition, it could promote global metadata policies such as the defintion of the DataSource above(it would require an include mechanism). A change in one meta file would assure all dependent classes would be updated.

Yes, I know it would create extra files, but on large projects I think inline meta-data would cause more problems than help.

>Why the need for meta-data inlining? Why not
> implement a .meta extension for all class
> definitions. This would allow for the least
> amount of instrusiveness with meta data.

Because you have to add positional meta-data to your data. For example:

>
>Plus, inlining meta-data is a problem in terms of application lifecycle. As an example:
>
>@DataSource(
> jndi-name=myDataSource
> database=TESTDB
> username=myuser
> password=mypassword
>)
>
You will need to specify where this tag should be applied. Imagine it's a method-level tag, such as "@RemoteMethod". You specify the method name, along with its signature (quite a pain already).

Then one day you refactor, and you have to update your .meta file as well. Which is exactly the problem that XML descriptors have these days: duplication.

Don't violate the DRY principle if you can avoid it (Don't Repeat Yourself).

--
Cedric

>>Because you have to add positional meta-data to your data.

I don't know if this is bad or not. What about

@Remote(
method-name=*
method-name=setXYZ
)

Sort of feels like aspect-oriented meta-data :)

Refactoring is still a pain with this approach, but I'm not sure if inlining meta-data is any more immune to the DRY principle. Refactoring is a pain with or without meta data. Rarely is it benign to the rest of the codebase or build processes. The pain is more manageable with separate .meta files and I think it addresses your concerns with compile time dependencies.

Great topic.

>>So this is a case of "me too", and we have to >>do the same thing as .NET did?

The need for a metadata facility is clear ( look at all the ad-hoc tools )

The .NET design seems sound , and a lot of the usage in the clr class lib is fine.

The JSR guys had a look and made sure we are not missing any major feature ( met attribs , etc )

I _was_ at the BOF you talk about , and had a long talk with the SUN chaps later.

I hate the chosen syntax with the @ notation , but this JSR is a welcome addition.

Regarding the comment about refactoring issues around the annotated code elements. I wonder if there should have been a way to externalize the annotation specification through the use URLs or something like that in the code. It may help with testing or tuning an application during development phases. I guess it depends what the specific annotation is about.

I have heard some talk about ejb descriptors being replaced by annotations in ejb 3.0. If the ejb deployment descriptors are replaced by annotations what would it mean in terms of deployment flexibility now that the code has to recompiled everytime i want to change some annotation based descriptor ?

I guess having a nice IDE environment may make some of this easier to deal with.

My first post in Cedric's weblog. My feeling is that JSR175 is trying to mimic what's done in the .NET platform through Attributes.

To clarify what's happening on .NET:

1. The value of an attribute can be any subclass of System.Attribute.
2. There is a bunch of "generic" subclasses available for you.
3. Attributes can be accessed by using introspection.
4. If you need a custom Attribute, you need to subclass System.Attribute. Any source code that is using that attributes needs the class.

So, to conclude:

a. The JDK should provide a bunch of generic attributes that can be used safely.
b. javac should generate an error if the class of an attribute is missing - mainly because of 3.

My two cents.
Thierry.

Not sure what the bug deal is, really? In most cases the annotations are surely real extensions to the code; they have semantics that usually mean something important, .e.g persistence info, threading info. If you need these features then it implies that you need the tools to build the code. Just accept that your javac compliler is just getting more sophisticated - it has more to do and therefore relies on more libraries. Why is this a issue? Processor cycles are cheap, right? If the tools cause problems when compiling then that's a problem with the tool - not the annotations. The future of software is surely more complex systems - but with the tools to support that complexity - not simpler systems.

How old is this post?