Community
Participate
Working Groups
If a source file is using the new assert statement, the code generation makes it incompatible with VMs older than 1.4 VMs. We might want to keep this binary compatibility considering that older VMs should simply run these .class files as a 1.4 VM would do with assertion disabled. This means we would silently ignore the exceptions thrown if fields, methods or classes used to manage the assert statement are not present. According to the specs, Java platform implementors are under no obligation to do this. We might consider adding a support for that.
This would though mean we'd wrap assertions in try/catch statements during code gen... Maybe we could rather use the -target VM_version to tell us whether or not to use reflect or direct 1.4 lib access when generating bytecodes for an assert statement.
Exactly. We would use reflection to retrieve the java.lang.AssertionError class and try/catch to handle invalid accesses to missing fields or methods. This is easily doable with the current API. The change would be very local to the AssertStatement code generation.
Nice to have, but we shouldn't pollute the normal codegen to support this scenario, unless it becomes critical that we support it.
*** Bug 13976 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
