Message-ID: <1897760452.2859.1369328116203.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2858_1733483722.1369328116203" ------=_Part_2858_1733483722.1369328116203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
JAM is an object model for Java types and their associated annotations. = It provides a superset of the features offered by similar APIs (such as Ref= lection or X/Javadoc). It is also designed from the ground-up to be extrem= ely extensible - you can write a JAM plugin which can easily build up a des= cription of Java types using whatever information you happen to have availa= ble about them.
JAM is being developed and distributed as a module within Annogen. JAM = is merely one of several such APIs which JAM supports. JAM has no dependen= cies on Annogen, though Annogen does have a few dependencies on JAM (primar= ily for code generation).
Yes. JAM is developed and distributed as a part of Annogen, but it is u= seful in its own right.
Right here: JAM API Javadocs
One thing JAM provides is a nice, clean, consistent, singly-rooted class= hierarchy for describing Java types (e.g. parameters are first-class citiz= ens of the model).
It also gives you a unified API whether you are dealing with source file= s or class files. This can be very helpful if your application cares about= source artifacts which are lost after compilation, such as comments.
JAM creates an insulating layer between your code and the real artifacts= which describe the java types your code needs to view. The JAM API was de= signed from the ground up to allow you to write code that is completely <= ;i>artifact agnostic</i> when inspecting java types. That is to s= ay, JAM provides a set of abstractions which isolate your java type-inspect= ing code from the files that it is actually looking at. This means that y= ou get a single API with which you can view java sources and classfiles.
For example, a given instance of JClass (JAM's abstract representation o= f a Java class) may in reality represent the contents of either a .cla= ss file or its corresponding .java source file. However, the= JClass that your code sees looks exactly the same in either case. Without= JAM, you may have to write your code twice using two separate APIs like Ja= vadoc and Reflection. With JAM, your code more able to focus on the logic = that is central to your application.
However, the advantages of JAM's beansed design extend far beyond simply= providing a unified view of java source- and classfiles. This is because = JAM allows you to write your own extensions which customize the proxies tha= t it creates. With this extension mechanism, you can easily add, modify, o= r remove any part of a beaning built.
For example, you could write an extension which adds a default comment t= o uncommented methods on a given JClass. With such an extension in place, = JClasses loaded by JAM will contain your generated comments exactly as if they had actually been in the source file all along.
Even though this is an extremely simple example, consider how much troub= le it might save you in a complex application composed of serveral subsyste= ms. Say that those subsystems who ask each other to do things using java t= ypes that they pass around, and that we need them to use default comments. = If we don't have JAM, we're going to have to write special logic in each s= ubsystem to generate default comments when appropriate. However, with JAM,= we only have to write one bit of code that weaves those comments into out = proxied view of the Java classes. Those subsytems that are consuming this = view need be none the wiser.------=_Part_2858_1733483722.1369328116203--