he better
choice as long as it isn't too intrusive / noisy.
-- Kevin
- Nir
On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
inline
On 5/2/2018 4:52 PM, Nir Lisker wrote:
Thanks Murali,
I won’t suggest read
On 5/3/2018 4:54 AM, Tom Schindl wrote:
Hi,
Following up on the native-libs-in-modules I wonder how we deal with
OSGi-Applications like Eclipse RCP.
Do OpenJFX-Binaries run only on the module-path or can they run on the
classpath as well. If they can run on the classpath, can they maybe
loade
of the WebView media
component so special that it justifies its own mechanism /
property. I doubt it, which is why removing the verbose flag
altogether seems the better choice as long as it isn't too
intrusive / noisy.
-- Kevin
- Nir
On Thu, May 3, 2018 at 3:31
Hi Johan,
I don't know whether this work at all, and it might be even more work
than what you are proposing, but a possible approach would be to create
a variant of the getToolkit method with a boolean indicating whether to
create/initialize the Toolkit instance, with a default of "false".
So
Thanks, Prasanta.
As an additional note to reviewers:
The JDK portion of this change (JDK-8202199) is the subject for this review.
The FX webrev is enough to be able to test the JDK side, but will need
additional refactoring (to allow it to continue to build / run with JDK
10) before being re
jdk.unsupported.desktop is defined to the application class loader
which I think it's fine as FX modules are defined to the same class
loader.
I noticed this, too, during my testing this morning. It still fails when
the security manager is enabled. We already have a bug filed for this:
ht
My quick comments:
1. The changes to java.desktop module-info.java won't compile when
applied to jdk-client, since there is already a qualified export of the
sun.swing package to another internal class. Can you update your patch
to be based off of jdk-client? I note that it requires a small pa
That name seems good to me.
-- Kevin
On 5/7/2018 8:01 AM, Prasanta Sadhukhan wrote:
Would InteropProviderImpl sound good?
Regards
Prasanta
On 5/7/2018 8:27 PM, Alan Bateman wrote:
On 07/05/2018 10:26, Prasanta Sadhukhan wrote:
:
Modified webrev to use InteropProvider
http://cr.openjdk.ja
I am pleased to announce the first Early Access build of a standalone
JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an
OpenJDK 11 EA build.
If your application is in an unnamed module (i.e., your app is on the
classpath), you can run your application as follows, after unzi
FYI...
-- Kevin
Forwarded Message
Subject: [11] RFR: 8202553: Update FXLauncherTest as part of removing
JavaFX from JDK
Date: Tue, 8 May 2018 08:15:48 -0700
From: Kevin Rushforth
To: core-libs-...@openjdk.java.net ,
Kumar Srinivasan
Please review the following
gt;> wrote:
Modified webrev to rename to InteropProviderImpl
http://cr.openjdk.java.net/~psadhukhan/fxswing.10/
<http://cr.openjdk.java.net/%7Epsadhukhan/fxswing.10/>
Regards
Prasanta
On 5/7/2018 8:35 PM, Kevin Rushforth wrote:
That name seems good to me.
Yes, adding the javafx-sdk-11/lib to the module-path is a required step.
Thanks.
-- Kevin
3. How do you properly configure an Eclipse (the latest 4.7.3a)
project to use this module path. Adding the OpenJDK was no problem but
how do you add the module path for JavaFX? I failed on that.
Michae
The module definition for jdk.unsupported.desktop and the changes to
java.desktop look fine.
In reviewing the jdk.swing.interop API, I have the following suggestions
/ observations:
1. DispatcherWrapper, DragSourceContextWrapper,
DropTargetContextWrapper, and LightweightContentWrapper can al
k.java.net/~psadhukhan/fxswing.11/
Regards
Prasanta
On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes to
java.desktop look fine.
In reviewing the jdk.swing.interop API, I have the following
suggestions / observations:
1. Dispatc
conversation is that it seems
doclint fail on warning must be disabled by default .. and I suppose that
is what we want here since documentation is minimal.
-phil.
On 5/9/18, 5:28 AM, Kevin Rushforth wrote:
The following can also be abstract:
LightweightContentWrapper:
st one; the others still need to be validated.
-- Kevin
On 5/9/2018 7:14 AM, Prasanta Sadhukhan wrote:
Modified webrev to cater to this
http://cr.openjdk.java.net/~psadhukhan/fxswing.12/
Regards
Prasanta
On 5/9/2018 5:58 PM, Kevin Rushforth wrote:
The following can also
8141391
<https://bugs.openjdk.java.net/browse/JDK-8141391> and #4 works for me.
Regards
Prasanta
On 5/9/2018 11:29 PM, Kevin Rushforth wrote:
Hi Prasanta,
The API looks good now.
All of our automated tests work (except for the ones with a security
manager due to JDK-8202451
<https://bugs.openjdk.jav
Please review the following build change to produce jmods for the
standalone FX SDK:
https://bugs.openjdk.java.net/browse/JDK-8202368
http://cr.openjdk.java.net/~kcr/8202368/webrev.00/
See the JBS issue for more details.
My plan is to get this in on Monday so it can be part of next week's
sta
Phil,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8201261
http://cr.openjdk.java.net/~kcr/8201261/webrev.00/
This adds support for two new gradle properties, JFX_DEPS_URL and
JDK_DOCS_LINK, replacing logic currently in the closed build. Details
are in JBS.
-- Kevin
Looks good.
+1
-- Kevin
On 5/15/2018 12:56 AM, Pankaj Bansal wrote:
Hi All,
Request to review this fix.
Webrev: http://cr.openjdk.java.net/~pbansal/8163795/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8163795
Regards,
Pankaj Ba
I wanted to update you on the progress of the last couple weeks on the
OpenJFX project:
1. As mentioned last week, we now have EA builds of OpenJFX 11 on
java.net [1]. We intend to update this roughly weekly. Currently the
build numbers match the corresponding JDK build number, but that will
On 5/15/2018 11:57 PM, Ty Young wrote:
3. JavaFX has been removed from JDK 11 as of this week. Starting with
jdk-11+14, early access builds of JDK 11 will not include JavaFX.
I'm not sure if it's intentional or perhaps a bug on my end, but I
cannot compile JavaFX without Oracle JDK(9 or 10
g
tool in OpenJDK.
-- Kevin
On 5/15/2018 3:16 PM, Alan Snyder wrote:
Where does java packager fit in this?
On May 15, 2018, at 2:59 PM, Kevin Rushforth wrote:
I wanted to update you on the progress of the last couple weeks on the OpenJFX
project:
1. As mentioned last week, we now have EA
On 5/16/2018 10:49 AM, Ty Young wrote:
That one, as mentioned in the wiki build guide. I get an immediate
build fail(see: https://pastebin.com/geR4LLMm). The JDK works just
fine: I can set it as the default JDK, run Netbeans, set the project
source to 11, and my application builds just fine.
On 5/16/2018 11:54 AM, Nir Lisker wrote:
What will happen to the JavaDocs? Will they be removed from the EA
docs and upon release from the release docs?
Correct. The JDK 11 docs will no longer include JavaFX modules and
classes. We will need to host separate docs for JavaFX.
-- Kevin
Yes, the source code for javapackager is fully open source.
-- Kevin
On 5/16/2018 1:05 PM, Michael Ennen wrote:
Is the source code for javapackager fully open source?
Thanks.
On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
The javapa
I think it isn't worth doing anything for the packager. In any case,
since "HelloService" is a test program, I see no problem with it
continuing to use java.util.logging.
Regarding your other comment:
Thanks Murali, Iv'e also commented out isDebug() (though maybe it can
be completely removed,
On 5/17/2018 3:16 AM, Ty Young wrote:
And could the new standalone modules be integrated with the source
code somehow so that a JDK without JavaFX support can be compiled?
Not sure what you mean, but you can use an OpenJDK without modules
+ the JavaFX standalone modules to build and run you
was discussed in the JIRA issue). Since the
packager is out of scope, I'll just patch the last remnant
in test.com.sun.javafx.binding.ErrorLoggingUtiltity and submit a
Webrev tomorrow or this weekend since all other changes are already
prepared (and mostly trivial).
- Nir
On Thu, M
to consider removing this. One
possible timeline would be to "deprecate it for removal" in JDK 12 and
remove it in JDK 13.
-- Kevin
[1] https://bugs.openjdk.java.net/browse/JDK-8202553
Thanks,
- Johan
On Wed, May 16, 2018 at 12:09 AM Kevin Rushforth
mailto:kevin.rushfo...@oracle.
Starting now, the JBS release version for the "jfx-dev" repo is "openjfx11".
All JBS issues for bugs that affect jfx-dev (e.g., are found in a local
build or in an openjfx-11-ea release) should use "openjfx11" as the
"affected version". Likewise, all bugs that are fixed in jfx-dev or
targeted
Sure. No problem.
-- Kevin
On 5/18/2018 1:22 PM, Nir Lisker wrote:
I see, sorry about the false flag.
On Fri, May 18, 2018 at 11:13 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
I was somewhat imprecise. That should have read:
We still expect to do a rele
users since it breaks continuity).
- Nir
On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
I wanted to update you on the progress of the last couple weeks on
the OpenJFX project:
1. As mentioned last week, we now have EA builds o
On 5/18/2018 10:45 AM, Matthew Elliot wrote:
Hey Anirvan,
Thanks for the info - guess it’s not such a promising route either then.
As these Jira for Matrox cards in JavaFX were from 2013 is it possible that
later Matrox cards / drivers would now work if this global disablement was not
prese
Phil or Ajit,
Please review the following simple fix:
https://bugs.openjdk.java.net/browse/JDK-8203378
http://cr.openjdk.java.net/~kcr/8203378/webrev.00/
This removes one qualified export from javafx.graphics to the
no-longer-built jdk.packager module. More details in JBS.
Note to Eclipse us
nned to be
updated [1] after j.u.l. is removed [2].
[1]
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021740.html
[2] https://bugs.openjdk.java.net/browse/JDK-8195974
- Nir
On Mon, May 21, 2018 at 8:54 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
which will have any review comments. If there are
no compelling reasons why the PR can't be pushed to jfx-dev, then it can
be pushed.
Please let me know your thoughts on the above proposals.
Thank you all for being a part of this community.
-- Kevin Rushforth, OpenJFX Project Lead
[1] htt
openjfx-dev-ow...@openjdk.java.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openjfx-dev digest..."
Today's Topics:
1. OpenJFX code review policies, etc. (Kevin Rushforth)
-----
as they approve the API change itself via the CSR.
-- Kevin
On 5/23/2018 3:16 PM, Kevin Rushforth wrote:
To: OpenJFX Developers
As I mentioned in a message last week [1] I would like to restart the
discussion we started a few months ago [2] around making it easier to
contribute code to OpenJFX. To
+1
On 5/25/2018 2:41 AM, Johan Vos wrote:
The webrev for the memory leak in the iOS imageloader, which is fixed by
https://github.com/javafxports/openjdk-jfx/pull/73/commits/7f264eda17fc91aedfa47e60ffa4a096a4904350
is
available at http://cr.openjdk.java.net/~jvos/8202396/webrev.00/
Is is a simp
I just sent an email to the core-libs-dev alias [1] proposing a new
Packaging Tool as a replacement for javapackager. If you are interested
in this JEP, you can follow and participate in the discussion there.
-- Kevin
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.ht
Am 31.05.18 um 02:11 schrieb Kevin Rushforth:
I just sent an email to the core-libs-dev alias [1] proposing a new
Packaging Tool as a replacement for javapackager. If you are
interested in this JEP, you can follow and participate in the
discussion there.
-- Kevin
[1]
http://mail.openjdk.java.net
rship
<https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership>
On Thu, May 24, 2018 at 1:16 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
To: OpenJFX Developers
As I mentioned in a message last week [1] I would like to restart
the discussion w
Apple has been making noises about this for a while. I wouldn't expect
them to drop OpenGL in the very near future, but it would seem that
investigating a Metal pipeline for FX is timely.
-- Kevin
On 6/4/2018 1:51 PM, Tom Schindl wrote:
Hi,
I don‘t know what the Apple guys are smoking but t
Hi Johan,
The intention is to launch using --module-path
java --module-path path-to-sdk/javafx-sdk-11/lib ...
For non-modular applications you also need to add the modules to the
module graph, for example:
java --module-path path-to-sdk/javafx-sdk-11/lib --add-modules
javafx.fxml,ja
Hi Tom,
Yes, changes such as this, which are needed for platform support, are
good candidates for backporting. Not sure about the time frame, but we
are looking into it with our sustaining team.
-- Kevin
On 6/6/2018 1:20 AM, Tom Schindl wrote:
Hi,
Eclipse SWT developers are about to remove
Hi Phil & Johan,
I have initiated a pull request on GitHub as a review for:
JBS: https://bugs.openjdk.java.net/browse/JDK-8201553
PR: https://github.com/javafxports/openjdk-jfx/pull/92
It is now ready to be reviewed, and once the review is done, merged into
the develop branch of the GitHub san
/
GitHub commit:
https://github.com/javafxports/openjdk-jfx/commit/04dc51b698347ce53420777abff4b2c472e45d32
-- Kevin
On 6/6/2018 11:00 AM, Kevin Rushforth wrote:
Hi Phil & Johan,
I have initiated a pull request on GitHub as a review for:
JBS: https://bugs.openjdk.java.net/browse/JDK-820155
The fix works for me, but I have a couple comment on the implementation
and a couple more on the test:
1. You borrowed the following from the Java2D fix:
+ signum((int)fx);
+ signum((int)fy);
This effectively does a rounding in the normalized absolute coordinate
space use by the Windo
Phil,
Please review the following to fix up the copyright header:
https://bugs.openjdk.java.net/browse/JDK-8203801
http://cr.openjdk.java.net/~kcr/8203801/webrev/
-- Kevin
: Kevin Rushforth
Sent: Saturday, June 9, 2018 1:15 AM
To: Pankaj Bansal; openjfx-dev@openjdk.java.net
Subject: Re: [11] JDK-8196031: FX Robot mouseMove fails on Windows 10 1709 with
HiDPI
The fix works for me, but I have a couple comment on the implementation and a
couple more on the test:
1. You
t only frees up the
scarce "R"eviewers, but it helps train new ones :-), whilst still
ensuring at least two sets of eye balls
were on it.
-phil.
On 05/24/2018 10:36 AM, Kevin Rushforth wrote:
Phil pointed out one glaring typo in the summary and also a couple
things in the details that c
We are getting close to the start of rampdown for JDK 11 [1]. Now that
FX is no longer bundled we don't need to follow exactly the same
schedule of milestones, although we do want to release this first
unbundled FX 11 release at the same time JDK 11 ships (or slightly sooner).
Here is the prop
7;t an issue.
-phil
No @since tags anywhere
-phil.
On 5/10/18, 8:32 AM, Kevin Rushforth wrote:
I confirm that this fixes the issue. The interface change to make
the two static methods e instance methods is a good change in any case.
I am not a Swing "R"eviewer, but the .13 webr
Please review the following to bump the minimum boot JDK required for
JavaFX builds to JDK 10. Note that the review will be done on github,
but it is OK to reply to this thread with comments if you don't have a
github account.
https://bugs.openjdk.java.net/browse/JDK-8200446
https://github.com
nse to use 'var' gratuitously).
I'll remind that there's a style guide at
http://openjdk.java.net/projects/amber/LVTIstyle.html.
- Nir
On Thu, Jun 14, 2018 at 4:33 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
Please review the following to b
I verified on an earlier version of the patch that it wasn't in the
docs, but it would be good for Prasanta to double-check.
-- Kevin
On 6/14/2018 1:29 PM, Phil Race wrote:
you surely mean
@since 11
I believe it has been verified that it is excluded from the docs build
.. right Prasanta ?
We just upgraded to gradle 4.8 last week, but haven't yet updated the Wiki.
One thing to try is to manually remove the build directory, run gradle
clean, and then try it again with the --info option:
$ rm -rf build
$ gradle clean
$ gradle --info sdk
If it still doesn't work, make sure you hav
For those using the modified jcheck as indicated on the OpenJFX Wiki [1]
be aware that the latest promoted build tags, which were just synced
into the jfx-dev/rt repo, will require you to download a new version of
the modified jcheck tool [2] to handle the new tag format.
-- Kevin
[1] https:/
I tested this on all three platforms and the updated rasterizer looks good.
I spot checked the code changes, but didn't get time to do a complete
review yet. I was mostly looking for diffs between the Java2D version
which was already reviewed, and this one.
I do have a couple comments on the
+1
-- Kevin
On 6/20/2018 1:07 AM, Tom Schindl wrote:
Hi,
I'd like to request a review for the fix of JDK-8191661. The change is
at https://github.com/javafxports/openjdk-jfx/pull/100
Tom
The individual per-project javadoc tasks have always been disabled, so
this is not new.
-- Kevin
On 6/25/2018 4:27 PM, Nir Lisker wrote:
Hi,
When I run gradle javadoc (or for a specific module), all the javadoc tasks
are marked as SKIPPED. I don't remember this happening previously.
Task :
The javapackager tool, which was delivered as part of the Oracle JDK
releases along with JavaFX in JDK 8 through JDK 10, has been removed
from the JDK as of JDK 11. A JEP for a new packaging tool, jpackager, is
being proposed and discussed on core-libs-dev [1].
-- Kevin
[1]
http://mail.openj
We do not plan to add any more media codecs.
I agree that supporting pluggable codecs would be better than adding any
more specific codecs. I note that we aren't likely to spend resources on
doing this, either. Perhaps someone in the community would be interested
in working on it.
-- Kevin
ation will ever see. I may be
missing some point here.
-- Kevin
On 6/25/2018 9:01 AM, Laurent Bourgès wrote:
Kevin,
Here are my comments below:
2018-06-16 1:47 GMT+02:00 Kevin Rushforth <mailto:kevin.rushfo...@oracle.com>>:
I tested this on all three platforms and the
One more thing about the test. All of the OpenJFX unit tests should have
GPL v2 + Classpath Exception (this differs from the JDK).
-- Kevin
On 6/29/2018 10:23 AM, Kevin Rushforth wrote:
I'll plan to review the code today if possible. This will need one
more reviewer, so maybe Phil can
lem.
Also, I've tested it pretty well on all three platforms.
The overall +1 is pending the fixes needed for the test: at least the
copyright header and shortening or disabling the test.
-- Kevin
On 6/29/2018 11:25 AM, Kevin Rushforth wrote:
One more thing about the test. All of the Ope
mProperty "ClipShapeTest.numTests",
rootProject.getProperty("ClipShapeTest.numTests")
}
-- Kevin
On 7/3/2018 2:13 AM, Laurent Bourgès wrote:
Kevin,
Thanks for the review !
2018-06-29 22:52 GMT+02:00 Kevin Rushforth <mailto:kevin.rushfo...@oracle.com>>:
>
On 7/3/2018 8:45 AM, Laurent Bourgès wrote:
Kevin,
> I added the system property "ClipShapeTest.numTests" but it requires a
build.gradle change to pass the parameter:
Yes, something like this is what I had in mind. As long as we
don't add too many of these, it is OK with me
PS: I am not really satisfied by adding such noise in build.gradle,
but it can be improved later ...
Agreed. This can be a follow-on issue. I'll finish my review shortly.
-- Kevin
On 7/3/2018 8:45 AM, Laurent Bourgès wrote:
Kevin,
> I added the system property "ClipShapeTest.numTests" b
Looks good.
+1 -- note that needs a second reviewer (doesn't need to be a capital-R
Reviewer).
-- Kevin
On 7/3/2018 8:56 AM, Kevin Rushforth wrote:
PS: I am not really satisfied by adding such noise in build.gradle,
but it can be improved later ...
Agreed. This can be a follow-on
Most of you should be aware of this already: The review for the public
FX Robot API, contributed by Michael Ennen (and sponsored by me), has
been proceeding on GitHub:
https://bugs.openjdk.java.net/browse/JDK-8090763
https://github.com/javafxports/openjdk-jfx/pull/36
My review is now done, so
As a reminder, the RDP1 date for openjfx11 is July 9, at 23:59 Pacific
time. This is the deadline for features, although we will have a process
for getting in some smaller enhancements after RDP1 with approval
(similar to what the JDK does).
-- Kevin
On 6/12/2018 3:18 PM, Kevin Rushforth
Java2D
patch and the JavaFX patch, and it looks ok to me.
I'll try to test it on linux and/or mac later today and have a
deeper look.
- Johan
On Tue, Jul 3, 2018 at 6:14 PM Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
Note that this has already been merged into the 'develop' branch on
GitHub. Barring any objections, I'll push it to openjfx-dev tomorrow.
On 7/5/2018 1:06 PM, Bernhard Lutzmann wrote:
Hi,
please review the following pull request on GitHub:
JBS: https://bugs.openjdk.java.net/browse/JDK-8203345
One quick comment:
This no longer compiles with OpenJDK10. It looks like the logic to
optionally filter out jdk.unsupported.desktop from javafx.swing's
module-info.java got lost between the .2 and .3 versions.
-- Kevin
On 7/4/2018 4:35 AM, Prasanta Sadhukhan wrote:
Hi All,
Please review a
6:47 AM, Kevin Rushforth wrote:
One quick comment:
This no longer compiles with OpenJDK10. It looks like the logic to
optionally filter out jdk.unsupported.desktop from javafx.swing's
module-info.java got lost between the .2 and .3 versions.
-- Kevin
On 7/4/2018 4:35 AM, Prasanta Sadh
n 7/5/2018 11:29 PM, Prasanta Sadhukhan wrote:
My Bad. Please find modified webrev restoring the filter
http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.4/
Regards
Prasanta
On 7/6/2018 6:47 AM, Kevin Rushforth wrote:
One quick comment:
This no longer compiles with OpenJDK10. It looks
Hi Steve,
This is happening because the JDK has now switched to VS 2017 for its
build, and is now delivering the Microsoft redistributable DLLs. JavaFX
switched to using VS 2017 prior to JDK 10, so the javafx.graphics module
also includes these DLLs. I will file a bug against JavaFX.
I don't
iew in the next day or so.
-- Kevin
On 7/9/2018 4:12 AM, Prasanta Sadhukhan wrote:
Hi Kevin,
Modified webrev to address the "public" leakage
http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.5/
I am looking into the test failures.
Regards
Prasanta
On 7/7/2018 4:30 AM, Kevin Rushf
To: OpenJFX Developers
As a reminder, OpenJFX 11 is now in Rampdown Phase One RDP1. [1]
During RDP1, the only restriction is that any enhancements will need
explicit approval to go in. Note that these restrictions apply to the
jfx-dev/rt mainline (and by extension, the develop branch of the Gi
Yes, that will work around the problem.Thanks for posting it.
Note that the 'glob:/javafx.graphics/lib/' term is unneeded. The
following is sufficient:
--exclude-files
"glob:/javafx.graphics/lib/api-ms*.dll,glob:/javafx.graphics/lib/ucrtbase.dll,glob:/javafx.graphics/lib/vcruntime140.dll,glob
I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer.
Prem is a member of JavaFX team at Oracle, who has contributed 10
changesets [2] to OpenJFX.
Votes are due by July 24, 2018.
Only current OpenJFX Committers [4] are eligible to vote on this
nomination. Votes must be cast in the op
Vote: YES
On 7/10/2018 4:41 PM, Kevin Rushforth wrote:
I hereby nominate Prem Balakrishnan [1] to OpenJFX Committer.
Prem is a member of JavaFX team at Oracle, who has contributed 10
changesets [2] to OpenJFX.
Votes are due by July 24, 2018.
Only current OpenJFX Committers [4] are eligible
Good to know about the time frame. Yes, we are looking at backporting
GTK 3 support to JDK 8.
-- Kevin
On 7/12/2018 12:47 AM, Tom Schindl wrote:
Hi,
There's a now a defined EOL for SWT-Gtk2 announced [1]. The last SWT
Release supporting Gtk2 is 2018-09! Starting with 2018-12 SWT there will
b
Checking the conditional feature SCENE_3D should give you what you need.
It is true if and only if there is support for 3D features, which is the
software pipelines lack.
-- Kevin
On 7/12/2018 4:02 AM, Selim Dincer wrote:
Hi,
I was wondering if there is a way to find out which graphics pipe
some more refactoring to move more
common code to SwingNode
and also this solves SwingNodeMemoryLeakTest failure
http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.6/
Regards
Prasanta
On 7/10/2018 7:13 AM, Kevin Rushforth wrote:
Hi Prasanta,
The public API looks fi
+1
On 7/13/2018 3:40 AM, Johan Vos wrote:
PR 83 (https://github.com/javafxports/openjdk-jfx/pull/83) is ready to be
merged.
The JBS issue is at https://bugs.openjdk.java.net/browse/JDK-8205919
webrev: http://cr.openjdk.java.net/~jvos/8205919/webrev.00/rt.patch
The GitHub PR is approved by Kevi
Would it help Eclipse if instead of an empty jar, the jar contained just
the module-info.class file? Or will that then cause problems because of
two .jar files with the same module name?
-- Kevin
On 7/13/2018 7:37 AM, Johan Vos wrote:
Hi Steve,
Yes, that has been considered, but I'm more th
name javafx.controls and the platform dependent uses e.g.
javafx.controls.windows
Regards,
Steve
Am Fr., 13. Juli 2018 um 17:00 Uhr schrieb Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>:
Would it help Eclipse if instead of an empty jar, the jar
contained just
the mod
santa Sadhukhan wrote:
Hi Kevin,Ambarish,
Please find modified webrev taking care of review comments.
http://cr.openjdk.java.net/~psadhukhan/fxswinterop/webrev.8/
I had done "gradle checkrepo" followed by "checkWhiteSpace -F" to get
rid of whitespace problem.
Regards
Prasant
FYI, I have synced the OpenJFX changes from the just-released July 2018
CPU/PSU release (8u181, 10.0.2) into 8u-dev, 10u-dev, and jfx-dev.
-- Kevin
There was a somewhat late-ish respin of JDK 8u181 for a problem that was
unrelated to and did not affect JavaFX, so JDK 8u181-b13 used the FX
bits from build 12. Thanks for checking, though.
-- Kevin
On 7/17/2018 10:57 AM, Edens, Eric wrote:
Quick check on the tags. For JFX 8u181, the latest
+1
On 7/19/2018 10:21 PM, Prasanta Sadhukhan wrote:
Hi Kevin, All
Please review the disabling of the 2 failing tests in SandboxAppTest.
--- a/tests/system/src/test/java/test/sandbox/SandboxAppTest.java Mon
Jul 16 14:30:19 2018 +0530
+++ b/tests/system/src/test/java/test/sandbox/SandboxAppTest
Please review the following PR on GItHub. Once approved there, I will
merge it to develop and then push it to the jfx-dev HG repo.
https://bugs.openjdk.java.net/browse/JDK-8207015
https://github.com/javafxports/openjdk-jfx/pull/136
-- Kevin
Alan Bateman is probably the best person to ask about this, although I
don't know how much he has looked into what maven is doing w.r.t. modules.
The problem here seems to be that the dummy jar doesn't have a
module-info.class, and so will become an automatic module with a name
chosen based on
As an FYI, this is filed in JBS as:
https://bugs.openjdk.java.net/browse/JDK-8207839
and is now being reviewed.
-- Kevin
On 7/5/2018 8:10 PM, Nakajima Akira wrote:
Hi All.
I created github account today
and re-posted this patch to github.
Please review the following fix:
patch: https://git
This is being tracked here:
https://bugs.openjdk.java.net/browse/JDK-8207932
As an RFE, this can be considered for openjfx12.
-- Kevin
On 7/5/2018 11:59 PM, Nakajima Akira wrote:
Hi All.
patch: https://github.com/javafxports/openjdk-jfx/pull/126
This is separated from
http://mail.openjdk.
Hi,
The relaxed permissions, which are allowed given the default
'--illegal-access=permit' mode, only apply to modules that are linked
into the Java runtime. Modules that are loaded on the module-path are
subject to strict access controls.
I see three possible solutions for you:
1. Run your
The following should work:
gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true
:systemTests:test
You can limit it to just the Monocle tests as follows:
gradle -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true
:systemTests:test --tests 'test.robot.com.sun.glass.ui.monoc
801 - 900 of 5031 matches
Mail list logo
