[jboss-cvs] JBossAS SVN: r63226 - projects/aop/trunk/aop/docs/reference/reference/en/modules.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon May 28 13:17:24 EDT 2007
Author: flavia.rainone at jboss.com
Date: 2007-05-28 13:17:24 -0400 (Mon, 28 May 2007)
New Revision: 63226
Modified:
projects/aop/trunk/aop/docs/reference/reference/en/modules/jdk14compatibility.xml
Log:
[JBAOP-400] Replaced 1.4 by 1.4.2, and removed commented text.
Modified: projects/aop/trunk/aop/docs/reference/reference/en/modules/jdk14compatibility.xml
===================================================================
--- projects/aop/trunk/aop/docs/reference/reference/en/modules/jdk14compatibility.xml 2007-05-28 11:20:04 UTC (rev 63225)
+++ projects/aop/trunk/aop/docs/reference/reference/en/modules/jdk14compatibility.xml 2007-05-28 17:17:24 UTC (rev 63226)
@@ -1,26 +1,26 @@
<chapter id="jdk14compatibility">
- <title>JDK 1.4 Backwards Compatibility</title>
+ <title>JDK 1.4.2 Backwards Compatibility</title>
<para>
Despite the fact that it has been a while since the release of JDK 5, there are projects
- that still require backwards compatibility with JDK 1.4. This is relatively common, and
+ that still require backwards compatibility with JDK 1.4.2. This is relatively common, and
the reasons for it are diverse.
To deal with this type of requirement, JBoss AOP provides two different solutions. By using
one of them, you can use all features JBoss AOP provides, including annotation-related
- features, and still keep your code backwards compatible with JDK1.4.
+ features, and still keep your code backwards compatible with JDK1.4.2.
</para>
<sect1 id="jdk14-jbossretro" revision="1">
<title>JBoss Retro</title>
<para>
- The first solution to achieve JDK 1.4 backwards compatibility is to use the JBoss Retro
+ The first solution to achieve JDK 1.4.2 backwards compatibility is to use the JBoss Retro
tool. JBoss Retro converts JDK 5 compiled bytecodes into bytecodes that can be
- run using a JDK 1.4 virtual machine.
+ run using a JDK 1.4.2 virtual machine.
</para>
<para>
This tool acts as a bytecode processor, and using it is very simple. You just need to
write your code using JDK 5 constructs and features, and then compile it,
using JDK 5. Next, process the generated bytecodes using
JBoss Retro tool (just like you do when you use aopc compiler), and now your
- bytecodes are ready to run using a JDK 1.4 virtual machine. Notice this solution
+ bytecodes are ready to run using a JDK 1.4.2 virtual machine. Notice this solution
allows not only the use of JBoss AOP annotations, but of most JDK 5 features and
new API operations.
</para>
@@ -84,13 +84,13 @@
[-bytecode]<files>+
</programlisting>
<para>
- JBoss Retro is the de facto standard solution JBoss Group provides to achieve JDK 1.4 backward compatibility.
+ JBoss Retro is the de facto standard solution JBoss Group provides to achieve JDK 1.4.2 backward compatibility.
However, if you do not have the option to compile your code using JDK 5, you should go with the next solution,
the annotation compiler.
</para>
</sect1>
<sect1 id="jdk14-anncompiler" revision="1">
- <title>JDK1.4 Annotation Compiler</title>
+ <title>JDK1.4.2 Annotation Compiler</title>
<para>
Unlike JBoss Retro, the annotation compiler does not support all JDK 5 constructs and new APIs.
Its functionality consists in supporting only annotations, that must be written in the form of doclets.
@@ -142,7 +142,7 @@
<para>
One difference from AOP 1.x is that the interfaces defining the annotations must now extend
<literal>org.jboss.lang.Annotation</literal>, this is because JBoss Retro is now the primary
- mechanism for using annotations in JDK 1.4.
+ mechanism for using annotations in JDK 1.4.2.
</para>
<para>
@@ -470,12 +470,6 @@
<literal>classpathref</literal> and
<literal>verbose</literal> -
These have the same meaning as in the <link linkend="jbossretroparam">JBoss Retro task</link>.
- <!--These are interchangable, and represent the jars needed for the annotation compiler
- to work. The
- <literal>compilerclasspath</literal> version takes the paths of the
- jar files, and the
- <literal>compilerclasspathref</literal> version takes the
- name of a predefined ant path.-->
</listitem>
<listitem>
<literal>bytecode</literal> - The default is false. If true the annotation compiler
@@ -484,16 +478,6 @@
<literal>classpath</literal> or
<literal>classpathref</literal> must be specified.
</listitem>
- <!--<listitem>
- <literal>classpath</literal> or
- <literal>classpathref</literal> - Path to the
- compiled classes to be instrumented with annotations, if
- <literal>bytecode</literal>="true". The
- <literal>classpath</literal>
- version takes the path of the directory, and the
- <literal>classpathref</literal>
- version takes the name of a predefined ant path.
- </listitem> -->
<listitem>
<literal>xml</literal> - Default is false. If true an xml file is generated
containing information of how to attach the annotations at a later stage in
@@ -506,10 +490,6 @@
name is
<literal>metadata-aop.xml</literal>
</listitem>
-<!-- <listitem>
- <literal>verbose</literal> - Default is false. If true, verbose output
- is generated, which comes in handy for diagnosing unexpected results.
- </listitem>-->
</itemizedlist>
You cannot currently specify both
<literal>bytecode</literal> and
More information about the jboss-cvs-commits
mailing list