I put some checks back in which I commented out while there was a problem with BCEL
check for assignment compatibility (which was rooted someplace else).
However, this could cause JustIce to reject code that's not rejected by traditional
verifiers.
I got a bug report today from a person who found a class that was rejected by a traditional
verifier but not by JustIce - which is even more annoying. So I switched. See TODO.JustIce .
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/bcel/trunk@152749 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/TODO.JustIce b/TODO.JustIce
index 65ebef1..d6f4373 100644
--- a/TODO.JustIce
+++ b/TODO.JustIce
@@ -5,7 +5,15 @@
- JustIce uses object generalization during pass 3b, as supposed by
Sun. However, there are better methods such as the idea proposed by
-Staerk et al.: using sets of object types.
+Staerk et al.: using sets of object types. JustIce may reject code
+that is not rejected by traditional JVM-internal verifiers for this
+reason. The corresponding checks all have some "TODO" tag with an
+explanation; they're all in the 'InstConstraint.java' file. Users
+encountering problems should simply comment them out (or uncomment
+them) as they like. The default is some setting that works well
+when using 'java org.apache.bcel.verifier.TransHull java.lang.String'
+- that is, there are no rejects caused by the above problem in a lot
+of usual classes.
- There are a few bugs concerning access rights of referenced methods
and probably fields. The tests for access rights that Sun defines