Lambda the Ultimate

For instance with EJBs you end up defining special interfaces and writing an xml descriptor file to tell the container and compiler that certain methods are remote and certain methods should be used for container managed persistence. With one particular kind of EJB you end up writing 6 separate files to describe just one component. This is complex and error-prone so people end up using tools like xdoclet which use special tags in your implementation class to generate the other files that are then fed to the compiler.

I'm hoping that Java 1.5 will finally see some movement with regards to shaking up the Java language rather than taking the attitude that it's pretty much perfect and we shouldn't alter it too much because of backwards-compatibility. If generics gets added and some sensible approach to metadata is taken then Java can then whole new abstractions will become significantly easier to express.

Given that there are other languages out there that already implement metadata; what works and what doesn't?

I'm trying to stay open-minded on this topic but 'll confess to an almost instinctive rejection of any solution based on adding javadoc tags. I want my metadata to be something I can have the compiler check up on. I don't want to "deploy and see."

The @deprecated javadoc tag already works this way - it adds a "deprecated" attribute to the method or class definition in the binary class file.

One of the really nice things about C# (and the other dotNET languages ?) is the ability to add user defined attributes to classes and methods and then introspect on them at run-time.

What makes this more useful than just a naming convention is when you're doing work with APIs like EJBs. Currently a developer has to jump through various hoops to provide extra information to a special "ejb compiler" so that it can verify that you have a valid component. This extra information is then used to do things like generate stubs/skeletons for Remote Method Invocation and other container generated classes that wrap around your code and provide features like concurrency management/transaction handling/persistence/etc.

Unfortunately this situation has evolved and grown more complicated over time. For example to define a Container Managed Persistence Entity Bean I have to write the bean implementation class (containing various abstract method definitions for getting/setting properties as well as implementations of all the code that the various interfaces will use), write one or two interface definition files for the business methods (where the actual business logic gets executed) so that the container which of the implementation classes it can expose, write one or two 'home' interface definition files (which acts like a definition of the various 'static' methods for creating, finding and removing instances of this bean from the database), write a descriptor for the component specifying the security restrictions on each method. Then I write one more vendor-specific descriptor detailing the object-relational mapping for the bean's properties to fields in the database.

As you can imagine this is repetitive and error-prone. What they're trying to do with this proposal is to start shifting that kind of semantic meta-information into the source code rather than using tricks like naming conventions, reflection and numerous descriptor files.

As I understand it, the aim is to move the meta-data into the thing it's describing and help the standard java compiler do various sanity checks rather than having individual developers writing their own tools to manage the morass I described above.

I'd say the meta problem though is agreeing on what the meta information should be and how it should be encoded. To be cynical that's the advantage of XML as a "standard", it let's everyone define their own standard by defining their own DTD/Schema but let's them claim to be following a "standard". However, it does have the real advantage that it is easy to modify and evolve. That's what I'd be nervous of wrt adding this info to the source code. Doing that sets it in concrete and how sure are we at the moment that it's going to be correct and describe all we want?

http://www.onjava.com/pub/a/onjava/2002/01/30/xdoclet.html

Hopefully this JSR will end up specifying a mechanism based on JavaDoc rather than new language constructs.

For example one of the interesting things about EJBs is the way in which they separate out certain 'aspects' so that they can be defined declaratively in an XML descriptor file. This theoretically gives an enormous amount of flexibility since the components can be customised without changing the source code.

In practice this flexibility is more often a source of problems than a useful tool. The component usually only works properly with certain sets of metadata but there's no way to enforce this besides writing documentation.

Adding metadata to the language itself might allow a developer to enforce the constraints they want upon the permissible values for this metadata.

Is anyone familiar with how this is done in C#?