Remove JRockit LTW support, particularly JRockitAgent

In two places, the documentation now contains this text:

"Since AspectJ 1.9.7, the obsolete Oracle/BEA JRockit agent is no longer
part of AspectJ. JRockit JDK never supported Java versions higher than
1.6. Several JRockit JVM features are now part of HotSpot and tools like
Mission Control available for OpenJDK and Oracle JDK."

The decision to drop JRockit support was made during a discussion
between Alexander Kriegisch and Andy Clement:

Andy Clement wrote on 26 Mar 2021:

> Yes I think so.
>
>
> Alexander Kriegisch wrote on 26 Mar 2021:
>
>> https://en.wikipedia.org/wiki/JRockit
>>
>> Can we get rid of that? AspectJ requires Java 8, JRockit never
>> supported more than Java 6.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

1 files changed, 70 insertions, 68 deletions

diff --git a/docs/devGuideDB/ltw.xml b/docs/devGuideDB/ltw.xml
index 3d8723662..bc5aac769 100644
--- a/docs/devGuideDB/ltw.xml
+++ b/docs/devGuideDB/ltw.xml
@@ -1,23 +1,23 @@
 <chapter id="ltw" xreflabel="Load-Time Weaving">
     <title>Load-Time Weaving</title>
-    
+
     <sect1 id="ltw-introduction">
         <title>Introduction</title>
-        
+
         <para> The AspectJ weaver takes class files as input and produces class files as output.
             The weaving process itself can take place at one of three different times: compile-time,
             post-compile time, and load-time. The class files produced by the weaving process (and
             hence the run-time behaviour of an application) are the same regardless of the approach
             chosen. </para>
-            
+
         <itemizedlist>
             <listitem> <para>Compile-time weaving is the simplest approach. When you have the source code
                 for an application, ajc will compile from source and produce woven class files as
                 output. The invocation of the weaver is integral to the ajc compilation process. The
-                aspects themselves may be in source or binary form. 
+                aspects themselves may be in source or binary form.
                 If the aspects are required for the affected classes to compile, then
                 you must weave at compile-time.  Aspects are required, e.g., when they
-                add members to a class and other classes being compiled reference the 
+                add members to a class and other classes being compiled reference the
                 added members.
                 </para></listitem>
             <listitem> <para>Post-compile weaving (also sometimes called binary weaving) is used to weave
@@ -29,32 +29,32 @@
                 one or more "weaving class loaders", either provided explicitly by the run-time
                 environment or enabled through a "weaving agent" are required. </para></listitem>
         </itemizedlist>
-        
+
         <para> You may also hear the term "run-time weaving". We define this as the weaving of
             classes that have already been defined to the JVM (without reloading those
             classes). AspectJ 5 does not provide explicit support for run-time weaving although
             simple coding patterns can support dynamically enabling and disabling advice in aspects. </para>
-        
+
         <sect2 id="weaving-class-files-more-than-once" xreflabel="weaving-class-files-more-than-once">
             <title>Weaving class files more than once</title>
-        
+
             <para> As of AspectJ 5 aspects (code style or annotation style) and woven classes are
-            	reweavable by default. If you are developing AspectJ applications that are to be used 
+            	reweavable by default. If you are developing AspectJ applications that are to be used
             	in a load-time weaving environment with an older version of the compiler you
                 need to specify the <literal>-Xreweavable</literal> compiler option when building
                 them. This causes AspectJ to save additional state in the class files that is used
                 to support subsequent reweaving. </para>
         </sect2>
     </sect1>
-    
+
     <sect1 id="ltw-rules">
         <title>Load-time Weaving Requirements</title>
-    
+
         <para> All load-time weaving is done in the context of a class loader, and hence the set of
             aspects used for weaving and the types that can be woven are affected by the class
             loader delegation model. This ensures that LTW complies with the Java 2 security model.
             The following rules govern the interaction of load-time weaving with class loading: </para>
-    
+
         <orderedlist>
             <listitem> <para>All aspects to be used for weaving must be defined to the weaver before any
                 types to be woven are loaded.  This avoids types being "missed" by aspects added
@@ -66,19 +66,19 @@
                 may be extended.
             </para></listitem>
             <listitem><para>A class loader may only weave classes that it defines. It may not weave
-                classes loaded by a delegate or parent class loader.</para></listitem>    
+                classes loaded by a delegate or parent class loader.</para></listitem>
         </orderedlist>
-        
+
     </sect1>
-    
+
     <sect1 id="ltw-configuration">
         <title>Configuration</title>
         <para>New in AspectJ 5 are a number of mechanisms to make load-time weaving
-        easy to use. The load-time weaving mechanism is chosen through JVM startup options. 
-        Configuration files determine the set of aspects to be used for weaving and which 
-        types will be woven. Additional diagnostic options allow the user to debug the configuration and 
+        easy to use. The load-time weaving mechanism is chosen through JVM startup options.
+        Configuration files determine the set of aspects to be used for weaving and which
+        types will be woven. Additional diagnostic options allow the user to debug the configuration and
         weaving process. </para>
-        
+
         <sect2 id="enabling-load-time-weaving" xreflabel="enabling-load-time-weaving">
             <title>Enabling Load-time Weaving</title>
             <para> AspectJ 5 supports several ways of enabling load-time weaving for
@@ -88,15 +88,16 @@
                 <varlistentry>
                     <term>Agents</term>
                     <listitem>
-                        <para>AspectJ 5 ships with a number of load-time weaving agents that
-                            enable load-time weaving. These agents and their configuration
-                            are execution environment dependent. Configuration for the supported environments is discussed
+                        <para>AspectJ 5 ships with a load-time weaving agent that
+                            enables load-time weaving. This agent and its configuration
+                            is execution environment dependent. Configuration for the supported environments is discussed
                             later in this chapter.</para>
                             <para>
                             Using Java 5 JVMTI you can specify the <literal>-javaagent:pathto/aspectjweaver.jar</literal> option
                             to the JVM.</para><para>
-                            Using BEA JRockit and Java 1.3/1.4, the very same behavior can be obtained using BEA JRockit JMAPI features with
-                            the <literal>-Xmanagement:class=org.aspectj.weaver.loadtime.JRockitAgent</literal>
+                            Since AspectJ 1.9.7, the obsolete Oracle/BEA JRockit agent is no longer part of AspectJ.
+                            JRockit JDK never supported Java versions higher than 1.6. Several JRockit JVM features are
+                            now part of HotSpot and tools like Mission Control available for OpenJDK and Oracle JDK.
                         </para>
                     </listitem>
                 </varlistentry>
@@ -104,12 +105,12 @@
                     <term>Command-line wrapper scripts <literal>aj</literal></term>
                     <listitem>
                         <para>The <command>aj</command> command runs Java programs in Java 1.4 or
-                        later by setting up <literal>WeavingURLClassLoader</literal> as the 
-                            system class loader.  
+                        later by setting up <literal>WeavingURLClassLoader</literal> as the
+                            system class loader.
                             For more information, see <xref linkend="aj"/>.
                         </para>
                         <para>The <command>aj5</command> command runs Java programs in Java 5
-                        by using the <literal>-javaagent:pathto/aspectjweaver.jar</literal> option 
+                        by using the <literal>-javaagent:pathto/aspectjweaver.jar</literal> option
                             described above.
                             For more information, see <xref linkend="aj"/>.
                         </para>
@@ -132,10 +133,10 @@
                 </varlistentry>
             </variablelist>
         </sect2>
-        
+
         <sect2 id="configuring-load-time-weaving-with-aopxml-files" xreflabel="configuring-load-time-weaving-with-aopxml-files">
             <title>Configuring Load-time Weaving with aop.xml files</title>
-            
+
             <para>The weaver is configured using one or more <literal>META-INF/aop.xml</literal>
                 files located on the class loader search path. Each file may declare a list of
                 aspects to be used for weaving, type patterns describing which types
@@ -187,16 +188,16 @@
               <!-- Dump all types within the "com.foo.bar" package and sub-packages,
                    both before are after they are woven,
                    which can be used for byte-code generated at runtime
-              <dump within="com.foo.bar..*" beforeandafter="true"/> 
+              <dump within="com.foo.bar..*" beforeandafter="true"/>
             </weaver>
 
           </aspectj>
 
 		  ]]></programlisting>
-          
+
             <para>
-                The DTD defining the format of this file is available here: 
-                http://www.eclipse.org/aspectj/dtd/aspectj.dtd. 
+                The DTD defining the format of this file is available here:
+                http://www.eclipse.org/aspectj/dtd/aspectj.dtd.
             </para>
             <para>
                 An aop.xml file contains two key sections: <literal>aspects</literal> defines one
@@ -204,15 +205,15 @@
                 used in the weaving process; <literal>weaver</literal> defines weaver options and which
                 types should be woven.
             </para>
-            
+
             <para>
-                The simplest way to define an aspect to the weaver is to 
-                specify the fully-qualified name of the aspect type in an aspect element. 
+                The simplest way to define an aspect to the weaver is to
+                specify the fully-qualified name of the aspect type in an aspect element.
                 You can also
                 declare (and define to the weaver) aspects inline in the aop.xml file.
                 This is done using the <literal>concrete-aspect</literal> element. A concrete-aspect
-                declaration must provide a pointcut definition for every abstract 
-                pointcut in the abstract aspect it extends. This mechanism is a 
+                declaration must provide a pointcut definition for every abstract
+                pointcut in the abstract aspect it extends. This mechanism is a
                 useful way of externalizing configuration for infrastructure and
                 auxiliary aspects where the pointcut definitions themselves can be
                 considered part of the configuration of the service.
@@ -229,15 +230,15 @@
                 and || are replaced by 'AND' and 'OR'.
             </para>
             <para>
-                Note that <literal>include</literal> and <literal>exclude</literal> elements affect all aspects 
-                declared to the weaver including those in other aop.xml files. To help avoid unexpected 
+                Note that <literal>include</literal> and <literal>exclude</literal> elements affect all aspects
+                declared to the weaver including those in other aop.xml files. To help avoid unexpected
                 behaviour a lint warning is issued
                 if an aspect is not declared as a result of of applying these filters.
                 Also note <literal>aspect</literal> and <literal>concrete-aspect</literal> elements
                 must be used to declare aspects to the weaver i.e. <literal>include</literal> and <literal>exclude</literal>
                 elements cannot be used find aspects on the class loader search path.
             </para>
-            
+
             <para>
                 The <literal>weaver</literal> element is used to pass options to the weaver and to specify
                 the set of types that should be woven. If no include elements are specified
@@ -245,10 +246,10 @@
                 element can be used capture on disk byte-code of woven classes for diagnostic purposes both before,
                 in the case of those generated at runtime, and after the weaving process.
             </para>
-          
-          
+
+
             <para> When several configuration files are visible from a given weaving class loader
-                their contents are conceptually merged. 
+                their contents are conceptually merged.
                 The files are merged in the order they are
                 found on the search path (with a regular <literal>getResourceAsStream</literal> lookup)
                 according to the following rules: </para>
@@ -263,7 +264,7 @@
                     by any exclude statements. If there are no include statements then all non-excluded
                     aspects are included.</para></listitem>
                 <listitem> <para> The set of types to be woven are those types matched by at
-                    least one weaver <literal>include</literal> element and not matched by any 
+                    least one weaver <literal>include</literal> element and not matched by any
                     weaver <literal>exclude</literal> element. If there are no weaver include
                     statements then all non-excluded types are included.</para></listitem>
                 <listitem> <para> The weaver options are derived by taking the union of the
@@ -272,19 +273,19 @@
                     will be used.</para></listitem>
             </itemizedlist>
 
-            <para>It is not an error for the same aspect to be defined to the weaver in 
-                more than one visible <literal>META-INF/aop.xml</literal> file. 
+            <para>It is not an error for the same aspect to be defined to the weaver in
+                more than one visible <literal>META-INF/aop.xml</literal> file.
                 However, if the same concrete aspect
                 is defined in more than one aop.xml file then an error will be issued.
-                A concrete aspect 
+                A concrete aspect
                 defined in this way will be used to weave types loaded by the
-                class loader that loaded the aop.xml file in which it was defined. 
+                class loader that loaded the aop.xml file in which it was defined.
                 </para>
-            
+
             <para> A <literal>META-INF/aop.xml</literal> can be generated by
-                using either the <literal>-outxml</literal> or <literal>-outxmlfile</literal> options of the AspectJ compiler. 
+                using either the <literal>-outxml</literal> or <literal>-outxmlfile</literal> options of the AspectJ compiler.
                 It will simply contain a (possibly empty) set of aspect elements; one for
-                each abstract or concrete aspect defined. 
+                each abstract or concrete aspect defined.
                 When used in conjuction with the <literal>-outjar</literal> option
                 a JAR is produced that can be used
                 with the <command>aj5</command> command or a load-time weaving environment.</para>
@@ -333,7 +334,7 @@
             ]]></programlisting>
             <para>
                 This aspect (in either style) can be made concrete using <literal>META-INF/aop.xml</literal>.
-                It defines the abstract pointcut <literal>scope()</literal>. When using this mechanism the 
+                It defines the abstract pointcut <literal>scope()</literal>. When using this mechanism the
                 following rules apply:
                 <itemizedlist>
                     <listitem><para>The parent aspect must be abstract. It can be an @AspectJ or a
@@ -343,17 +344,17 @@
                             as illustrated in this sample, this means the method that hosts the pointcut must be abstract,
                             have no arguments, and return void.</para></listitem>
                     <listitem><para>The concrete aspect must implement all inherited abstract pointcuts.</para></listitem>
-                    <listitem><para>The concrete aspect may not implement methods so the abstract aspect it 
+                    <listitem><para>The concrete aspect may not implement methods so the abstract aspect it
                             extends may not contain any abstract methods.</para></listitem>
                 </itemizedlist>
             </para>
-		
+
             <para>
 		        <emphasis>A limitation of the implementation of this feature in AspectJ 1.5.0 is that aspects defined using
 		        aop.xml are not exposed to the weaver. This means that they are not affected by advice and ITDs defined in
 		        other aspects. Support for this capability will be considered in a future release.</emphasis>
             </para>
-                
+
             <para>
                 If more complex aspect inheritance is required use regular aspect
                 inheritance instead of XML.
@@ -456,7 +457,7 @@
                             <entry>
                                 <literal>-verbose</literal>
                             </entry>
-                            <entry>Issue informational messages about the weaving process. Messages issued while the weaver is being 
+                            <entry>Issue informational messages about the weaving process. Messages issued while the weaver is being
                                    bootstrapped are accumulated until all options are parsed. If the messages are required to be output
                                    immediately you can use the option <literal>-Daj.weaving.verbose=true</literal> on the JVM startup command line.
                             </entry>
@@ -466,11 +467,11 @@
                                 <literal>-debug</literal>
                             </entry>
                             <entry>
-                            	Issue a messages for each class passed to the weaver 
-                            	indicating whether it was woven, excluded or ignored. 
+                            	Issue a messages for each class passed to the weaver
+                            	indicating whether it was woven, excluded or ignored.
                             	Also issue messages for classes
                             	defined during the weaving process such as around advice
-                            	closures and concrete aspects defined in 
+                            	closures and concrete aspects defined in
                             	<literal>META-INF/aop.xml</literal>.
                             </entry>
                         </row>
@@ -542,7 +543,7 @@
                             The given value must be the full qualified class name of a class that implements the
                             <literal>org.aspectj.bridge.IMessageHandler</literal> interface
                             and is visible to the classloader with which the weaver being configured is associated.
-                            Exercise caution when packaging a custom message handler with an application that is to 
+                            Exercise caution when packaging a custom message handler with an application that is to
                             be woven. The handler (as well as classes on which it depends) cannot itself be woven
                             by the aspects that are declared to the same weaver.
                             </entry>
@@ -556,7 +557,7 @@
     <sect1 id="ltw-specialcases">
         <title>Special cases</title>
         <para>
-            The following classes are not exposed to the LTW infrastructure regardless of 
+            The following classes are not exposed to the LTW infrastructure regardless of
             the <literal>aop.xml</literal> file(s) used:
             <itemizedlist>
                 <listitem> <para>All <literal>org.aspectj.*</literal> classes (and subpackages) - as those are needed by the infrastructure itself</para></listitem>
@@ -578,14 +579,14 @@
             won't be handled as a warn (as during compile time) but as an info message.
         </para>
     </sect1>
-    
+
     <sect1 id="ltw-packaging">
         <title>Runtime Requirements for Load-time Weaving</title>
         <para> To use LTW the <literal>aspectjweaver.jar</literal> library must be added to the
             classpath. This contains the AspectJ 5 runtime, weaver, weaving class loader and
             weaving agents. It also contains the DTD for parsing XML weaving configuration files. </para>
     </sect1>
-    
+
     <sect1 id="ltw-agents">
         <title>Supported Agents</title>
         <sect2 id="jvmti" xreflabel="jvmti">
@@ -598,10 +599,11 @@
         </sect2>
         <sect2 id="jrockit" xreflabel="jrockit">
             <title>JRockit with Java 1.3/1.4 (use JVMTI on Java 5)</title>
-            <para> The JRockit agent is configured with the following JVM option: </para>
-            <programlisting><![CDATA[
-			-Xmanagement:class=org.aspectj.weaver.loadtime.JRockitAgent
-		  ]]></programlisting>
+            <para>
+                Since AspectJ 1.9.7, the obsolete Oracle/BEA JRockit agent is no longer part of AspectJ.
+                JRockit JDK never supported Java versions higher than 1.6. Several JRockit JVM features are
+                now part of HotSpot and tools like Mission Control available for OpenJDK and Oracle JDK.
+            </para>
         </sect2>
     </sect1>
 </chapter>