RFR : JDK-8009162: "make test" target change

Martin Buchholz martinrb at google.com
Tue Mar 5 14:04:47 PST 2013


Historically, developers have always developed shortcuts to speed up their
own personal edit-compile-test cycle and the build system should support
that as well as it can, without making it too error-prone.

Ideally, the build system should never have to use the classes directory
hack, which is only for developer performance.  If only one java source
file was modified, the images rt.jar  could be updated with the compilation
results without rebuilding the rest of images.  But that's quite difficult
to get right.  "jar u" could perhaps be optimized with low-level hacks.

Also historically, the build system was very unreliable about failing to
pick up changes in an incremental rebuild.

Anyways, enough hard problems to keep y'all employed!

Martin

On Tue, Mar 5, 2013 at 1:14 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> We could certainly make test depend upon images. I considered but did not
> implement  this because I imagined that doing so would result in inevitable
> complaints about overhead and/or unwanted building. On my system an images
> target rebuild with no work takes only 1 second. Probably more on a non SSD
> system but it seems like a worthwhile cost.
>
> Dissent? It sounds like Martin and Alan are in favour....
>
> Mike
>
> On Mar 5 2013, at 13:06 , Alan Bateman wrote:
>
>  On 05/03/2013 20:58, Martin Buchholz wrote:
>
>
>
> On Tue, Mar 5, 2013 at 5:37 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
>
>>
>>>
>>>  it make sense to default to the JDK image.
>
>
>  This introduces a new problem, where a developer will build and test,
> but because the lazy developer did not build images, the wrong bits get
> tested.
>
>  Either fully support testing with non-images, or do not.
> If non-images are fully supported, then tests should run against images by
> default, but only if they have been built more recently than the classes/
> dir.
>
>  If the shiny new build system is smart enough, it could efficiently
> check whether images is up to date before testing with them, and so if
> requesting testing with images, they will never be stale bits.
>
> With the existing test/Makefile then you can specify PRODUCT_HOME=<jdk> to
> make and it will run the tests on that.
>
> For the new build then I completely agree that the test target should
> depend on images, at least if it's going to test the JDK image but there
> will be cases where you want to test a different build. There were a few
> attempts to start a discussion on this a few months ago on build-infra-dev
> but it wasn't the right time so the discussion didn't go very far.
>
> -Alan.
>
>
>


More information about the jdk8-dev mailing list