[OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces (marlin) enhancements ?

[Mario Torre]

Btw, just to clarify one thing that may have been too subtle in the replies.

I'm all for giving this work a proper home with Graphics Rasterizer,
especially if this means it will get proper evaluation, which is what
should happen after all this discussion :)

What I do want to avoid, is to go around in circles, which is what's
happening here so far.

Cheers,
Mario



2015-02-19 15:50 GMT+01:00 Mario Torre <neugens.limasoftware at gmail.com>:
> 2015-02-19 15:25 GMT+01:00 dalibor topic <dalibor.topic at oracle.com>:
>>
>>
>> On 19.02.2015 13:50, Mario Torre wrote:
>>
>>> The code is part of an OpenJDK project, though, it's already the
>>> existing Java rasterizer.
>>
>>
>> It's not part of an OpenJDK Project - Project with an upper case 'P'. See
>> http://openjdk.java.net/projects/ for details. Considering the motivation
>> for this discussion, that would be a necessary precondition.
>>
>>> Of course I'm fine with giving it a formal home in the Graphics
>>> Rasterizer project (where it naturally belongs), but let's also try to
>>> be a bit more pragmatic, this code is in hold since more than one year
>>> now, the JEP process can be started before giving a formal home, or at
>>> least concurrently to that.
>>
>>
>> While the JEP process is explicitly open even to aggressive,
>> outside-the-box, and even completely wacky ideas, new feature ideas often
>> require significant up-front research, experimentation, and socialization
>> before they're ready to be proposed as enhancements to the JDK itself.
>>
>> That work is typically performed within an OpenJDK Project.
>>
>> That does not preclude writing any number of JEPs as a finger exercise, of
>> course, but one should not expect that writing JEPs would in any form be a
>> substitute for going through the significant up-front work necessary to
>> research, experiment and socialize the desired changes within the OpenJDK
>> Community.
>
> While I agree with your general feelings, one has to start
> *somewhere*. There have been 3rd parties doing extensive test on this
> code already, and while those test need to be confirmed this is no
> different than any other work done in the rest of the platform. Ah,
> and yes, IcedTea will integrate it if it make sense, of course.
>
> What we are discussing here is not a "aggressive, outside-the-box, and
> even completely wacky ideas", is a set of patches that were partially
> reviewed in very positive terms, but then put in limbo over the years.
> Unfortunately, given the area I recognize there are not many
> experienced developers who can comment on the code, but still,
> ignoring that completely isn't fair either.
>
>> For example, it would be interesting to see if, once the code has found a
>> home in an OpenJDK Project, you, Mario, would take the time it takes to add
>> it to IcedTea, and confirm that it does not cause issues with your
>> regression and other tests on the various platforms you support. Among other
>> things, that would allow you to form a more informed opinion about the code,
>> potential integration paths, etc. and inform others in such a Project about
>> your experiences.
>
> I don't work directly on IcedTea, and afaik there is no IcedTea for 8
> onward (afaik, but Andrew Hughes and Omair may tell us more on that).
> Also, IcedTea is *not* a test repository for OpenJDK, is a stable
> implementation of it, similar to what Oracle JDK is. That said, I'm
> sure the IcedTea maintainers will do their part, especially if the
> code turns out to be of the quality we are supposing.
>
> Btw, a big chunk of this code, as I said, was sent out for review
> already. If the reviewers thinks the quality doesn't justify the
> efforts of integration into OpenJDK, then, please, just say so!
>
>> Such work would have to take the time it takes either way. I believe that
>> focusing on writing JEPs before such work is complete (or even begun) means
>> setting one's priorities in a way that puts the cart before the horse. You
>> can certainly chose to do that, but the cart might not get very far on its
>> own. [0]
>
> Ok, so let it not be a JEP. Let it not be a separate patch set for
> review. What other options are there? I don't think discussing forever
> whether we want a Project, a JEP or whatever means to put an horse in
> front of the cart, it just means to park the cart behind a wall.
>
> Cheers,
> Mario
>
> --
> 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/



-- 
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/