[ https://issues.apache.org/jira/browse/HARMONY-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Cornwall updated HARMONY-5654:
-------------------------------------
Attachment: pack200.pack.gz
pack200.pack.gz data which leads to synchronized <init> method
> [classlib][pack200] Init methods cannot be synchronized
> -------------------------------------------------------
>
> Key: HARMONY-5654
> URL: https://issues.apache.org/jira/browse/HARMONY-5654
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: All pack200
> Reporter: Andrew Cornwall
> Attachments: pack200.pack.gz
>
>
> In the current code, it's possible for a CPMethod <init> to be emitted as synchronized.
This will not pass Sun's verification. For instance, if you run pack200 on itself, NewAttributeBands$LayoutElement
in the following will be emitted with a synchronized <init>.
> I've temporarily hacked this with the following code in CPMethod:
> public CPMethod(CPUTF8 name, CPUTF8 descriptor, long flags, List attributes) {
> // TODO Check that we only pass these on, or remap
> super(name, descriptor, 0x7FFF & flags, attributes);
> if(name.underlyingString().equals("<init>")) {
> // hack hack - init should never be synchronized
> SegmentUtils.debug("Hacking off synchronized on an init method");
> this.flags = (short)(this.flags & 0x7FDF);
> }
> }
> but I really need to look into it more deeply and find out why the 0x20 flag is being
passed in. (This may end up being an encoding issue, but I need to look more first).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
|