RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Paul Sandoz paul.sandoz at oracle.com
Wed Oct 14 19:36:39 UTC 2015

> On 14 Oct 2015, at 21:12, Steve Drach <steve.drach at oracle.com> wrote:
>>> The current test directory contains binary jar files. In fact in all the test directories, there are 52 binary .jar files.
>> I know but we need to work to remove those.
> I figured that might be the response, but thought it was worth the try ;-)

A reasonable way forward is to go with pre-baked jar files (it’s not making the current situation particular any worse) then lets try and clear up this aspect in a later push, hopefully using a common mechanism that can be used by all such tests that need to construct jar files.

We need a CCC, so i suggest if tests are not ready and approved by the time the CCC is approved then we push what we have.


>>> I added three more.  I thought about generating the jar files but the problem I run into is that there are two test classes that use the same files and creating the files twice seemed to be a bit wasteful.  I couldn’t figure out a reliable way to have one test class create the files and the other one just use the files.
>> I'm not aware of anything in jtreg that would give you the @BeforeSuite-like support. One could use file locks to have it be setup in one place but it's probably more trouble that it is worth. How expensive is it to create them?
> I don’t know, but probably not that expensive, basically for multi-release jar it’s 3 compiles and writing to a jarOutputStream().  I’ll do it.

More information about the core-libs-dev mailing list