Lambda the Ultimate

inactiveTopic (JSR 175) Adding metadata to Java
started 3/27/2002; 4:05:54 PM - last post 4/1/2002; 3:15:35 PM
Adewale Oshineye - (JSR 175) Adding metadata to Java  blueArrow
3/27/2002; 4:05:54 PM (reads: 2363, responses: 6)
This JSR (led Joshua Bloch, author of Effective Java and large parts of Java's Collections API) plans to add the ability to add metadata to the java language. Basically this is because there are far too many java APIs that have ended up with complex XML and reflecton based mechanisms for metadata.

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."

nickmain - Re: (JSR 175) Adding metadata to Java  blueArrow
3/27/2002; 7:00:31 PM (reads: 2440, responses: 0)
Given that the Java Class File format is user extensible (a JVM is supposed to ignore any named attributes it doesn't understand) implementing this should be a no-brainer.

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.

Ehud Lamm - Re: (JSR 175) Adding metadata to Java  blueArrow
3/28/2002; 9:49:21 AM (reads: 2433, responses: 0)
Is this anything more than a naming convention? I am not sure I fully understand what's this about.

Adewale Oshineye - Re: (JSR 175) Adding metadata to Java  blueArrow
3/28/2002; 12:13:51 PM (reads: 2423, responses: 0)
As far as I see it, this is the first step on the road to making aspects part of the language.

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.

Alex Moffat - Re: (JSR 175) Adding metadata to Java  blueArrow
3/29/2002; 2:06:30 PM (reads: 2408, responses: 0)
The attributes stuff mentioned by nickmain is more than just a naming convention to the extent that the java class file format provides for various attribute "structures" associated with methods etc. as they are represented in the class file. For instance a java method must have a "Code" attribute where the byte code for the method is stored. You could certainly add a "Metadata" attribute to a class file and store whatever you wanted in it. JVMs that don't understand an attribute must ignore it.

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?

nickmain - Re: (JSR 175) Adding metadata to Java  blueArrow
3/29/2002; 11:57:45 PM (reads: 2422, responses: 1)
The XDoclet tool allows EJB descriptors to be generated from custom JavaDoc tags:

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

Adewale Oshineye - Re: (JSR 175) Adding metadata to Java  blueArrow
4/1/2002; 3:15:35 PM (reads: 2357, responses: 0)
The Server Side is another site where people have begun discussing some of the ramifications of this idea ( They've raised some interesting issues.

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#?