Am Donnerstag, den 19.02.2015 um 15:25 +0100 schrieb dalibor topic: > > 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.
Socialization seems to be the major pain point here ;-) It seems that the project is already fairly well advanced, and, from what I hear, used in production code in some places already, where it seems to outperform the pisces rasterizer. The impact of including it in OpenJDK seems to be fairly small: it is an implementation of an existing SPI, and there's no need to make it the *default* right away. It can be included and live side-by-side and require some runtime flag to get it enabled. And when enough testing has been done, eventually switched to default. > That work is typically performed within an OpenJDK Project. I agree that it'd be good to bring Marlin into the Rasterizer project (which otherwise appeared to be an orphaned project anyway...) Why not go both routes in parallel: propose inclusion into the Rasterizer project, and start discussing a JEP. I see no problem with that. > 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] Well, dunno, it just seems pragmatic to me. If anything, OpenJDK could need a little more agility and welcomeness to contributions, especially if they provide such massive improvements, and has already been tested outside OpenJDK for quite a while (exactly because it got stuck in OpenJDK's processes). Regards, Roman
