Backport proposal of the Marlin renderer in OpenJDK8

[Andrew Brygin]

Hello Laurent,

 thank you for your great work on the Marlin renderer.

 As you know we (Azul) have already integrated Marlin into
 Zulu 8, we are ready to help with the integration into OpenJDK 8.

>> Finally I still wonder how to deal with the former classes (RenderingEngine
>> conflict). How did you handle this aspect in the zulu codebase ?

 In Zulu8 we have updated the rendering engine selection in order to use
 Marlin by default. However, we have preserved the Pisces renderer just
 in case if somebody wants to use it, and uses sun.java2d.renderer property
 to specify Pisces explicitly.

 We have registered Marlin renderer as a service in
 src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine
 in order to make it available via ServiceLoader machinery.

 We will be happy to share our patches, as well as test and review the integration.

Thanks,
Andrew

> On Sep 11, 2019, at 6:41 PM, Mario Torre <neugens.limasoftware at gmail.com> wrote:
> 
> I suggest to do what we are doing for JFR, which means the project
> lead created a repository for us where we are merging individual bugs
> (and adding new where necessary, like minor fixes only applicable to
> 8u), with every commit accompanied by the relative bug id. Once
> everything is done, you can propose the whole batch for integration.
> We also mark individual bugs in Jira for the back port with a special
> label, so they should be easier to track.
> 
> As for who approves the patches, ideally you want to have a reviewer
> working with you, but for the staging repository you don't strictly
> need it since its purpose is obviously to get the patches back ported
> and the assumption is that you are the original author so you know
> best ;)
> 
> Once everything is ready, a reviewer will go through the patches (or
> the big patch) and approve it (or not!).
> 
> Cheers,
> Mario
> 
> Il giorno mer 11 set 2019 alle ore 16:51 Laurent Bourgès
> <bourges.laurent at gmail.com> ha scritto:
>> 
>> Hi,
>> 
>> I am wondering how to start with such big backport.
>> - list all original patches among 9 to 14 repositories (=11u as I
>> backported few changes already)
>> - use my github fork of jdk8u_jdk or stay on mercurial but a new
>> jdk8u_marlin forrest should be created ?
>> - identify interested people (azul, adoptopenjdk, amazon) to build a tiger
>> team to start the concrete work
>> - who can sponsor (committer) / review these patches ?
>> 
>> Finally I still wonder how to deal with the former classes (RenderingEngine
>> conflict). How did you handle this aspect in the zulu codebase ?
>> 
>> Laurent
>> 
>> 
>> Le jeu. 8 août 2019 à 20:51, Andrew John Hughes <gnu.andrew at redhat.com> a
>> écrit :
>> 
>>> 
>>> 
>>> On 08/08/2019 08:18, Laurent Bourgès wrote:
>>> 
>>> snip...
>>> 
>>>>> 
>>>> This class change must stay specific to jdk8u, as a different patch.
>>>> 
>>>> Finally I wonder if we should backport each individual jdk9, 10, 11, 14
>>>> patches into jdk8u as a long train or you would accept 1 large patch
>>>> gathering all patches.
>>>> Of course, the latter approach seems simpler to me, but it requires a
>>>> careful review to ascertain the code is the same with the current jdk
>>>> repository (jdk 14).
>>>> Once jdk8u & jdk14 have Marlin renderer 0.9.1.2, we will simply backport
>>>> future changes.
>>>> 
>>> 
>>> The individual changes should be backported. This assures that there is
>>> a record that these bugs are fixed in 8u, which is important for
>>> long-term maintainability.
>>> 
>>> I would suspect the original JDK9 patch would be an easier backport too,
>>> given how much the build system has changed and the files have moved
>>> around in JDK head.
>>> 
>>> A halfway option between the two would be to build up the required
>>> changes in a staging repository and then ask for a bulk review before
>>> integration into 8u. I believe this is how JFR is being backported.
>>> 
>>> Thanks,
>>> --
>>> Andrew :)
>>> 
>>> Senior Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>> 
>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>> https://keybase.io/gnu_andrew
>>> 
> 
> 
> 
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> 
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> 
> Please, support open standards:
> http://endsoftpatents.org/