hg: openjfx/8u-dev/rt: RT-35813 TabPane leaks memory if Tab Content is Replaced and the Tab is Never Viewed.
Changeset: c888fb474902 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-02-14 10:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c888fb474902 RT-35813 TabPane leaks memory if Tab Content is Replaced and the Tab is Never Viewed. Follow up fix in Parent. ! modules/graphics/src/main/java/javafx/scene/Parent.java
Result: New OpenJFX Committer: Victor Shubov
Voting for Victor Shubov [1] was closed on Nov 07, 2013, but the results were never announced. Here they are: Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-October/011103.html [2] http://openjdk.java.net/projects/#project-committer Thanks, Artem
hg: openjfx/8u-dev/rt: RT-35785: weak listener was getting reaped.
Changeset: c2e7de12fe81 Author:David Grievedavid.gri...@oracle.com Date: 2014-02-14 11:02 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c2e7de12fe81 RT-35785: weak listener was getting reaped. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java
IMPORTANT: Rampdown / stabilization of 8u20 for milestone M2
Hi OpenJFX committers, After this coming Monday's FX build, which will go into 8u20-b02, we will start ramping down for our M2 milestone build (aka 8u20-b03). This particular milestone is important for the embedded platform. As a result, you will need to observe the following rules for any commit. 1) Sunday, Feb 16 at 11:00 pm Pacific time: All planned changes for b02 should be in (our test build is scheduled to start at 11pm that day). The usual rules apply for changesets pushed prior to that time. 2) All changesets that are pushed after 11:00 pm Pacific time on Sunday, Feb 16 will need additional scrutiny to go in. In addition to your normal reviewer you must get a +1 from one of the following, even if you would normally do a post-commit review: Daniel Blaukopf Steve Northover Kevin Rushforth Lisa Selle 3) Monday, Feb 17: We will do our usual (In)Sanity Testing and then hand off the bits to release engineering for 8u20-b02. 4) Week of Feb 17 - 14: Bug fixes can go in subject to the extra approval noted above, but please hold off making any risky changes until after M2. 5) Sunday, Feb 23 at 11:00 pm Pacific time: We will do a soft freeze, during which time we will be locked except for critical issues discovered during testing, for b03 (milestone M2). 6) Monday, Feb 24: We will do our usual (In)Sanity Testing, with extra emphasis on testing anything that changed after b02, and then hand off the bits to release engineering for 8u20-b03. 7) I will send a subsequent announcement as to when the repo is open for normal business. Thank you. -- Kevin
Heads up... changing the rt/build/*sdk/ directory
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, we are
trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able to provide a
common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with, explained
here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A developer may
// have multiple SDK's on their system at any one time, depending on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
--
David Hill david.h...@oracle.com
Java Embedded Development
On a clear disk, you can seek forever.
Re: Heads up... changing the rt/build/*sdk/ directory
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809,
we are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be
able to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending
on which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into
'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
hg: openjfx/8u-dev/rt: RT-35400: [Win] Attempt to add Tab to TabPane crashes the VM
Changeset: 125d12ca7288 Author:Anthony Petrov anthony.pet...@oracle.com Date: 2014-02-14 23:29 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/125d12ca7288 RT-35400: [Win] Attempt to add Tab to TabPane crashes the VM Summary: Do not raise a COM error because of a Java exception ! modules/graphics/src/main/native-glass/win/GlassClipboard.cpp
hg: openjfx/8u-dev/rt: RT-35809 [BUILD] switch build/(host)-sdk to just build/sdk to help with apps build files
Changeset: 755652e72e11 Author:ddhill Date: 2014-02-14 13:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/755652e72e11 RT-35809 [BUILD] switch build/(host)-sdk to just build/sdk to help with apps build files Reviewed-by: kcr, ckyang ! apps/experiments/3DViewer/nbproject/project.properties ! apps/experiments/Modena/nbproject/project.properties ! apps/samples/Ensemble8/nbproject/project.properties ! apps/samples/MandelbrotSet/nbproject/project.properties ! apps/toys/FXSlideShow/build.xml ! apps/toys/FXSlideShow/nbproject/project.properties ! apps/toys/Hello/build.xml ! apps/toys/Hello/nbproject/project.properties ! build.gradle
OpenJFX Lambda Day, Feb 25th 2014
Hello all, Mark it on your calendar. Feb 25th is OpenJFX Lambda day. On that day, we will lock the code base, lambdify everything in sight, and then open up for business again. One thing that we won't be doing right away is converting our code to use streams and other JDK8 features but this is inevitable (perhaps after 8u20). We are part of the JDK, we ship with the JDK so we will use features from the JDK. Like Lambda's to the slaughter the Android and iOS ports of OpenJFX will be affected. We've been discussing the use of RetroLambda on and off in JIRA for a while and it seems that it will work for both ports. We care about these ports and it is possible that Lambda Day will slip for one reason or another. For one thing, the lambdifying tools blow up some of the source making lambda conversion a somewhat manual process. Hopefully we can get the bugs fixed before the day. On that day, I will be listening to 'The Lambda Lies Down on Broadway all day. Those of you with children might prefer Mary had a little Lambda. Despite being called The Lambda Police, I am and old Lisper and a card carrying member of the Knights of the Lambda Calculus. Look that one up. I know the founder personally but will never tell who it is. Steve
hg: openjfx/8u-dev/rt: RT-26314: Linux packaging tools assume rpm build is always available
Changeset: 17a6e1b4b091 Author:shemnon Date: 2014-02-14 16:38 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/17a6e1b4b091 RT-26314: Linux packaging tools assume rpm build is always available Summary: validate the version is 4.0 or greater, throw a config exception if it isn't. ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxDebBundler.java ! modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/LinuxRPMBundler.java ! modules/fxpackager/src/main/resources/com/oracle/bundlers/linux/LinuxRpmBundler.properties ! modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxRpmBundlerTest.java
Re: Heads up... changing the rt/build/*sdk/ directory
Are you guys using the NetBeans Gradle plugin?
Scott
On Fri, Feb 14, 2014 at 2:17 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:
Thanks David.
For NB 7.4 (or 8) users, you should be able to just open up the apps
projects in NB and have it work without needing to do anything extra.
-- Kevin
David Hill wrote:
As part of this Jira https://javafx-jira.kenai.com/browse/RT-35809, we
are trying to make working in rt/apps easier.
To do that, we found that the only way to make the IDEs happy is be able
to provide a common path to host build jfxrt.jar.
Currently we have:
rt/build/${hosttype}-sdk (rt/build/linux-sdk/...)
which requires evaluation that Netbeans does not want to do.
We do need to support cross builds, so here is what we came up with,
explained here in the new improved comment from build.gradle
// The jfxrt task is responsible for creating the jfxrt.jar. A
developer may
// have multiple SDK's on their system at any one time, depending on
which
// cross compiles they have done. For example, I might have:
// build/ios-sdk/rt/lib/ext/jfxrt.jar
// build/armhf-sdk/rt/lib/ext/jfxrt.jar
// and so forth. The default host build will always install into 'sdk'
// allowing for uses where a known sdk path is needed (like IDEs)
// build/sdk/rt/lib/ext/jfxrt.jar
// This arrangement allows for multiple independent SDKs to
// exist on a developer's system.
After you sync, you will probably want to perform a clean build.
And then try out the apps, in the new easier to use format.
Note: for now, you will still need to specify the JDK for ant/nb, like
this:
ant -Dplatforms.JDK_1.8.home=$JAVA_HOME
Re: OpenJFX Lambda Day, Feb 25th 2014
Classic post Steve :-) On 15 Feb 2014, at 10:35, Stephen F Northover steve.x.northo...@oracle.com wrote: Hello all, Mark it on your calendar. Feb 25th is OpenJFX Lambda day. On that day, we will lock the code base, lambdify everything in sight, and then open up for business again. One thing that we won't be doing right away is converting our code to use streams and other JDK8 features but this is inevitable (perhaps after 8u20). We are part of the JDK, we ship with the JDK so we will use features from the JDK. Like Lambda's to the slaughter the Android and iOS ports of OpenJFX will be affected. We've been discussing the use of RetroLambda on and off in JIRA for a while and it seems that it will work for both ports. We care about these ports and it is possible that Lambda Day will slip for one reason or another. For one thing, the lambdifying tools blow up some of the source making lambda conversion a somewhat manual process. Hopefully we can get the bugs fixed before the day. On that day, I will be listening to 'The Lambda Lies Down on Broadway all day. Those of you with children might prefer Mary had a little Lambda. Despite being called The Lambda Police, I am and old Lisper and a card carrying member of the Knights of the Lambda Calculus. Look that one up. I know the founder personally but will never tell who it is. Steve
