From: ehilsdal Date: Tue, 2 Dec 2003 19:49:16 +0000 (+0000) Subject: Fix for Bugzilla 42663: doc implications of Foo.class X-Git-Tag: mostlyLastEclipse2xTree_20040112~39 X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=8599351489cb15cb93a960f222845509f311345a;p=aspectj.git Fix for Bugzilla 42663: doc implications of Foo.class * added note about String+ and Foo.class to implementation notes section --- diff --git a/docs/progGuideDB/implementation.xml b/docs/progGuideDB/implementation.xml index 314c574f9..fcf05583a 100644 --- a/docs/progGuideDB/implementation.xml +++ b/docs/progGuideDB/implementation.xml @@ -117,6 +117,48 @@ Bytecode Notes + + The .class expression and String + + + The java language form Foo.class is + implemented in bytecode with a call to + Class.forName guarded by an exception + handler catching a ClassNotFoundException. + + + The java language + operator, when applied to String + arguments, is implemented in bytecode by calls to + StringBuffer.append. + + + In both of these cases, the current AspectJ compiler + operates on the bytecode implementation of these language + features; in short, it operates on what is really happening rather + than what was written in source code. This means that there may + be call join points to Class.forName or + StringBuffer.append from programs that do not, + at first glance, appear to contain such calls: + + + + + In short, the join point model of the current AspectJ + compiler considers these as valid join points. + + + + + + The Handler join point + + The end of exception handlers cannot reliably be found in Java bytecode. Instead of removing the handler join point entirely, the current AspectJ compiler restricts what can be done with the handler @@ -173,6 +215,8 @@ will likely have fewer such restrictions. + +