[MRJAR] Entry order matters?

[Claes Redestad]

This appears to be caused by a bug I inadvertently introduced in a
startup optimization a while back; patch and extended tests are up for
review on core-libs-dev:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043476.html

Thanks!

/Claes

On 2016-09-08 22:15, Robert Scholte wrote:
> Confirmed there's an issue; jar should have been recognized as a
> multirelease jar.
>
> https://bugs.openjdk.java.net/browse/JDK-8165723
>
>
> thanks,
> Robert
>
> On Mon, 05 Sep 2016 09:10:56 +0200, Alan Bateman
> <Alan.Bateman at oracle.com> wrote:
>
>>
>>
>> On 04/09/2016 21:56, Robert Scholte wrote:
>>> :
>>>
>>>> Also if you "unzip <jar>  -d <somedir>" then does everything look okay?
>>>>
>>>
>>> hboutemy    $ unzip -t multirelease-0.8-SNAPSHOT_failure.jar | grep
>>> class
>>> hboutemy     testing: base/Base.class OK
>>> hboutemy     testing: META-INF/versions/9/mr/A.class OK
>>> hboutemy     testing: META-INF/versions/8/mr/A.class OK
>>> hboutemy     testing: mr/A.class OK
>>> hboutemy    $ unzip -t multirelease-0.8-SNAPSHOT_success.jar | grep
>>> class
>>> hboutemy     testing: base/Base.class OK
>>> hboutemy     testing: META-INF/versions/8/mr/A.class OK
>>> hboutemy     testing: mr/A.class OK
>>> hboutemy     testing: META-INF/versions/9/mr/A.class OK
>>>
>>> Looks good to me.
>> I think I need to see multirelease-0.8-SNAPSHOT_failure.jar to
>> understand this as I suspect there is more going on that is obvious
>> here. I'll see if I can duplicate it.
>>
>> -Alan