Re: JavaFX JIRA issues moving to JBS

[Adam Granger]

A crazy out-there suggestion...

Could OpenJDK work in partnership with stackoverflow on this through via
either a new tag - e.g.[javafx-possible-bug] or a whole new stackoverflow
site?

IMHO forums aren't the best way to work through coding problems, it's just
unorganised noise, the stackoverflow structured
question/answer/comment/vote approach is much better suited poor
quality questions (bug reports) will automatically get culled by the
crowd, sscce questions are encouraged, better community involvement
etc

Adam.

> I will also add a suggestion that I think would be reasonable.  Take
> advantage of the OTN forum.  Anyone without a JBS account could be asked
> to
> post their first bug report to the forum.  If it's not a bug, the forum
> community can help with the issue.  The forum community can also help
> people learn to write a good bug report.
>
> If someone submits a decent quality bug report to the forum, they could be
> invited to use JBA.  The threshold could be more than one good bug report
> to the forum if needed.  That gives new users and entry point into the
> community and it filters out most of the noise on the actual bug tracker.
>
> You could probably even come up with a strategy for letting the community
> nominate people for JBS invites so the developers wouldn't have to sift
> through the forums looking for users that would make good JBS
> participants.
>
> Ryan Jaeb
>
>
>
> On Wed, Apr 15, 2015 at 10:03 AM, Fabrizio Giudici <
> fabrizio.giud...@tidalwave.it> wrote:
>
>> On Wed, 15 Apr 2015 17:55:19 +0200, Robert Krüger 
>> wrote:
>>
>>  Understandable. IMHO a certain "seriousness threshold" to reduce the
>> noise
>>> makes sense.
>>>
>>
>> I was thinking on a score system such as the one at StackOverflow, but
>> I'm
>> not aware of any support of Atlassian.
>>
>>  What if you at least had a policy where someone in your team
>>> can propose people they know from the mailing list for a while for
>>> accounts? I don't think what's needed is to have a completely open
>>> system
>>> with one-click self-registration but don't draw the line where you draw
>>> it
>>> now, which means you're missing qualified input from people who are
>>> ready
>>> to invest qualified time (e.g. to build test cases and good
>>> descriptions
>>> of
>>> issues) but do not submit patches.
>>>
>>
>> I would add that having a corporate collective account could probably
>> help. I'm thinking of a case in which there are a couple of dozen
>> developers from the same corporate that could share the same email
>> alias.
>> Even in this case self-subscribing wouldn't be needed, actually it might
>> make sense to have a control process to be sure that the corporate
>> account
>> is official, I mean the corporate is in charge for it.
>>
>>
>> --
>> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
>> "We make Java work. Everywhere."
>> http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
>>
>

Re: JavaFX JIRA issues moving to JBS

[Anirvan Sarkar]

On 15 April 2015 at 03:50, Kevin Rushforth 
wrote:

> ...
> The issues currently in the RT project in JavaFX JIRA will be folded into
> the JDK project in JBS.
>

What about the Scene Builder issues (DTL project in JavaFX JIRA)? Would
they also be migrated to JBS?

-- 
Anirvan

Re: JavaFX JIRA issues moving to JBS

[Ryan Jaeb]

My frustration isn't aimed at anyone on the list, so I hope it didn't seem
like that.

I don't usually post to the list, but I follow it enough to know that, once
we see an announcement like the one Kevin delivered, the decision has been
made and there's no going back.  If I've misinterpreted, I apologize.
Please correct me.

The thing that's particularly frustrating with this incident is that it's
going to have a predictable, negative impact on people like me who feel
like submitting bug reports is the most effect contribution we can make to
the JavaFX community.  Being told that we should engage the JBS folks after
the decision has been made isn't acceptable.  Whoever made the decision to
merge with JBS should already have engaged the JBS folks and advocated for
changes on behalf of the JavaFX community before the decision was
finalized.  The message Kevin delivered should have included the results of
that advocacy.

Regardless, what's done is done.  If we need to have someone engage the JBS
people to ask for policy changes, I think we'd do well to nominate whoever
made the original decision.  If they have enough influence to get a project
merged into the JBS, they're effort will be far more effective than that of
a random person from the community.

We've been told that Oracle wants to see more participation from the JavaFX
community.  This is an excellent opportunity for someone with a decision
making role at Oracle to take action and demonstrate to the community that
they're willing to help facilitate some of that participation.

Ryan Jaeb

On Wed, Apr 15, 2015 at 6:24 PM, Richard Bair 
wrote:

> > Why can't an effort be made to influence JBS policies before making the
> switch?
>
> I think the way to do this is to engage the JBS folks on their alias, I
> don’t think they watch this one and Kevin doesn’t have the ability to
> change this policy. He’s just the messenger!
>
> Richard

Re: JavaFX JIRA issues moving to JBS

[Richard Bair]

> Why can't an effort be made to influence JBS policies before making the 
> switch?

I think the way to do this is to engage the JBS folks on their alias, I don’t 
think they watch this one and Kevin doesn’t have the ability to change this 
policy. He’s just the messenger!

Richard

[9, 8u60] review request for RT-40533 - rendering overhead for small shapes in Canvas

[Jim Graham]

Jira: https://javafx-jira.kenai.com/browse/RT-40533
webrev: http://cr.openjdk.java.net/~flar/RT-40533/webrev.02/

(note that this latest webrev is generated against 9-dev and has a few 
lines/names/copyrights cleaned up, but no change in the logic...)


...jim

Re: Updating JavaFX BarChart data causes memory leak?

[Jonathan Giles]

You don't mention what version of JavaFX you are using. Assuming you 
have tested this issue against 8u40 and / or 8u60 EA builds, and if the 
issue persists, then yes, please file an issue in Jira.


Thanks,

-- Jonathan

On 15/04/2015 11:53 p.m., Adam Granger wrote:

Hi, I've just asked this on stackoverflow, but I'm guessing someone from
this group might be able to help better... Should I raise a JIRA?

I've discovered what I believe is a memory leak in BarChart triggered by
replacing all the data values in the series. This is exasperated by our
application which does this several times a second.

Using `jvisualvm` shows an uncontrolled growth in the number of
javafx.scene.layout.StackPane instances which eventually results in an
OutOfMemoryError. Styled StackPane nodes are used internally by BarChart
for the bars.

I've tried a different strategies to update the list. All exhibit the same
issue.

 // 1
 series.getData().clear();
 series.getData().addAll(list);
 // 2
 series.getData().setAll(list);
 // 3
 series.setData(list)

Interestingly the example in the BarChart tutorial updates values by
adding all the points first, and then mutating using
XYChart.Data.setYValue(). This could work, but is not convenient for us as
the number of data points can vary dynamically.

Specific questions

  * Is there anyway to avoid this issue, other than a extra logic using the
setYValue() approach above.
  * Have I stumbled across an actual memory leak in JavaFX? or just an
artefact of my misuse of the API? Surely freeing internal nodes when data
is updated is JavaFX responsibility

Example

 public class ChartUpdate extends Application {
 private int clock;
 public static void main(String[] args) {
 launch(args);
 }
 @Override
 public void start(Stage stage) {
 CategoryAxis xAxis = new CategoryAxis();
 NumberAxis yAxis = new NumberAxis(0, 100, 10);
 yAxis.setAutoRanging(false);
 BarChart graph = new BarChart<>(xAxis, yAxis);
 graph.setAnimated(false);
 Series series = new Series<>();
 graph.getData().add(series);
 stage.setScene(new Scene(graph));
 stage.show();

 Timeline timeLine = new Timeline();
 timeLine.getKeyFrames().add(
 new KeyFrame(Duration.millis(500),
 (e) -> {
 ObservableList> list
= FXCollections.observableArrayList();
 for (int i = 0; i < 100; i++) {
 list.add(new Data<>(String.valueOf(i),
(clock + i) % 100));
 }
 series.setData(list);
 clock++;
 }));
 timeLine.setCycleCount(Animation.INDEFINITE);
 timeLine.play();
 }
 }

Re: JavaFX JIRA issues moving to JBS

[Fabrizio Giudici]

On Wed, 15 Apr 2015 18:31:56 +0200, Ryan Jaeb  wrote:


If someone submits a decent quality bug report to the forum, they could  
be

invited to use JBA. ...
You could probably even come up with a strategy for letting the community
nominate people for JBS invites so the developers wouldn't have to sift
through the forums looking for users that would make good JBS  
participants.


Good points.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it

Re: JavaFX JIRA issues moving to JBS

[Ryan Jaeb]

I will also add a suggestion that I think would be reasonable.  Take
advantage of the OTN forum.  Anyone without a JBS account could be asked to
post their first bug report to the forum.  If it's not a bug, the forum
community can help with the issue.  The forum community can also help
people learn to write a good bug report.

If someone submits a decent quality bug report to the forum, they could be
invited to use JBA.  The threshold could be more than one good bug report
to the forum if needed.  That gives new users and entry point into the
community and it filters out most of the noise on the actual bug tracker.

You could probably even come up with a strategy for letting the community
nominate people for JBS invites so the developers wouldn't have to sift
through the forums looking for users that would make good JBS participants.

Ryan Jaeb



On Wed, Apr 15, 2015 at 10:03 AM, Fabrizio Giudici <
fabrizio.giud...@tidalwave.it> wrote:

> On Wed, 15 Apr 2015 17:55:19 +0200, Robert Krüger 
> wrote:
>
>  Understandable. IMHO a certain "seriousness threshold" to reduce the noise
>> makes sense.
>>
>
> I was thinking on a score system such as the one at StackOverflow, but I'm
> not aware of any support of Atlassian.
>
>  What if you at least had a policy where someone in your team
>> can propose people they know from the mailing list for a while for
>> accounts? I don't think what's needed is to have a completely open system
>> with one-click self-registration but don't draw the line where you draw it
>> now, which means you're missing qualified input from people who are ready
>> to invest qualified time (e.g. to build test cases and good descriptions
>> of
>> issues) but do not submit patches.
>>
>
> I would add that having a corporate collective account could probably
> help. I'm thinking of a case in which there are a couple of dozen
> developers from the same corporate that could share the same email alias.
> Even in this case self-subscribing wouldn't be needed, actually it might
> make sense to have a control process to be sure that the corporate account
> is official, I mean the corporate is in charge for it.
>
>
> --
> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
> "We make Java work. Everywhere."
> http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
>

Re: JavaFX JIRA issues moving to JBS

[Fabrizio Giudici]

On Wed, 15 Apr 2015 17:55:19 +0200, Robert Krüger   
wrote:


Understandable. IMHO a certain "seriousness threshold" to reduce the  
noise

makes sense.


I was thinking on a score system such as the one at StackOverflow, but I'm  
not aware of any support of Atlassian.



What if you at least had a policy where someone in your team
can propose people they know from the mailing list for a while for
accounts? I don't think what's needed is to have a completely open system
with one-click self-registration but don't draw the line where you draw  
it

now, which means you're missing qualified input from people who are ready
to invest qualified time (e.g. to build test cases and good descriptions  
of

issues) but do not submit patches.


I would add that having a corporate collective account could probably  
help. I'm thinking of a case in which there are a couple of dozen  
developers from the same corporate that could share the same email alias.  
Even in this case self-subscribing wouldn't be needed, actually it might  
make sense to have a control process to be sure that the corporate account  
is official, I mean the corporate is in charge for it.



--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it

Re: JavaFX JIRA issues moving to JBS

[Darryl R]

What are the chances more open access policies will really be implemented? It 
sounds to me like they really won't so it will cut off input from most people. 
Costs will go down yes but unreported bugs will go up and users will have much 
less sense of really being involved.






On Wed, Apr 15, 2015 at 8:57 AM -0700, "Ryan Jaeb"  wrote:










Keep in mind the cost cutting is going to be exaggerated and it's going to
be difficult to measure any long term damage this change will have on the
JavaFX community.  People like me are going to stop participating.
There'll be fewer bug reports, it's going to take fewer people to manage
the bug load, and fewer developers to fix bugs.  Of course that's going to
translate into additional savings.  Plus, someone's going to get praised
for cutting costs while improving reliability.  The reality is JavaFX will
end up with more undiscovered bugs.

Why can't an effort be made to influence JBS policies before making the
switch?  My concern is that once the cost savings of the switch have been
realized, there's going to be no incentive to re-include people like me.  I
completely understand the justification for merging with JBS, but I'm
extremely frustrated that Oracle hasn't considered the impact an immediate
switch will have on the community.  This is a predictable transition and
there's no excuse for failing to come up with a solution that doesn't
alienate existing participants before making the change.

Ryan Jaeb


On Wed, Apr 15, 2015 at 8:54 AM, Richard Bair 
wrote:

> Hi everybody,
>
> Moving to JBS is both good and bad. The good:
>
>- Reduce costs associated with the project
>- Reduce internal overhead for development processes (everybody on
>Java uses JBS for everything so having a second JIRA makes everything
>harder with release management, management, even engineers who have to
>switch from one to the other)
>- JBS has dedicated engineering for support and maintenance, upgrades,
>etc
>- Making OpenJFX more of a core component of OpenJDK
>- Issues can be indexed on Google etc. (no account required to view
>issues)
>
>
> The bad:
>
>- Contributing is hard (nay, impossible?) if you are not at least an
>OpenJDK Author
>
>
> This last bullet is a huge problem IMO and the reason why we didn’t roll
> out a migration to JBS 1-2 years ago. But that is an OpenJDK policy issue,
> and all we can do is raise the issue and voice support for a more lenient
> policy. I actually don’t know if bugs.java.com allows you to comment on
> your own bug, but I don’t think it does. What happens if you file a bug and
> the dev cannot reproduce? Or they need more info? How do you add more info?
> I’m not even sure this is possible without emailing the engineer directly.
>
> From what I see, JBS still doesn't support self-creation of accounts.
>
>
> This is correct. The only way for people to file issues freely is through
> bugs.java.com
>
> perhaps I can ask for one and perhaps Oracle would grant one (to be
> verified).
>
>
> I am certain you could get one, you’ve been an active member of the
> community for a long time.
>
> But I don't think this would apply for a common employee of a corporate
> that, among other things, also develops in Java; not mentioning that not
> having the possibility of instantly signing in is not good, and would
> discourage almost everybody I know. The "bridge" offered by bugs.sun.com
> is cumbersome too. In any case, this is completely different from any other
> FLOSS project around, where access to the issue tracker is immediate and
> easy.
>
>
> I agree.
>
> I understand that, being Java so popular, Oracle might fear some kind of
> massive, low-level posting of issues, that would be expensive to manage. If
> this is the case, let's discuss it.
>
>
> This is exactly the issue. We know from the last 20 years that in fact we
> get a huge amount of completely bogus bugs that get filed via
> bugs.java.com (previously bugs.sun.com). Wild stuff from end users like
> “I can’t reboot my computer” and so forth. The concern with JBS (as I
> understand it) was that we’d end up with 10’s or 100,000’s of thousands of
> user accounts, many of which would be one-shot submitters associated with
> bogus issues.
>
> One solution would be if Atlasssian had some kind of “guest” mode where
> submitter accounts could be created but they would not show up in lists for
> things like assignees etc so they don’t clutter other views. Another
> solution could be to have a system whereby anybody who submits a good issue
> through bugs.java.com would get an email allowing them to sign up on JBS
> if they had an issue.
>
> Or, maybe the concern is actually not a problem — since Applets etc would
> point towards bugs.java.com, the only people (hopefully) coming to JBS
> are serious developers, the doors could be opened.
>
> Dalibor would probably know the right alias to discuss the JBS policy, and
> I do believe, personally, that the polic

Re: JavaFX JIRA issues moving to JBS

[Ryan Jaeb]

Keep in mind the cost cutting is going to be exaggerated and it's going to
be difficult to measure any long term damage this change will have on the
JavaFX community.  People like me are going to stop participating.
There'll be fewer bug reports, it's going to take fewer people to manage
the bug load, and fewer developers to fix bugs.  Of course that's going to
translate into additional savings.  Plus, someone's going to get praised
for cutting costs while improving reliability.  The reality is JavaFX will
end up with more undiscovered bugs.

Why can't an effort be made to influence JBS policies before making the
switch?  My concern is that once the cost savings of the switch have been
realized, there's going to be no incentive to re-include people like me.  I
completely understand the justification for merging with JBS, but I'm
extremely frustrated that Oracle hasn't considered the impact an immediate
switch will have on the community.  This is a predictable transition and
there's no excuse for failing to come up with a solution that doesn't
alienate existing participants before making the change.

Ryan Jaeb


On Wed, Apr 15, 2015 at 8:54 AM, Richard Bair 
wrote:

> Hi everybody,
>
> Moving to JBS is both good and bad. The good:
>
>- Reduce costs associated with the project
>- Reduce internal overhead for development processes (everybody on
>Java uses JBS for everything so having a second JIRA makes everything
>harder with release management, management, even engineers who have to
>switch from one to the other)
>- JBS has dedicated engineering for support and maintenance, upgrades,
>etc
>- Making OpenJFX more of a core component of OpenJDK
>- Issues can be indexed on Google etc. (no account required to view
>issues)
>
>
> The bad:
>
>- Contributing is hard (nay, impossible?) if you are not at least an
>OpenJDK Author
>
>
> This last bullet is a huge problem IMO and the reason why we didn’t roll
> out a migration to JBS 1-2 years ago. But that is an OpenJDK policy issue,
> and all we can do is raise the issue and voice support for a more lenient
> policy. I actually don’t know if bugs.java.com allows you to comment on
> your own bug, but I don’t think it does. What happens if you file a bug and
> the dev cannot reproduce? Or they need more info? How do you add more info?
> I’m not even sure this is possible without emailing the engineer directly.
>
> From what I see, JBS still doesn't support self-creation of accounts.
>
>
> This is correct. The only way for people to file issues freely is through
> bugs.java.com
>
> perhaps I can ask for one and perhaps Oracle would grant one (to be
> verified).
>
>
> I am certain you could get one, you’ve been an active member of the
> community for a long time.
>
> But I don't think this would apply for a common employee of a corporate
> that, among other things, also develops in Java; not mentioning that not
> having the possibility of instantly signing in is not good, and would
> discourage almost everybody I know. The "bridge" offered by bugs.sun.com
> is cumbersome too. In any case, this is completely different from any other
> FLOSS project around, where access to the issue tracker is immediate and
> easy.
>
>
> I agree.
>
> I understand that, being Java so popular, Oracle might fear some kind of
> massive, low-level posting of issues, that would be expensive to manage. If
> this is the case, let's discuss it.
>
>
> This is exactly the issue. We know from the last 20 years that in fact we
> get a huge amount of completely bogus bugs that get filed via
> bugs.java.com (previously bugs.sun.com). Wild stuff from end users like
> “I can’t reboot my computer” and so forth. The concern with JBS (as I
> understand it) was that we’d end up with 10’s or 100,000’s of thousands of
> user accounts, many of which would be one-shot submitters associated with
> bogus issues.
>
> One solution would be if Atlasssian had some kind of “guest” mode where
> submitter accounts could be created but they would not show up in lists for
> things like assignees etc so they don’t clutter other views. Another
> solution could be to have a system whereby anybody who submits a good issue
> through bugs.java.com would get an email allowing them to sign up on JBS
> if they had an issue.
>
> Or, maybe the concern is actually not a problem — since Applets etc would
> point towards bugs.java.com, the only people (hopefully) coming to JBS
> are serious developers, the doors could be opened.
>
> Dalibor would probably know the right alias to discuss the JBS policy, and
> I do believe, personally, that the policy is too restrictive and
> discourages cooperation and needs to be changed. But I also think moving to
> JBS is a good thing for a bunch of other reasons (and cost cutting can’t be
> ignored) and actually I’m looking forward to the ability to browse issues
> without having to get an account (not like I don’t have an account, but I
> mean for all the

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Wed, Apr 15, 2015 at 4:54 PM, Richard Bair 
wrote:

> Hi everybody,
>
> Moving to JBS is both good and bad. The good:
>


> The bad:
>
>- Contributing is hard (nay, impossible?) if you are not at least an
>OpenJDK Author
>
>
>
That's really the only (and serious) aspect anyone is complaining about
IIRC. Having everything in one Jira instance does of course make sense.


> This is exactly the issue. We know from the last 20 years that in fact we
> get a huge amount of completely bogus bugs that get filed via
> bugs.java.com (previously bugs.sun.com). Wild stuff from end users like
> “I can’t reboot my computer” and so forth. The concern with JBS (as I
> understand it) was that we’d end up with 10’s or 100,000’s of thousands of
> user accounts, many of which would be one-shot submitters associated with
> bogus issues.
>
>
Understandable. IMHO a certain "seriousness threshold" to reduce the noise
makes sense. What if you at least had a policy where someone in your team
can propose people they know from the mailing list for a while for
accounts? I don't think what's needed is to have a completely open system
with one-click self-registration but don't draw the line where you draw it
now, which means you're missing qualified input from people who are ready
to invest qualified time (e.g. to build test cases and good descriptions of
issues) but do not submit patches.


> One solution would be if Atlasssian had some kind of “guest” mode where
> submitter accounts could be created but they would not show up in lists for
> things like assignees etc so they don’t clutter other views. Another
> solution could be to have a system whereby anybody who submits a good issue
> through bugs.java.com would get an email allowing them to sign up on JBS
> if they had an issue.
>

Yes, something like that would address at least my concerns.


>
> Or, maybe the concern is actually not a problem — since Applets etc would
> point towards bugs.java.com, the only people (hopefully) coming to JBS
> are serious developers, the doors could be opened.
>
> Dalibor would probably know the right alias to discuss the JBS policy, and
> I do believe, personally, that the policy is too restrictive and
> discourages cooperation and needs to be changed. But I also think moving to
> JBS is a good thing for a bunch of other reasons (and cost cutting can’t be
> ignored) and actually I’m looking forward to the ability to browse issues
> without having to get an account (not like I don’t have an account, but I
> mean for all the folks out there who just want to see the issues :-)).
>
>
Your response gives me some hope that you take the feedback seriously. This
is a big thing. Please don't disappoint us by letting this discussion fade
into nirvana without anything being done about that.

Re: JavaFX JIRA issues moving to JBS

[dalibor topic]

On 15.04.2015 04:58, Stefan Fuchs wrote:

So my question is, how does the web frontend process work at oracle?


Quoting from https://wiki.openjdk.java.net/display/general/JBS+Overview

"At the time of launch, self-service account creation is not supported. 
Users without an account can browse JBS anonymously or use bugs.sun.com 
to view a time-delayed and simplified snapshot of bug state. Users 
without an account can also use bugs.sun.com to submit an issue. When 
such an issue is submitted, a record is created in the Java Incidents 
(JI) project in JBS; at the time of launch, the JI project is not 
publicly visible. Issues in the JI project have an identifier like 
JI-9XX, where the numeric portion corresponds to the bug identifier 
sent back to the submitter. After an initial triage process, if the 
incidents needs further review, it can be transferred to be an issue in 
the JDK project. When such a transfer occurs, the issue gets a new 
identifier in the JDK project (JDK-8YY) but references to the 
original JI-9XX number will be redirected."



Can I somewhere look up the status of an review or incident report?


You can browse to https://bugs.openjdk.java.net/browse/JI-9XX and if 
an incident report has been triaged and transferred, you will be 
redirected to https://bugs.openjdk.java.net/browse/JDK-8YY .



Is there an escalation level?


Quoting from http://bugs.java.com/ :

"Please note that fixes for bug reports are not guaranteed through this 
channel.
For bugs that require immediate and personal attention, Oracle offers 
Java SE

Support. Support customers should report bugs through My Oracle Support. "


One last question about the migration. I have several bugs on my
watchlist. Will I continue to receive update notifications for this bugs
after the migration?


See https://robilad.livejournal.com/139637.html

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: JavaFX JIRA issues moving to JBS

[dalibor topic]

On 15.04.2015 16:54, Richard Bair wrote:


Dalibor would probably know the right alias to discuss the JBS policy


Quoting from https://wiki.openjdk.java.net/display/general/JBS+Overview :

"General questions about JBS can be sent to disc...@openjdk.java.net.

Feature requests for JBS itself can be sent to o...@openjdk.java.net."

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: JavaFX JIRA issues moving to JBS

[Richard Bair]

Hi everybody,

Moving to JBS is both good and bad. The good:
Reduce costs associated with the project
Reduce internal overhead for development processes (everybody on Java uses JBS 
for everything so having a second JIRA makes everything harder with release 
management, management, even engineers who have to switch from one to the other)
JBS has dedicated engineering for support and maintenance, upgrades, etc
Making OpenJFX more of a core component of OpenJDK
Issues can be indexed on Google etc. (no account required to view issues)

The bad:
Contributing is hard (nay, impossible?) if you are not at least an OpenJDK 
Author

This last bullet is a huge problem IMO and the reason why we didn’t roll out a 
migration to JBS 1-2 years ago. But that is an OpenJDK policy issue, and all we 
can do is raise the issue and voice support for a more lenient policy. I 
actually don’t know if bugs.java.com  allows you to 
comment on your own bug, but I don’t think it does. What happens if you file a 
bug and the dev cannot reproduce? Or they need more info? How do you add more 
info? I’m not even sure this is possible without emailing the engineer directly.

> From what I see, JBS still doesn't support self-creation of accounts.

This is correct. The only way for people to file issues freely is through 
bugs.java.com

> perhaps I can ask for one and perhaps Oracle would grant one (to be verified).

I am certain you could get one, you’ve been an active member of the community 
for a long time.

> But I don't think this would apply for a common employee of a corporate that, 
> among other things, also develops in Java; not mentioning that not having the 
> possibility of instantly signing in is not good, and would discourage almost 
> everybody I know. The "bridge" offered by bugs.sun.com is cumbersome too. In 
> any case, this is completely different from any other FLOSS project around, 
> where access to the issue tracker is immediate and easy.

I agree.

> I understand that, being Java so popular, Oracle might fear some kind of 
> massive, low-level posting of issues, that would be expensive to manage. If 
> this is the case, let's discuss it.

This is exactly the issue. We know from the last 20 years that in fact we get a 
huge amount of completely bogus bugs that get filed via bugs.java.com 
 (previously bugs.sun.com ). Wild 
stuff from end users like “I can’t reboot my computer” and so forth. The 
concern with JBS (as I understand it) was that we’d end up with 10’s or 
100,000’s of thousands of user accounts, many of which would be one-shot 
submitters associated with bogus issues.

One solution would be if Atlasssian had some kind of “guest” mode where 
submitter accounts could be created but they would not show up in lists for 
things like assignees etc so they don’t clutter other views. Another solution 
could be to have a system whereby anybody who submits a good issue through 
bugs.java.com  would get an email allowing them to sign 
up on JBS if they had an issue.

Or, maybe the concern is actually not a problem — since Applets etc would point 
towards bugs.java.com , the only people (hopefully) 
coming to JBS are serious developers, the doors could be opened.

Dalibor would probably know the right alias to discuss the JBS policy, and I do 
believe, personally, that the policy is too restrictive and discourages 
cooperation and needs to be changed. But I also think moving to JBS is a good 
thing for a bunch of other reasons (and cost cutting can’t be ignored) and 
actually I’m looking forward to the ability to browse issues without having to 
get an account (not like I don’t have an account, but I mean for all the folks 
out there who just want to see the issues :-)).

Cheers
Richard

Updating JavaFX BarChart data causes memory leak?

[Adam Granger]

Hi, I've just asked this on stackoverflow, but I'm guessing someone from
this group might be able to help better... Should I raise a JIRA?

I've discovered what I believe is a memory leak in BarChart triggered by
replacing all the data values in the series. This is exasperated by our
application which does this several times a second.

Using `jvisualvm` shows an uncontrolled growth in the number of
javafx.scene.layout.StackPane instances which eventually results in an
OutOfMemoryError. Styled StackPane nodes are used internally by BarChart
for the bars.

I've tried a different strategies to update the list. All exhibit the same
issue.

// 1
series.getData().clear();
series.getData().addAll(list);
// 2
series.getData().setAll(list);
// 3
series.setData(list)

Interestingly the example in the BarChart tutorial updates values by
adding all the points first, and then mutating using
XYChart.Data.setYValue(). This could work, but is not convenient for us as
the number of data points can vary dynamically.

Specific questions

 * Is there anyway to avoid this issue, other than a extra logic using the
setYValue() approach above.
 * Have I stumbled across an actual memory leak in JavaFX? or just an
artefact of my misuse of the API? Surely freeing internal nodes when data
is updated is JavaFX responsibility

Example

public class ChartUpdate extends Application {
private int clock;
public static void main(String[] args) {
launch(args);
}
@Override
public void start(Stage stage) {
CategoryAxis xAxis = new CategoryAxis();
NumberAxis yAxis = new NumberAxis(0, 100, 10);
yAxis.setAutoRanging(false);
BarChart graph = new BarChart<>(xAxis, yAxis);
graph.setAnimated(false);
Series series = new Series<>();
graph.getData().add(series);
stage.setScene(new Scene(graph));
stage.show();

Timeline timeLine = new Timeline();
timeLine.getKeyFrames().add(
new KeyFrame(Duration.millis(500),
(e) -> {
ObservableList> list
= FXCollections.observableArrayList();
for (int i = 0; i < 100; i++) {
list.add(new Data<>(String.valueOf(i),
(clock + i) % 100));
}
series.setData(list);
clock++;
}));
timeLine.setCycleCount(Animation.INDEFINITE);
timeLine.play();
}
}

Re: JavaFX JIRA issues moving to JBS

[Knut Arne Vedaa]

Kevin Rushforth wrote:


A JBS account will be needed to directly report new bugs or comment on
existing bugs. Most application developers will file new JavaFX bugs at
bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
account [4] is to have a role of Author or higher in an OpenJDK Project
(e.g., jdk9 or openjfx).


In my humble opinion this sounds like a very, very bad idea. I could 
rant on, but Ryan Jaeb has described it well and I completely agree with 
him.


Undoubtly, if you go ahead with this, there will be a lot less bug 
reports. You are basically alienating the community.


And it's not just about bugs. If you have to be an author in order to 
comment, this kind of discourse: 
https://javafx-jira.kenai.com/browse/RT-12643 will be a thing of the past.



Knut Arne Vedaa

[9] request for review: RT-37859 VM crash when call a method from within javascript code present in a page loaded in webEngine

[Anton Tarasov]

Hi Kevin, Vadim,

Please have a look at the following fix in WebKit bridge/jni/jsc code:

JIRA: https://javafx-jira.kenai.com/browse/RT-37859
webrev: http://cr.openjdk.java.net/~ant/RT-37859/webrev.0

Thanks,
Anton.

Re: JavaFX JIRA issues moving to JBS

[Fabrizio Giudici]

I had not realized that ...


Just be safe that everybody here is aligned to the focus of the  
discussion... As I previously said, I think the problem lies with the  
access policy. From the JBS official page:




Account Eligibility
OpenJDK Roles, Groups, and Projects are explained in the OpenJDK Bylaws.  
This JBS guide will use terms defined in the bylaws; the bylaws should be  
consulted for details.


An individual with at least one OpenJDK Project role of Author or higher  
has sufficient cause to get a JBS account. A JBS account grants an  
individual general read and write access to issues, including the ability  
to file new issues, transitioning issues among the states of the workflow,  
adding comments, changing field values (including adding and removing  
labels). The holder of a JBS account can also be the assignee of an issue.


A user's JBS username is his or her OpenJDK name. The password reset page  
can be used both to reset a lost password and to establish a an initial  
password.


At the time of launch, self-service account creation is not supported.  
Users without an account can browse JBS anonymously or use bugs.sun.com to  
view a time-delayed and simplified snapshot of bug state. Users without an  
account can also use bugs.sun.com to submit an issue. When such an issue  
is submitted, a record is created in the Java Incidents (JI) project in  
JBS; at the time of launch, the JI project is not publicly visible. Issues  
in the JI project have an identifier like JI-9XX, where the numeric  
portion corresponds to the bug identifier sent back to the submitter.  
After an initial triage process, if the incidents needs further review, it  
can be transferred to be an issue in the JDK project. When such a transfer  
occurs, the issue gets a new identifier in the JDK project (JDK-8YY)  
but references to the original JI-9XX number will be redirected.





There are a few points to discuss, and sure everybody has his own  
priority. For me, one of the most important ones is the capability to  
comment. For instance, today I can go here (issue picked at random)  
https://javafx-jira.kenai.com/browse/RT-30705 and add a comment, because  
perhaps I've run into the issue and I have something to add. If I don't  
have an account, because it's my first time, I can istantly create one at  
Kenai. I have a few customers using JavaFX (as well as many other FLOSS  
projects) and sometimes they run into an issue; I encourage them to  
directly login and report/comment.


From what I see, JBS still doesn't support self-creation of accounts. I  
don't have one, if I remember well, because I don't have any role in  
OpenJDK projects. For the kind of job I do, that is a consultant focused  
on Java, perhaps I can ask for one and perhaps Oracle would grant one (to  
be verified). But I don't think this would apply for a common employee of  
a corporate that, among other things, also develops in Java; not  
mentioning that not having the possibility of instantly signing in is not  
good, and would discourage almost everybody I know. The "bridge" offered  
by bugs.sun.com is cumbersome too. In any case, this is completely  
different from any other FLOSS project around, where access to the issue  
tracker is immediate and easy.


I think this expands the point that some earlier mentioned about being a  
"user" vs a "developer" of OpenJDK.


I understand that, being Java so popular, Oracle might fear some kind of  
massive, low-level posting of issues, that would be expensive to manage.  
If this is the case, let's discuss it.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Wed, Apr 15, 2015 at 8:53 AM, Ryan Jaeb  wrote:

> Do you guys have an estimate for the percentage of current JIRA
> contributors that will no longer be able to participate, in a meaningful
> way, in bug reporting due to this change?  I can't speak for anyone else,
> but I can tell you what a switch to JBS means to me.
>
> I consider myself an OpenJFX user, not an OpenJFX developer.  I contribute
> bug reports, but not patches.  I haven't contributed a ton of bug reports
> (22), but every time I run into a bug I take extra time to isolate the
> issue, create a reproducible example, and file a bug.  I'm careful to be
> polite, honest if I make any mistakes, and I make an effort to follow up
> whenever there's activity on a bug I've reported.
>
> The current bug tracker is a good value proposition for me.  My effort has
> a direct impact on having bugs that I discover fixed, it's easy for me to
> comment on bugs when I feel like I have useful input, I get to vote on all
> the bugs that affect me, and, most importantly, the discussion on many bug
> reports often leads to an acceptable workaround until the bug can be fixed.
>
> Conversely, contributing via JBS is not a good value proposition for me.  I
> won't have an author role, I won't get to comment on bugs, and I won't get
> to vote on bugs.  The process for me to participate is more cumbersome and
> bureaucratic and is going to be far less meaningful than the participation
> that I've become accustomed to with the existing bug tracking system.
>
> Why should I participate in a system where my contributions don't even
> warrant a vote on existing bugs?  Once the switch to JBS happens I'll stop
> reporting minor bugs.  The hassle of using JBS means I'm only going to make
> an effort when I run into a major, showstopping bug.  I don't intend to
> sound like I'm throwing a tantrum.  I'm simply being honest.
>
> For a normal user like me, JBS doesn't make contributing easier, it makes
> it harder.  It doesn't communicate appreciation to small contributors, it
> alienates us.  It's not inviting to new contributors, it's intimidating.
> These things may be ok for a large project like the OpenJDK and it may even
> help stack the bug tracker with veteran developers.  However, I don't think
> JavaFX is in a position to discourage anyone from participating.
>
> Please reconsider the decision to merge with JBS as it's going to have a
> significant, negative impact on normal users like me.


I had not realized that I would not be able to comment on my own or other
issues after this change. That is a major step back for me as well and my
role so far is very similar to Ryan's (I have not contributed code but I
have invested considerable amounts of time preparing bug reports with
reproducible test cases and aiding Oracle devs by adding comments when
requested).

So I am totally with Ryan and Tobias on this. Very bad news.

Re: JavaFX JIRA issues moving to JBS

[Mario Torre]

I think the confusing part of Kevin's mail was the "file to bugs.java.com" bit.

I think he meant for customers who already file bugs report to the
shipped-with-Oracle idk version of JavaFX, not the same OpenJFX we
discuss here.

OpenJFX bugs will be directed to the JIRA based https://bugs.openjdk.java.net/

Kevin, is that right, did I understand you correctly?

Cheers,
Mario

2015-04-15 10:08 GMT+02:00 Mario Torre :
> 2015-04-15 8:32 GMT+02:00 Tobias Bley :
>> Hi,
>>
>> in my opinion it’s definitely no good news to move from JIRA to JBS. While 
>> Jira is a very good and popular bug tracking system, the JDK JBS is a pain. 
>> With JBS the community efforts will decrease. It’s too complicated to be 
>> part of the Java community if you are forced to first sign a commitment… 
>> It’s a step backward :( Like other decisions like stop of SceneBuilder 
>> builds, no official mobile ports and so on. Sorry, I’m very disappointed of 
>> the current strategy of Oracle.
>
> JBS for OpenJDK *is* JIRA:
>
> https://bugs.openjdk.java.net/
>
>> I still hope that I am wrong…
>>
>> Best regards,
>> Tobi
>>
>>
>>> Am 15.04.2015 um 00:20 schrieb Kevin Rushforth :
>>>
>>> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The JDK 
>>> Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK Community. 
>>> With the OpenJFX Project being a part of this Community, it is time for us 
>>> to move away from our separate bug tracker and make use of JBS. This will 
>>> allow us to leverage the greater infrastructure investments being made and 
>>> lessen the burden of having to maintain our own infrastructure, and 
>>> consolidates all JDK bugs in one place. The target date for this transition 
>>> is the second half of May.
>>>
>>> The issues currently in the RT project in JavaFX JIRA will be folded into 
>>> the JDK project in JBS. Details will follow on the mapping, but here are 
>>> the highlights:
>>>
>>> - A new "javafx" component will be created in the JDK project
>>> - Most existing JavaFX JIRA components will be sub-components of the 
>>> "javafx" component
>>> - The mapping from existing "RT-n" bug ID to new "JDK-mmm" bug ID 
>>> will be maintained by JBS such that searching for RT-n will take you to 
>>> the right JDK-mmm bug.
>>>
>>> A JBS account will be needed to directly report new bugs or comment on 
>>> existing bugs. Most application developers will file new JavaFX bugs at 
>>> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS 
>>> account [4] is to have a role of Author or higher in an OpenJDK Project 
>>> (e.g., jdk9 or openjfx).
>>>
>>> Our advice to those of you actively involved and participating in the 
>>> OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by 
>>> signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary 
>>> first step in contributing to any OpenJDK Project, including OpenJFX. It 
>>> allows you to provide patches that we might accept for OpenJFX, and is also 
>>> a step along the path to becoming an Author. The general guideline [7] is 
>>> that the Author role may be requested by a Project Contributor who has 
>>> contributed two non-trivial patches that have been accepted and pushed.
>>>
>>> As part of this transition, we will enable anonymous viewing of bugs (no 
>>> need to login just to look at a bug) and they will be easily searchable 
>>> online.
>>>
>>> We apologize for the inconvenience caused to OpenJFX Participants by this 
>>> upcoming change to the bug database write access policy. We really 
>>> appreciate your commitment to improving and growing the JavaFX technology.
>>>
>>> -- Kevin
>>>
>>>
>>> [1] https://javafx-jira.kenai.com/
>>> [2] https://bugs.openjdk.java.net/
>>> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
>>> [3] http://bugs.java.com/
>>> [5] http://openjdk.java.net/contribute/
>>> [6] http://www.oracle.com/technetwork/oca-405177.pdf
>>> [7] http://openjdk.java.net/projects/#project-author
>>>
>>
>
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: JavaFX JIRA issues moving to JBS

[Fabrizio Giudici]

On Wed, 15 Apr 2015 09:49:09 +0200, Tom Eugelink  wrote:


I do not understand these doubts, JBS is Jira?!

https://wiki.openjdk.java.net/display/general/JBS+Overview
/The JDK bug system (JBS) ... is a JIRA instance which provides bug  
tracking for Projects in the OpenJDK/


I think that this is clear to everybody. The point is that Jira is  
extremely flexible in configuring access policies and two instances can be  
very different in terms of usability. With Jira/JBS I was referring to the  
two instances and their currently configured access policies. A few people  
pointed out in the previous emails about these differences.


In other words, consolidating to JBS is fine: but, as many expressed  
doubts, does it mean that the JavaFX component will be subject to the same  
configuration of JBS? Or is it possible to have its access policy, as a  
component, to stay the same? What about having the access policy of JBS  
more open, such as the current JIRA for OpenJFX?


I suppose these are more legal issues, or internal Oracle policy issues,  
than technical issues.


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it

Re: JavaFX JIRA issues moving to JBS

[Mario Torre]

2015-04-15 8:32 GMT+02:00 Tobias Bley :
> Hi,
>
> in my opinion it’s definitely no good news to move from JIRA to JBS. While 
> Jira is a very good and popular bug tracking system, the JDK JBS is a pain. 
> With JBS the community efforts will decrease. It’s too complicated to be part 
> of the Java community if you are forced to first sign a commitment… It’s a 
> step backward :( Like other decisions like stop of SceneBuilder builds, no 
> official mobile ports and so on. Sorry, I’m very disappointed of the current 
> strategy of Oracle.

JBS for OpenJDK *is* JIRA:

https://bugs.openjdk.java.net/

> I still hope that I am wrong…
>
> Best regards,
> Tobi
>
>
>> Am 15.04.2015 um 00:20 schrieb Kevin Rushforth :
>>
>> As most of you are aware, JavaFX uses its own JIRA bug tracker [1]. The JDK 
>> Bug System [2] (JBS) is the JIRA bug tracker used by the OpenJDK Community. 
>> With the OpenJFX Project being a part of this Community, it is time for us 
>> to move away from our separate bug tracker and make use of JBS. This will 
>> allow us to leverage the greater infrastructure investments being made and 
>> lessen the burden of having to maintain our own infrastructure, and 
>> consolidates all JDK bugs in one place. The target date for this transition 
>> is the second half of May.
>>
>> The issues currently in the RT project in JavaFX JIRA will be folded into 
>> the JDK project in JBS. Details will follow on the mapping, but here are the 
>> highlights:
>>
>> - A new "javafx" component will be created in the JDK project
>> - Most existing JavaFX JIRA components will be sub-components of the 
>> "javafx" component
>> - The mapping from existing "RT-n" bug ID to new "JDK-mmm" bug ID 
>> will be maintained by JBS such that searching for RT-n will take you to 
>> the right JDK-mmm bug.
>>
>> A JBS account will be needed to directly report new bugs or comment on 
>> existing bugs. Most application developers will file new JavaFX bugs at 
>> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS 
>> account [4] is to have a role of Author or higher in an OpenJDK Project 
>> (e.g., jdk9 or openjfx).
>>
>> Our advice to those of you actively involved and participating in the 
>> OpenJFX Project is to consider joining the OpenJDK as a Contributor [5] by 
>> signing the Oracle Contributor Agreement (OCA) [6]. This is a necessary 
>> first step in contributing to any OpenJDK Project, including OpenJFX. It 
>> allows you to provide patches that we might accept for OpenJFX, and is also 
>> a step along the path to becoming an Author. The general guideline [7] is 
>> that the Author role may be requested by a Project Contributor who has 
>> contributed two non-trivial patches that have been accepted and pushed.
>>
>> As part of this transition, we will enable anonymous viewing of bugs (no 
>> need to login just to look at a bug) and they will be easily searchable 
>> online.
>>
>> We apologize for the inconvenience caused to OpenJFX Participants by this 
>> upcoming change to the bug database write access policy. We really 
>> appreciate your commitment to improving and growing the JavaFX technology.
>>
>> -- Kevin
>>
>>
>> [1] https://javafx-jira.kenai.com/
>> [2] https://bugs.openjdk.java.net/
>> [4] https://wiki.openjdk.java.net/display/general/JBS+Overview
>> [3] http://bugs.java.com/
>> [5] http://openjdk.java.net/contribute/
>> [6] http://www.oracle.com/technetwork/oca-405177.pdf
>> [7] http://openjdk.java.net/projects/#project-author
>>
>



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: JavaFX JIRA issues moving to JBS

[Tom Eugelink]

I do not understand these doubts, JBS is Jira?!

https://wiki.openjdk.java.net/display/general/JBS+Overview
/The JDK bug system (JBS) ... is a JIRA instance which provides bug tracking 
for Projects in the OpenJDK/


On 15-4-2015 09:42, Fabrizio Giudici wrote:

While consolidating the issue tracked is a plus, I share the doubts about the 
usability of JBS vs Jira. Why not going the opposite path :-) that is 
consolidating everything under Jira?

Re: JavaFX JIRA issues moving to JBS

[Fabrizio Giudici]

While consolidating the issue tracked is a plus, I share the doubts about  
the usability of JBS vs Jira. Why not going the opposite path :-) that is  
consolidating everything under Jira?


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Wed, Apr 15, 2015 at 12:20 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:
>
>
> A JBS account will be needed to directly report new bugs or comment on
> existing bugs. Most application developers will file new JavaFX bugs at
> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
> account [4] is to have a role of Author or higher in an OpenJDK Project
> (e.g., jdk9 or openjfx)
>

When I submit a bug there, will I be informed of the resulting Jira Issue
ID in JBS? That's crucial for tracking the things I submit. So far I have
perceived bugs.java.com as a black hole compared to the JFX jira.