Re: 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  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  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 enou

Re: Future of JavaFX

[Florian Brunner]

I think actually the 2nd point (State-of-the-art code collaboration platform) 
is not comfortable enough how I described it.

Firstly, it should be a CI server, not a person, who synchronizes the 
repositories whenever there is a change on a non-feature branch of the main 
repository.

Secondly, try to work with pull requests
 For this to work in such an environment the collaborations platform needs the 
following features, I think:
- restrict write access to the non-feature branchens (in Gitflow based Git 
repositories these are usually at least the "master" and "develop" branch),
Only the CI server (or maybe the platform) should have write access to these 
branches, but no developer.
- provide the possibility to define a reviewer group and set up a rule that at 
least one member of this reviewer group needs to approve the pull request
- the reviewer should get an email (push notfication) whenever there is a new 
pull request or whenever a pull request changed

At least for Git, Atlassian Stash can provide such features, AFAIK. Maybe 
BitBucket does provide some similar features for Mercurial repositories?

If such a collaboration platform can be established/ configured it should even 
be possible to set-up another CI server job for 2 way synchronization, as it 
can be made sure everything has been reviewed by an accepted reviewer.

-Florian

Am Mittwoch, 2. Dezember 2015, 23.43:44 schrieb Florian Brunner:
> 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  
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.mik...@gmail.com]
> > > Sent: Dienstag, 1. Dezember 2015 23:05
> > > To: Markus KARG
> > > Cc: openjfx-dev@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 

Code Review Request For JDK-8144542: Remove an experimental stopgap fix (-Dprism.experimental.skipMeshNormalComputation) that is no longer needed

[Chien Yang]

Hi Kevin,

Please review the proposed fix.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8144542
Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8144542/webrev.00/

Thanks,
- Chien

Reviewing impl_* methods in JavaFX

[Jonathan Giles]

Hi all.

As you may recall a few months back I kicked off a review of APIs that 
exist in com.sun.* packages that were going to be lost due to the 
arrival of JDK 9. This resulted in a small number of APIs being proposed 
and made public in the last few weeks. With JDK 9 slipping we think it 
is prudent to use some of this time to do a similar exercise for the 
many impl_* methods that exist as deprecated methods in JavaFX. We would 
like to do two things:


1) Remove as many of these as possible.
2) Replace the relevant (and most important) impl_ methods with proper, 
non-deprecated API instead.


Some impl_* methods need to go simply because they take as arguments 
com.sun.* API. Other impl_* methods need to go away as they are bad or 
wrong API, intended for internal use only. Some subset of impl_* methods 
exist because they were added without the benefit of a full API review, 
but should now be reviewed and possibly made public.


Another indicator of how far we should progress this review is your 
usage of these methods. Therefore, it would be very interesting to us if 
you could email me (off list!) the output of a grep search in your 
projects. You could try running a command along the lines of the following:


grep -r --include "*.java" "impl_" .

This will help to inform us about the extent to which methods are being 
used, and which ones we need to think more carefully about before 
removing or replacing.


Thanks,
Jonathan

Re: Future of JavaFX

[Mark Fortner]

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  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 
> 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.mik...@gmail.com]
> > > Sent: Dienstag, 1. Dezember 2015 23:05
> > > To: Markus KARG
> > > Cc: openjfx-dev@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 
> > > 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

Re: Future of JavaFX

[Florian Brunner]

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  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.mik...@gmail.com]
> > Sent: Dienstag, 1. Dezember 2015 23:05
> > To: Markus KARG
> > Cc: openjfx-dev@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 
> > 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.gi...@gmail.com]
> > Sent: Dienstag, 1. Dezember 2015 20:19
> > To: Markus KARG
> > Cc: openjfx-dev@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 JavaF

Re: Future of JavaFX

[Kevin Rushforth]

I'll add a comment to the bug report.

-- Kevin


Ilya Buziuk wrote:

Hello, guys
If the question about bugs that are considered important was risen I 
would say that for me (as a JBoss Tools  
developer who uses JavaFx for cordova ripple based mobile emulator) 
the regression JDK-8090205 
  is utterly 
important. Basically, it makes Debugger API unusable since 8u20


On Wed, Dec 2, 2015 at 11:51 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


To add to this, if there is an existing open bug that you consider
important, please let us know.

-- Kevin



Chien Yang wrote:

On 12/2/15, 4:46 AM, Robert Krüger wrote:

How much of a priority are quality issues,
especially on the Mac (which clearly is a second-class
citizen as far as
JavaFX is concerned)? Are things like flashing when
opening Stages, bad
rendering performance, broken media APIs etc. an issue?

We have been busy fixing bugs to ensure a high quality release
for 9 on all supported platforms. Many of our developers have
a Mac and it is tested weekly. If you found a bug that is
still reproducible on the JDK 9 early access please file it
[1]. We will definitely investigate it.

[1]
https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report

- Chien




--
Best Regards,
Ilya Buziuk

Re: Future of JavaFX

[Ilya Buziuk]

Hello, guys
If the question about bugs that are considered important was risen I would
say that for me (as a JBoss Tools  developer who
uses JavaFx for cordova ripple based mobile emulator) the regression
JDK-8090205   is utterly
important. Basically, it makes Debugger API unusable since 8u20

On Wed, Dec 2, 2015 at 11:51 PM, Kevin Rushforth  wrote:

> To add to this, if there is an existing open bug that you consider
> important, please let us know.
>
> -- Kevin
>
>
>
> Chien Yang wrote:
>
>> On 12/2/15, 4:46 AM, Robert Krüger wrote:
>>
>>> How much of a priority are quality issues,
>>> especially on the Mac (which clearly is a second-class citizen as far as
>>> JavaFX is concerned)? Are things like flashing when opening Stages, bad
>>> rendering performance, broken media APIs etc. an issue?
>>>
>> We have been busy fixing bugs to ensure a high quality release for 9 on
>> all supported platforms. Many of our developers have a Mac and it is tested
>> weekly. If you found a bug that is still reproducible on the JDK 9 early
>> access please file it [1]. We will definitely investigate it.
>>
>> [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report
>>
>> - Chien
>>
>


-- 
Best Regards,
Ilya Buziuk

Re: Future of JavaFX

[Kevin Rushforth]

To add to this, if there is an existing open bug that you consider 
important, please let us know.


-- Kevin


Chien Yang wrote:

On 12/2/15, 4:46 AM, Robert Krüger wrote:

How much of a priority are quality issues,
especially on the Mac (which clearly is a second-class citizen as far as
JavaFX is concerned)? Are things like flashing when opening Stages, bad
rendering performance, broken media APIs etc. an issue?
We have been busy fixing bugs to ensure a high quality release for 9 
on all supported platforms. Many of our developers have a Mac and it 
is tested weekly. If you found a bug that is still reproducible on the 
JDK 9 early access please file it [1]. We will definitely investigate it.


[1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report

- Chien

Re: Future of JavaFX

[Chien Yang]

On 12/2/15, 4:46 AM, Robert Krüger wrote:

How much of a priority are quality issues,
especially on the Mac (which clearly is a second-class citizen as far as
JavaFX is concerned)? Are things like flashing when opening Stages, bad
rendering performance, broken media APIs etc. an issue?
We have been busy fixing bugs to ensure a high quality release for 9 on 
all supported platforms. Many of our developers have a Mac and it is 
tested weekly. If you found a bug that is still reproducible on the JDK 
9 early access please file it [1]. We will definitely investigate it.


[1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report

- Chien

RE: Future of JavaFX

[Markus KARG]

I see it differently. Often the initial contribution does not fulfil the
quality, because the original author alone has not the time to fix all the
law stuff, but just has a great idea and hacks it down. Then others chime in
an fix it. I often saw (an helped with) such features in other open source
projects like PostgreSQL, JOnAS, FOP, DITA-OT... and it was always a great
experience to work *together* to get the thing running and finally done in
the wanted quality.

This is not possible in the JavaFX project, as the original author has no
chance to file to core idea and let others finish it, since you expect the
original author not only having the great idea and hack together the first
draw, but first of all, sign papers, read lots of rules and process
definitions, and so on, before you even take a look at his idea (this is
what happened to me several times). Hence, you expect the original author to
have plenty of time to do all that on his own, all alone. That does not
match on most community driven open source authors, it only matches on
commercial open source vendors.

So actually you only want to get contributions from Oracle, IBM, Gluan and
possibly a hand full of fully paid others, but not from the user space.
That's a pity, because that user space has a lot of great ideas. So if you
only want full-time contributors, please say it loud and clear on the "how
to contribute" page, and all that "noise" from the community will stop at
once -- including USING JavaFX as a side effect.

I wouldn't bother you if I wouldn't have met those people and listened to
their ideas, BTW.

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
dalibor topic
Sent: Mittwoch, 2. Dezember 2015 10:46
To: openjfx-dev@openjdk.java.net
Subject: Re: Future of JavaFX

On 01.12.2015 22:58, Markus KARG wrote:
> I actually talk about those people that *did not* invest the time to
> contribute

Making high quality contributions to open source projects takes a 
considerable amount of humbleness, time and effort. People who aren't 
able or willing to invest the necessary time and effort into making high 
quality contributions are not likely to produce acceptable results - in 
any open source community.

To quote Jono Bacon:

"Low-quality contributors don't bring much other than noise: they are a 
net drain on resources because other good contributors have to take time 
away to support them." [1]

cheers,
dalibor topic

[1] http://opensource.com/life/15/3/how-to-fire-community-members
-- 
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


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

 Oracle is committed to developing
practices and products that help protect the environment

RE: App freezing on Linux

[Markus KARG]

Please try again with JavaFX 1.8.0_66.
-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Bryan Buchanan
Sent: Mittwoch, 2. Dezember 2015 09:30
To: openjfx-dev@openjdk.java.net
Subject: App freezing on Linux

I have a customer testing an FX app and more often than not, if the app is
left open for a while (20 minutes or so), either the mouse ceases to work,
or if it does work, when you click a field, or do something that should
re-paint the window, the whole FX window goes totally grey and the app
"disappears".

I've tried starting with "-Dprism.verbose=true -Dprism.order=sw" and
without these options, and it seems to make no difference.

The system is Xubuntu 14.0.43,  kernel 3.13.0-71 running on a Gigabyte
Brix, and Java 64 bit build 1.8.0_60-b27. I don't have this hardware in my
office, but have run up a system with the same OS, kernel and Java, and
cannot re-produce the problem.

Are the any other command line switches, or debug flags that I can set to
try and get a handle on why this is happening ?

(Hope this is the right list for issues like this).

Re: Verona (JEP 223) Integration to JDK 9

[Kevin Rushforth]

The Verona integration is complete and has been synced back down into FX 
9-dev. The per-build tags now match the JDK, so build 94 was tagged with 
"9-b94" and build 95 is tagged with "jdk-9+95".


-- Kevin


Kevin Rushforth wrote:

Hi,

The Verona (JEP 223) Integration to JDK 9 is planned for next week as 
announced on the jdk9-dev mailing list [1].


This will have a small impact on JavaFX in that we will skip next 
week's integration from FX 9-dev into 9 master, for the same reason as 
the JDK. The anticipated FX-specific dates are:


   On or before Mon 30 Nov
   - Sync FX sandbox-9-verona [2] with FX 9 MASTER (build 94)

   Mon 30 Nov (evening) or Tue 1 Dec (morning)
   - Integrate sandbox-9-verona to 9 (MASTER)

   Wed 2 Dec
   - After promotion, sync down to FX 9-dev and sandbox-9-jake

Thanks.

-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003100.html

[2] http://hg.openjdk.java.net/openjfx/sandbox-9-verona/rt

Re: Future of JavaFX

[Tobias Bley]

I absolutely agree. While we are committing to many Github projects it’s too 
hard to do that for JavaFX via bugs.sun.com…. Github is a modern way of 
developing together. The „bugs.sun.com“ way is like using a candle instead of 
electric light…

Best Regards,
Tobi


> Am 02.12.2015 um 13:32 schrieb Robert Krüger :
> 
> Please, you're really oversimplifying things, I'm not sure if
> intentionally. It's not just coding. In my company I pay people
> serious money who do testing and file reproducible test cases with a
> qualified analysis of what they observed and what may be the problem and
> that's what I have done in the past for JavaFX using my Jira account as
> also have a number of other qualified people who were affronted by the
> policy changes, which probably resulted in many of them stopping this
> because they could no longer follow their Jira tickets including taking
> part in discussions there or answering questions by the engineers. If you
> don't count these things as meaningful/valuable contributions that make a
> difference, I don't really know on what basis to argue anymore. Then I have
> to assume, you just don't want to really deal with criticism. Of course
> some unqualified ranting in a Jira issue hurts (i.e. consumes resources)
> more than it helps but putting the many qualified people (many of them on
> this list) all in that category is neither correct, nor a smart move in
> anyone's interest.
> 
> On Wed, Dec 2, 2015 at 10:45 AM, dalibor topic 
> wrote:
> 
>> On 01.12.2015 22:58, Markus KARG wrote:
>> 
>>> I actually talk about those people that *did not* invest the time to
>>> contribute
>>> 
>> 
>> Making high quality contributions to open source projects takes a
>> considerable amount of humbleness, time and effort. People who aren't able
>> or willing to invest the necessary time and effort into making high quality
>> contributions are not likely to produce acceptable results - in any open
>> source community.
>> 
>> To quote Jono Bacon:
>> 
>> "Low-quality contributors don't bring much other than noise: they are a
>> net drain on resources because other good contributors have to take time
>> away to support them." [1]
>> 
>> cheers,
>> dalibor topic
>> 
>> [1] http://opensource.com/life/15/3/how-to-fire-community-members
>> 
>> --
>>  Dalibor Topic | Principal Product Manager
>> Phone: +494089091214  | Mobile: +491737185961
>> 
>> 
>> 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
>> 
>>  Oracle is committed to developing
>> practices and products that help protect the environment
>> 
> 
> 
> 
> -- 
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG
> 
> www.lesspain-software.com

Re: Future of JavaFX

[Robert Krüger]

Kevin,

thanks for sharing those plans. How much of a priority are quality issues,
especially on the Mac (which clearly is a second-class citizen as far as
JavaFX is concerned)? Are things like flashing when opening Stages, bad
rendering performance, broken media APIs etc. an issue? As far as my
company is concerned, the biggest problem (which resulted in us reluctantly
dropping the idea of a migration of our product to JFX for the time being
after lengthy evaluation) is not so much lack of features but primarily
quality in terms of robustness and user experience and the number of
problems we have run into in almost every area that we did tests in was
what led us to that decision (especially with Mac being our most important
platform).

Is there awareness that there are serious problems of the described kind
that block the adoption of JFX in companies who desperately want to switch?
It's always difficult to judge that by the priorities in Jira but it
appeared to me that in many cases the perception on the Oracle side was
very different, if things like the white flashing problem when opening
windows or the tree view scrolling incorrectly or looping in a media api
not working seemed to be viewed rather like a minor glitch.

People have different requirements and thus different views on the topic of
this thread but I found the analysis and observations in Shay's posting not
very far from that of our own engineering team (no affiliation with him or
his company btw.) for the reasons described above.

Best regards,

Robert


On Wed, Dec 2, 2015 at 1:29 AM, Kevin Rushforth 
wrote:

> Just to chime in on a couple of points that have been raised in this
> discussion...
>
> * We are interested in working with the OpenJFX community to improve
> JavaFX. In particular: if you find a bug, file it (via bugs.java.com if
> you don't have a JBS account); if you want to contribute a patch to fix the
> bug, we'd love to review it; if you have an idea for an improvement, file
> it as an RFE (enhancement) and start up a thread on the mailing list.
> Larger features need a JEP, but smaller improvements do not.
>
> Please be aware that as part of the OpenJDK community, we are bound by the
> processes of the OpenJDK, including the need for a signed OCA in order to
> contribute, and before you can get a JBS account. If you are dissatisfied
> with those processes and policies, then I invite you to discuss it on the
> disc...@openjdk.java.net alias, and not here.
>
>
> * While we aren't planning a huge number of features in JDK 9, we are
> delivering some interesting improvements. Jigsaw is the big release driver
> and most of our effort on JavaFX is to align with that. For those of you
> who weren't at JavaOne, here is a list of things that are currently planned
> for JDK 9:
>
> - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt
> interop)
>
> - JEP 253 -- Control Skins & additional CSS APIs (proper support for
> third-party controls)
>
> - High DPI enhancements (full support on Windows; add support for Linux)
>
> - Public API for commonly used methods from internal packages:
>* Nested Event Loop
>* Pulse Listener
>* Platform Startup
>* Text API (HitTest, etc)
>* Static utility functions (under investigation)
>
> - New versions of WebKit and GStreamer
>
> And here is an incomplete list of things we are thinking about for after
> JDK 9, possibly in an update release. In fact, the recently proposed JDK 9
> slip [1] makes it possible to consider pulling a few of them into JDK 9, so
> let us know which ones you consider most important:
>
> - Provide a JavaFX equivalent for JEP 272 / AWT ‘Desktop’ API
>
> - Make UI Control Behaviors public
>
> - UI Control Actions API
>
> - Public Focus Traversal API
>
> - JavaFX support for multi-resolution images
>
> - Draggable tabs
>
> - Image IO
>
>
> -- Kevin
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Future of JavaFX

[Robert Krüger]

Please, you're really oversimplifying things, I'm not sure if
intentionally. It's not just coding. In my company I pay people
serious money who do testing and file reproducible test cases with a
qualified analysis of what they observed and what may be the problem and
that's what I have done in the past for JavaFX using my Jira account as
also have a number of other qualified people who were affronted by the
policy changes, which probably resulted in many of them stopping this
because they could no longer follow their Jira tickets including taking
part in discussions there or answering questions by the engineers. If you
don't count these things as meaningful/valuable contributions that make a
difference, I don't really know on what basis to argue anymore. Then I have
to assume, you just don't want to really deal with criticism. Of course
some unqualified ranting in a Jira issue hurts (i.e. consumes resources)
more than it helps but putting the many qualified people (many of them on
this list) all in that category is neither correct, nor a smart move in
anyone's interest.

On Wed, Dec 2, 2015 at 10:45 AM, dalibor topic 
wrote:

> On 01.12.2015 22:58, Markus KARG wrote:
>
>> I actually talk about those people that *did not* invest the time to
>> contribute
>>
>
> Making high quality contributions to open source projects takes a
> considerable amount of humbleness, time and effort. People who aren't able
> or willing to invest the necessary time and effort into making high quality
> contributions are not likely to produce acceptable results - in any open
> source community.
>
> To quote Jono Bacon:
>
> "Low-quality contributors don't bring much other than noise: they are a
> net drain on resources because other good contributors have to take time
> away to support them." [1]
>
> cheers,
> dalibor topic
>
> [1] http://opensource.com/life/15/3/how-to-fire-community-members
>
> --
>  Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
>
> 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
>
>  Oracle is committed to developing
> practices and products that help protect the environment
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Future of JavaFX

[dalibor topic]

On 02.12.2015 10:44, Ryan Jaeb wrote:

Which is it - discuss or adoption-discuss?


adoption-discuss is for general discussion about bundling and aiding 
OpenJDK collaboration, discuss is for general discussion about the 
OpenJDK Community.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


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

 Oracle is committed to developing
practices and products that help protect the environment

Re: Future of JavaFX

[dalibor topic]

On 01.12.2015 22:58, Markus KARG wrote:

I actually talk about those people that *did not* invest the time to
contribute


Making high quality contributions to open source projects takes a 
considerable amount of humbleness, time and effort. People who aren't 
able or willing to invest the necessary time and effort into making high 
quality contributions are not likely to produce acceptable results - in 
any open source community.


To quote Jono Bacon:

"Low-quality contributors don't bring much other than noise: they are a 
net drain on resources because other good contributors have to take time 
away to support them." [1]


cheers,
dalibor topic

[1] http://opensource.com/life/15/3/how-to-fire-community-members
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


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

 Oracle is committed to developing
practices and products that help protect the environment

Re: Future of JavaFX

[Ryan Jaeb]

Which is it - discuss or adoption-discuss?

I really hope someone jumps over and restarts the JBS policy conversation.
I tried when the JIRA change was initially announced and my
misunderstanding of some key facts undermined the message I was trying to
get across.  I also think it may have devalued the concerns that others
were trying to raise, so it would be great to see everyone get another
opportunity to participate in a discussion that may get taken more
seriously.

Learning from the mistakes I made last time, I think it would be useful if
someone that's been using bugs.java.com could start the discussion with an
overview of the bugs.java.com submission process.  I would volunteer, but I
quit submitting bugs when the submission process changed, so I wouldn't be
able to offer an accurate explanation of the current process.

Ryan Jaeb

On Wed, Dec 2, 2015 at 3:11 AM, dalibor topic 
wrote:

>
>
> On 02.12.2015 01:29, Kevin Rushforth wrote:
>
>> Please be aware that as part of the OpenJDK community, we are bound by
>> the processes of the OpenJDK, including the need for a signed OCA in
>> order to contribute, and before you can get a JBS account. If you are
>> dissatisfied with those processes and policies, then I invite you to
>> discuss it on the disc...@openjdk.java.net alias, and not here.
>>
>
> Suggestions for general improvements in that area are welcome on the
> adoption-discuss [0] mailing list. Please do make sure to check the list
> archives before posting to see if an idea hasn't been discussed already.
>
> cheers,
> dalibor topic
>
> [0] http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss
> --
>  Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
>
> 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
>
>  Oracle is committed to developing
> practices and products that help protect the environment
>

Re: Future of JavaFX

[dalibor topic]

On 02.12.2015 01:29, Kevin Rushforth wrote:

Please be aware that as part of the OpenJDK community, we are bound by
the processes of the OpenJDK, including the need for a signed OCA in
order to contribute, and before you can get a JBS account. If you are
dissatisfied with those processes and policies, then I invite you to
discuss it on the disc...@openjdk.java.net alias, and not here.


Suggestions for general improvements in that area are welcome on the 
adoption-discuss [0] mailing list. Please do make sure to check the list 
archives before posting to see if an idea hasn't been discussed already.


cheers,
dalibor topic

[0] http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


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

 Oracle is committed to developing
practices and products that help protect the environment

App freezing on Linux

[Bryan Buchanan]

I have a customer testing an FX app and more often than not, if the app is
left open for a while (20 minutes or so), either the mouse ceases to work,
or if it does work, when you click a field, or do something that should
re-paint the window, the whole FX window goes totally grey and the app
"disappears".

I've tried starting with "-Dprism.verbose=true -Dprism.order=sw" and
without these options, and it seems to make no difference.

The system is Xubuntu 14.0.43,  kernel 3.13.0-71 running on a Gigabyte
Brix, and Java 64 bit build 1.8.0_60-b27. I don't have this hardware in my
office, but have run up a system with the same OS, kernel and Java, and
cannot re-produce the problem.

Are the any other command line switches, or debug flags that I can set to
try and get a handle on why this is happening ?

(Hope this is the right list for issues like this).