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.limasoftw...@gmail.com>: > 2015-02-19 15:25 GMT+01:00 dalibor topic <dalibor.to...@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/
