Future of JavaFX

[Scott Palmer]

I didn't find it too difficult to get the form signed and submitted, but a key exchange is also a good idea.

The mirror of the Mercurial repo on BitBucket also makes a lot of sense as a staging area for contributions. (So long as I can avoid dealing with the insanity of Git and its ridiculous UI.)

However just as an overall point to this whole conversation... I don't believe the sky is falling. I choose JavaFX as the basis of all my GUI app.  There is no crisis, the primary theme of this thread is complete FUD IMO. This thread alone does more harm to the perception of JavaFX in the community than anything Oracle has done.

The main thing that prevents me from contributing to OpenJFX is time. Nothing else in the process is a deal breaker. Sure I was a bit irked when the open JavaFX Jira was moved to the more restricted OpenJDK Jira, because Jira (with proper access) is so much better than bugs.java.com. I wouldn't have a problem reporting issues through bugs.java.com though, like I did for years when reporting issues with Swing.
(It turns out that I got access to the OpenJDK Jira anyway.)

Quite frankly, there are very few features I would add the JavaFX.  (+1 to desktop integration APIs and access to cameras though.) So I am not concerned much that the focus for Java 9 has been mostly about bug fixing. 

The issue I have with that is the timeframe in terms of getting those fixes in a JRE that I can ship with. A similar thing happened between JavaFX 2.x an JavaFX 8.  Only a handful of issues were backported while I agonized over the fact that I had to fill my code with workarounds for issues that were already fixed in the Java 8 release that was still many months away.  So the delay for Java 9 may be a benefit in terms of getting more features into JavaFX 9, but it's bad from the perspective of delaying the release of all those fixes!

Perhaps if the community could help the effort to backport, some of that could be remedied. I expect a lot of the problem is the QA cycles needed to qualify the changes for release in a Java 8 update though.

Scott

> On Dec 2, 2015, at 6:12 PM, Mark Fortner <phidias51 at gmail.com> wrote:
> 
> I think the first hurdle is to get people to sign the CLA. Having to print
> a copy, sign it, and find a fax machine or scanner to resend it seems kind
> of archaic in this day and age.  That said, e-signing a PDF shouldn't be
> too difficult, but it would be better if it were simply a form that you
> attached your public key to. This would serve 2 purposes: (1) you have a
> proxy for a signature, (2) the key could be used to access the repo.
> 
> That said, even that might be too much for people who just have a quick bug
> fix that they'd like to see reviewed and merged.
> 
> Cheers,
> 
> Mark
> 
> 
>> On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner <fbrunnerlist at gmx.ch> wrote:
>> 
>> Some time ago there actaully was a OpenJFX mirror repository on BitBucket.
>> 
>> I'm not totally sure anymore why this was stopped. I think it needs someone
>> who keeps the repositories in sync and there were some concerns that it's
>> harder to control who wrote a patch. But maybe the idea with CLA signers
>> only
>> members would solve this issue?
>> 
>> So I see 3 pain points being raised.
>> 
>> 1. Signing the CLA.
>>        - Personally, I don't see any way around this. If there is no CLA
>> then you
>> end up with a project _nobody_ is in control of.
>>        - Basically it envolves the following steps:
>>         -- Download it from the website
>>         -- print it
>>         -- sign it
>>         -- send it off
>>         -- you only have to do this once
>>         -- you don't have to wait for Oracle to receive it to start
>> working
>> on the issue you like to solve
>> 
>>   Can this be presented in a way it doesn't scare people away as
>> according to
>> some statements it seems to do now?
>> 
>> 2. State-of-the-art code collaboration platform.
>>        -- This would have to be something like GitHub or BitBucket
>>        -- Only CLA signers can be members of the project
>>        -- Someone has to be in charge to synchronize the repositories
>> (probably one way only)
>>        -- personally I like to work with feature branches in Git but I
>> think
>> you can get something similar with Mercurial bookmarks. So
>>        --- pick an issue you would like to work on
>>        --- consider to announce it on this mailing list
>>        --- create a feature branch
>>        --- start pushing your changes to the feature branch
>>        --- other developers of the projects (all CLA signers) might chime
>> in
>> as they like
>>       --- once you think you're finished create a patch from the feature
>> branch and add it to the issue or (if you don't have enough rights) send
>> it to
>> the mailing list
>>       --- take the feedback from the review, do the fixes an create
>> another
>> patch etc.
>> 
>> So the main benefit would be that several developers could work on the same
>> issue until it gets to a high enough qualiy state to be merged into the
>> main
>> repository and not requiring one developer to do it all on his/ her own.
>> 
>> 
>> 3. Filing and commenting on issues
>>  - if you don't have enough rights, file it on bugs.java.com
>>  - ask on this mailing list (or ask someone you know on this mailing list
>> to
>> do it for you) about the corresponding issue on bugs.openjdk.java.net
>> - someone from Oracle should give anyone who filed an issue that made it
>> to
>> bugs.openjdk.java.net the enough rights so he/ she can join on the
>> discussion
>> in the issue
>> 
>> Any better way?
>> 
>> 
>> -Florian
>> 
>> Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula:
>>> The proposed strategy also applies to bitbucket, which does have
>> mercurial
>>> support ;)
>>> 
>>> On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG <markus at headcrashing.eu>
>> wrote:
>>>> Too bad that Github cannot fork mercurial repos. It would be
>> interesting
>>>> to see the real number of pull requests such a fork would gain. Maybe
>>>> Dalibor is right and we would end up with zero? ;-)
>>>> 
>>>> -Markus
>>>> 
>>>> 
>>>> 
>>>> From: Tomas Mikula [mailto:tomas.mikula at gmail.com]
>>>> Sent: Dienstag, 1. Dezember 2015 23:05
>>>> To: Markus KARG
>>>> Cc: openjfx-dev at openjdk.java.net
>>>> Subject: Re: Future of JavaFX
>>>> 
>>>> 
>>>> 
>>>> The review process for external contributions does not even have to be
>>>> different from the internal review process. There can be a virtual
>>>> organization on GitHub called "Oracle CLA signatories". After a pull
>>>> request has been reviewed, all that the OpenJFX committer has to do
>> before
>>>> merging is to check whether the contributor is a member of this
>>>> organization.
>>>> 
>>>> 
>>>> 
>>>> Tomas
>>>> 
>>>> 
>>>> 
>>>> On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG <markus at headcrashing.eu>
>>>> wrote:
>>>> 
>>>> We should ask ourselfs whether we want more contributions or not. We
>> will
>>>> not get them until we change something. Most contributors in the Open
>>>> Source just want to drop a bug report or a feature or two, and
>> multiplied
>>>> by the number of those guys, this is a lot of stuff. Only few
>> contributors
>>>> are willing to stay for long time, and only for those it makes sense to
>>>> have the complex rules. For example, I do not see why we cannot have a
>>>> dedicated full time "Community Officer" who simply collects the
>>>> contributions, reviews it, applies the needed checks and rules and all
>>>> that
>>>> instead of asking everybody to follow a complex process? That would
>> ensure
>>>> the quality, but not for the cost of losing contributors.
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Hervé Girod [mailto:herve.girod at gmail.com]
>>>> Sent: Dienstag, 1. Dezember 2015 20:19
>>>> To: Markus KARG
>>>> Cc: openjfx-dev at openjdk.java.net
>>>> Subject: Re: Future of JavaFX
>>>> 
>>>> Things are not different for Apache projects. Google does not accept
>> any
>>>> external contributions. The Linux kernel development is very tightly
>>>> controlled. We should stop considering that widespread open source
>>>> policies
>>>> are only a problem with JavaFX. These policies are in place for a
>> reason.
>>>> 
>>>> Hervé
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Dec 1, 2015, at 20:13, Markus KARG <markus at headcrashing.eu>
>> wrote:
>>>>> 
>>>>> I wonder why I was able to jointly assign my copyright with a lot of
>>>> 
>>>> other
>>>> 
>>>>> open source projects without having to sign papers, sent them in by
>> fax,
>>>>> wait for a written agreement, and pray to get a JIRA account... ;-)
>>>>> 
>>>>> See, I talked to a real lot of former JavaFX contributors in the past
>>>> 
>>>> weeks
>>>> 
>>>>> (visited some European JUGs in 2015), and *virtually everybody* told
>> me
>>>> 
>>>> that
>>>> 
>>>>> he is really unsatisfied with the fact that he cannot directly file
>> to
>>>> 
>>>> JIRA
>>>> 
>>>>> anymore or AT LEAST vote and comment on existing tickets. Is the
>> JavaFX
>>>> 
>>>> team
>>>> 
>>>>> clear about how many contributors you lost by that policy? I really
>>>> 
>>>> wonder
>>>> 
>>>>> whether you see the reality there outside of Oracle. People stopped
>>>>> reporting bugs! This is a real problem for JavaFX. You should act.
>> Now.
>>>>> 
>>>>> -Markus
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On
>>>> 
>>>> Behalf Of
>>>> 
>>>>> dalibor topic
>>>>> Sent: Dienstag, 1. Dezember 2015 19:06
>>>>> To: openjfx-dev at openjdk.java.net
>>>>> Subject: Re: Future of JavaFX
>>>>> 
>>>>>> On 01.12.2015 18:35, Markus KARG wrote:
>>>>>> With respect to TeamFX, the better question is: Are there plans to
>>>> 
>>>> further
>>>> 
>>>>>> open the project so third party has an easier channel to contribute
>>>>> 
>>>>> without
>>>>> 
>>>>>> the hazzle of contributor agreements
>>>>> 
>>>>> "Like many other open-source communities, the OpenJDK Community
>> requires
>>>>> Contributors to jointly assign their copyright on contributed code."
>> as
>>>>> http://openjdk.java.net/contribute/ wisely says.
>>>>> 
>>>>> There is no good reason to change that.
>>>>> 
>>>>> cheers,
>>>>> dalibor topic
>>>>> --
>>>>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>>> Phone: +494089091214 <tel:%2B494089091214>  <tel:+494089091214
>>>> 
>>>> <tel:%2B494089091214> > | Mobile: +491737185961 <tel:%2B491737185961>
>>>> 
>>>>> <tel:+491737185961 <tel:%2B491737185961> >
>>>>> 
>>>>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>>>> 
>>>>> ORACLE Deutschland B.V. & Co. KG
>>>>> Hauptverwaltung: Riesstr. 25, D-80992 München
>>>>> Registergericht: Amtsgericht München, HRA 95603
>>>>> 
>>>>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>>>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>>>> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
>>>>> 
>>>>> <http://www.oracle.com/commitment> Oracle is committed to developing
>>>>> practices and products that help protect the environment
>> 
>>