Bugzilla – Full Text Bug Listing
| Summary: | [compiler] ClassFormatError caused by abstract static method | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Objectteams | Reporter: | Stephan Herrmann <stephan.herrmann> | ||||||
| Component: | OTJ | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 0.8 | ||||||||
| Target Milestone: | 0.8 M6 | ||||||||
| Hardware: | Other | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 188411 [details]
test & fix
This patch resolves the problem by these steps:
- when generating code for an abstract static role method,
- remove the abstract flag
- generate a method body that throws a RuntimeException
- message send from team to static abstract role method uses
SyntheticRoleBridgeMethodBinding
- create synthetic binding from SourceTypeBinding.resolveTypesFor()
- setup syntheticAccessor in manageSyntheticAccessIfNecessary()
- explicitly pass synthetic arguments from generateCode()
- improve handling of copyInheritanceSrc
- already set MethodBinding.copyInheritanceSrc from AstEdit.addMethod()
which calls resolveTypesFor which needs this field set.
Patch has been committed as r1303, r1304. Apart from an insignificant change in generated SMAPs all tests pass. In the future we might want to look at the general issue of overriding static role methods along implicit inheritance (by what time we should strive to minimize the number of synthetic methods). Core issue is verified using build 201106070730. However, see fups bug 348572 and bug 348574. |
Created attachment 188367 [details] test In OT/J it is possible to declare a method as "abstract static", which is illegal in plain Java. Such a method can be used in two situations: A) bind by a callout binding in the same role class B) implement/bind in an implicit sub-role (if the super-role class is abstract) While A) works fine as demonstrated by CalloutMethodBinding.test3113_calloutToStatic1() B) fails with a ClassFormatError: Method getV in class T1$__OT__R has illegal modifiers: 0x409 (test3113_calloutToStatic3 in the attached patch). Two issues need to be investigated: - why is T1$__OT__R accessed although T2 is instantated (and thus T2$__OT__R) ? - does one of the conflicting modifiers require to be re-coded using a bytecode attribute or should a method body throwing an exception be generated?