Project Proposal: JFX

[Brian Beck]

Hi Patrick:

I'm on the JavaFX UI Controls team.  Since the UI Controls will be the 
first part of the platform opened up, we are the guinea pigs for this 
project.  Let me add to what Rich said by giving you our day one plan.

Once the project is approved the new repo will be initialized with the 
UI code from the head of our internal repo.  At that point the UI code 
will be removed from our internal repo and we will shift to working in 
the open repo.  As Rich said, nobody wants to have to deal with  
different branches if we don't have to.

Initially we will have UI Controls in the open and the rest of the 
platform internal.  We will build the Oracle JavaFX bits from the 
combination of the open + internal and make those bits available on a 
weekly basis.  The open repo will be buildable without any of the 
internal source (obviously) but it will need the weekly binary bits we 
are producing.  This is unavoidable at first.  As the process continues 
we will take more  pieces out of the internal repo and add them to the 
open repo.  Ultimately the open repo will stand on its own with no need 
for Oracle's binaries.  How long this process takes is a little unclear 
at the moment.  Having been part of the opening of the JDK, I imagine 
we'll make progress quickly at first but there may be a few pieces that 
require more effort or that have to be replaced entirely.  We'll just 
have to see how it goes.  But again, as Rich pointed out, we have every 
reason to make this go quickly.  Nobody wants to deal with code in two 
places.

Hope this helps.

Brian.


On 10/27/11 11:18 PM, Richard Bair wrote:
> Hi Patrick,
>
>> How do you envision the transition vis-a-vis releases? Currently there
>> are binary bits to download from javafx.com. Will those be built, from
>> day 1, from the combination of open-source bits + binary bits? Or do
>> you plan to keep a closed, "private" repository/branch for releasable
>> items for the time being?
> I see it as being the same as with OpenJDK, in that:
>    - The entire project will be buildable and runnable and usable on free software
>    - We are likely to have some encumbrances that require a closed module for the time being for the binaries that we ship of JavaFX, for the sake of performance and such (e.g. T2K for fonts)
>    - We will continue to work hard to replace those bits with free code
>
> For example, OpenJDK uses Open Pisces, while the JRE / JDK builds from Oracle use Ductus. However he have definite goals to improve Open Pisces so we can replace Ductus. It costs us time and money to maintain two different implementations. It is in our interest to make the free code good enough to replace the non-free code. The same is true here. I hate having to maintain a public forest and private forest -- it complicates my life and slows down my team. I would much rather only have the public forest and do everything in one place -- the open. It just makes sense.
>
>> As far as planning and taking input from the community, JavaFX has
>> several years of development behind it, basically all driven from
>> within Sun/Oracle - how do you see _planning_ incorporating the
>> community? I ask this because until now, I've seen JavaFX as a sort of
>> product being developed by Oracle, rather than a part of the standard
>> library. As a product, it would be in the product owner's interest to
>> have full say over what is included and what is not, based on what
>> they believe will do well on the market. A more concrete question
>> would be: will all project plans, planned milestones, planned features
>> be made public in advance, and be open to discussion and feedback from
>> the community, and will the decision-making process around project
>> planning and features be made in the open?
> We plan on following the pattern of OpenJDK. We plan on using JEP's for describing features we'd like to see. Of course anybody in the community (I'd have to consult the bylaws but I would guess any Contributor?) can file JEP's as well. We keep pretty much everything else in JIRA -- every bug or feature that goes into a specific release is listed there as targeted at that release. Of course these decisions (what features go into which release) are fluid and JIRA should never be taken as the authoritative roadmap -- that would be on the project pages. Much of the back and forth of the design work is also in JIRA (not as much historically but more so now). Also worth mentioning is that our release schedule is tied to the Java SE release schedule, which makes sense.
>
> Obviously the decision of what will be worked on and what won't will largely be based on who is doing the work. Obviously the decision about whether to spend Oracle engineering on a particular problem is a decision that ultimately lies with Oracle, just as what features you would choose to work on is ultimately your choice. But if members of the community (for example you, or IBM, or whomever) decides they want a feature and will provide the engineering time (including testing and documentation) and the feature is not otherwise in conflict with the project, then without question I would be happy for such help and would adjust our plans accordingly.
>
> We expect to do things in an "open and meritocratic manner" as the bylaws state. But ultimately, as the bylaws state, the Project lead has final say on all technical matters. I would do my best to make sure the right technical choices are always made (I think JavaFX to date has a very strong track record of this).
>
> Thanks
> Richard