Put me down as interested Richard. We can chat a bit on it at Devoxx Sven Am 19.10.2013 02:08 schrieb "Richard Bair" <richard.b...@oracle.com>:
> > That's pretty much it. VP6, T2K, deploy, FX JMX tooling. > > VP6 won't ever be opened because it is licensed 3rd party code. However it > isn't used that much anymore, most folks are using h.264. T2K I will come > back to. Deploy code (meaning, Applets) is not planned to be open sourced, > and I don't think it can be, unless JavaSE open sources all the applet / > webstart code. The JMX tooling code really doesn't work well (last I tried > it didn't work at all…). However I have big plans for JMX tooling in the 9 > timeframe which might come to fruition (anybody out there interested in > live-debugging JavaFX let me know, I've got a project for you!). I don't > now that we should bother open sourcing the JMX tooling code vs. just > replacing it. > > Kevin, if it is easy to open it, lets just do it and use it as a starting > point. > > For T2K, I'm a little unclear and hope someone can help clear up for me > under what circumstances we use T2K in the shipping product. My current > understanding was that we use native fonts for every platform except maybe > embedded, but that we want to switch from T2K to native fonts (Pango or > HarfBuzz or whatnot) soon. Is that right? > > The JDK uses an open source font library for OpenJDK, but T2K for the > Oracle JDK. On FX we just wanted to have a single implementation that was > used by both. The hope is that besides Applet code and VP6, everything in > the Oracle JavaFX would be available in OpenJFX, so that JavaFX is truly an > open source project built on open source code. > > For you guys at RedHat, the answer is: everything is open source. Go > forth, build, and prosper :-). I read on twitter Miho succeeded in a build > of OpenJFX based on OpenJDK. I think the doors are open for business. Other > than we still need the mercurial server moved from version .9 to something > modern so that we can have outside committers commit to the repo directly, > whereas right now it would require gate repos. Sadness. But if it takes a > Gate repo we'll use a darn gate repo so that we can be a real open source > project. > > Richard
