[stefanegli]

Beautiful, trunk works again! Thanks for that quick fix!

PS: Bummer that one can't instrument java.lang.Thread... wanted to trace Thread-creation but I guess it would be hard to support java.lang stuff.. :)

Cheers,
Stefan

[adinn]

Beautiful, trunk works again! Thanks for that quick fix!

No problem. Thank you for the bug report and keep em coming.

PS: Bummer that one can't instrument java.lang.Thread... wanted to trace Thread-creation but I guess it would be hard to support java.lang stuff.. :)

No, it is not hard to do so -- in the sense that my code is not built around the assumption that the transformed class is not in java.lang.* It' was actually a rather arbitrary decision on my part to exclude java.lang yet allow transforms for anything else (Byteman classes aside). If you tread very carefully you can probably get away with redefining code in this java.lang -- for example, I am pretty sure it will be safe to trace Thread creation.

Conversely, if you tread at all carelessly you can very easily screw up bigtime when you redefine code in other java.xxx classes. For example, I mistakenly modified your trace rule on File.exists to call traceln("ot", "..") when I really meant to supply String "out" as the first argument -- identifying System.out. This led to a recursive call to File.exists when it tried to open a trace file with key "ot". The resulting stack overflow crashed JVM startup with a segmentation error and no clear explanation of why it was happening. So even as is you need to exercise care.

The java.lang restriction is actually very simple to remove. If you want to try out injection into java.lang (and live with the consequences) all you need to do is modify method Transformer.isTransformable() so that it returns true when passed a classname that you are happy to inject code into. Currently this method returns false if the class name starts with the string "java.lang." and true otherwise.

This could easily be made configurable so as to make it more or less forgiving e.g. instead of using this fixed String it could check for a System property (or properties) which identified patterns for class names to exclude (and/or include). If you would find such a feature useful raise a JIRA (or post a note to the design forum) and I will be happy to add this feature.

[stefanegli]

I actually did try fiddling that isTransformable() method and my debug output would just now show up. ... when I realized that I didn't have debug set to true :)