Nice! Thanks for your hard work on this, Johan.
-- Kevin
Johan Vos wrote:
Hi,
I did 2 things:
* I talked to the fine and great people at AdoptOpenJDK (
https://adoptopenjdk.net/) and they are happy to have their build farm
being used to create OpenJFX modules (including the native libraries).
As far as the bug goes, I think it would be better to do it the other
way around. If we adopt a policy that a PR should reference a bug in
JBS, then that part of the problem will go away. I'm not convinced that
merging a random PR, for what is essentially just "a good idea" if it
isn't backed b
Thanks for the info. I update the bug report with this information, and
marked it as a regression (introduced in 9).
-- Kevin
Nir Lisker wrote:
I tested the issue. It is not present in 1.8.0_152-b16, but it is present
in 9+181 and 10-ea+37.
- Nir
Sorry for the delay in responding. I was traveling when this was sent
and barely able to keep up with urgent email / tasks.
Most of what you suggest below seems good. My only concern is whether
the "on demand" evaluation will have any side effects. Conceptually, it
seems like the right thing t
As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own thread and there's also the mailing list. Maybe
someone from Oracle already has done work related to the PR, and this will
only be known if a JBS issue is submitted or a mailing list thread is
star
Johan Vos wrote:
On Thu, Feb 15, 2018 at 4:09 AM Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
A global reference in JBS would indeed be very good to track back the
work in a PR to a real issue. It can also be very useful as there are
many existing issues in JBS that
asses to one of those choices.
[1]
https://docs.oracle.com/javase/9/docs/api/javafx/beans/binding/When.NumberConditionBuilder.html
On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
Sorry for the delay in responding. I was traveling when this was
This does sound like a bug. Can you file it at http://bugreport.java.com/ ?
One possible workaround might be to set the size of the scene when you
first create it:
new Scene(root, WIDTH, HEIGHT)
-- Kevin
Adam Granger wrote:
Greeting,
(https://stackoverflow.com/questions/48937412/node-
I haven't seen this bug, and I did a quick search and don't find it. Go
ahead and file a bug, but unless it is a trivial fix, you will need to
contact the author of the fix and ask him to sign the OCA before we
could take it.
> (P.S. When is ramp down phase 2 over? :) ).
Oh, right. We're actu
In general, what should we do when we find bugs in version 8 but the
latest development is happening on version 11? Open the bug, or test
it against the latest version first?
The latter is preferable if it is possible to test it on the latest version.
Thanks.
-- Kevin
John Neffenger wrote
Voting for Rajath Kamath [1] to OpenJFX Committer [2] is now closed.
Yes: 6
Veto: 1
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this nomination
has failed.
I didn't have a chance to respond to the Veto before the voting period
ended, but will reply shortly.
-- Kevin
[
ng, don't stop yourself to get that.
*Solve issue to get knowledge not just to show counts to other people.*
I can one more checkin from you, but that's too I guess in Test file
i.e. 0.5
So It seems, you are very close to your destination.
Let me now if anyone in the community has a
One of the big challenges in running JavaFX with OpenJDK builds is that
developers need to build OpenJDK locally themselves and include the
JavaFX bits produced by a locally-built OpenJFX build.
In an earlier email with the subject "javafx might not be present" [1],
I mentioned our intention t
es that:
* It's easier to start working because the GiutHub repo is more
convenient than the Oracle repo currently.
* PRs and JBS issues are mutually aware.
* The submit -> review -> commit process is streamlined.
We pay a synchronization price for having 2 repos and 2 bug trackers.
T
etween the repos. And supposed someone works on a different fix and
uses the rejected PR code, how will that be committed?
Good questions; maybe Johan has some thoughts as to how to mitigate this?
-- Kevin
On Wed, Feb 28, 2018 at 12:25 AM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.c
mp; the font finding fallback code is being little dubious.
I would like to address that separately. I have filed bug
JDK-8198752 <https://bugs.openjdk.java.net/browse/JDK-8198752> to
handle that.
Regards,
Ajit
*From:* Phil Race
*Sent:* Thursday, February 15, 2018 10:44 PM
*T
.
--Michael
Am 27.02.18 um 22:21 schrieb Kevin Rushforth:
One of the big challenges in running JavaFX with OpenJDK builds is
that developers need to build OpenJDK locally themselves and include
the JavaFX bits produced by a locally-built OpenJFX build.
In an earlier email with the subject &q
t;master" are regularly merged into
"development". The moment an accepted PR makes it into OpenJFX, it
will be synced into "master" and merged into "development" where the
merge happens silently as there are no conflicts (since development
alread
(since development already
has this
code).
Does that make sense?
- Johan
On Wed, Feb 28, 2018 at 12:51 AM Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
wrote:
>
>
> Nir Lisker wrote:
>
Ambarish or Ajit,
Please review the following fix to remove the obsolete JFR logger code:
https://bugs.openjdk.java.net/browse/JDK-8196297
http://cr.openjdk.java.net/~kcr/8196297/webrev.00/
Thanks.
-- Kevin
Ajit or Phil,
Please review the following fix to remove the obsolete apps/experiments
from the OpenJFX repo:
https://bugs.openjdk.java.net/browse/JDK-8196198
http://cr.openjdk.java.net/~kcr/8196198/
There is no reason to keep them around in jfx mainline (they can still
be found in openjfx/10
Note that the webrev just contains the one modified file. As explained
in JBS I didn't see the point of posting a 30 Mbyte webrev consisting of
485 removed files. If you want to apply the actual patch, then you can
download the .patch.gz file.
-- Kevin
Kevin Rushforth wrote:
Ajit or
I filed the following JBS isuse to remova the SceneBuilder sources from
the OpenJFX repo.
https://bugs.openjdk.java.net/browse/JDK-8198961
As mentioned in the Description of that issue, the OpenJFX repo contains
the source code for a no-longer-maintained version of the SceneBuilder
tool. Acti
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8195788
http://cr.openjdk.java.net/~kcr/8195788/webrev.00/
As the title says, this will remove the obsolete javafx.jmx module.
Details are in JBS.
-- Kevin
wrote:
Dear Kevin,
I will get back to you on this shortly with substantial claims.
--Ankit
On 28 Feb 2018 2:23 a.m., "Kevin Rushforth"
mailto:kevin.rushfo...@oracle.com>>
wrote:
Hi Ankit,
In response to your veto, I took the opportu
Phil,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8199071
http://cr.openjdk.java.net/~kcr/8199071/webrev.00/
This is mostly simple cleanup. The only substantive change was to remove
the override of the deprecated sourceSets.main.output.classesDir
property (added by t
Prasanta or Ajit,
Please review the following fix to remove the reference to JApplet from
the SwingInterop sample in Ensemble8:
https://bugs.openjdk.java.net/browse/JDK-8199132
http://cr.openjdk.java.net/~kcr/8199132/webrev.00/
Thanks.
-- Kevin
Ajit and Ambarish,
Please review the following to cleanup references to internal core
packages from our unit tests:
https://bugs.openjdk.java.net/browse/JDK-8198858
http://cr.openjdk.java.net/~kcr/8198858/webrev.00/
Thanks.
-- Kevin
Looks good.
+1
-- Kevin
Laurent Bourgès wrote:
Kevin,
Please review the following webrev that fixes compilation with gcc 6,
that was initiated on github by Emmanuel Bourg (@ebourg) in PR #11 and #16
https://bugs.openjdk.java.net/browse/JDK-8189689
http://cr.openjdk.java.net/~lbourges/fx/f
Since you have a simple test program that reproduces this bug, can you
please file a bug report?
http://bugreport.java.com/
Thanks.
-- Kevin
Chris Nahr wrote:
After some more experimentation I added some details and a screenshot
(from another test program) to this blog post:
http://news.kyn
I haven't run these with a Locale other than en_US, but given the nature
of the failure, it looks like you may have discovered another
Locale-related test bug.
We had another test that was fixed by setting the default Locale to
Locale.US in a static @BeforeClass method in the test class [1]. P
er modules?
-- Kevin
I have no opinion what is preferable to have less maintenance work or
problems in future.
Laurent
2018-03-12 16:09 GMT+01:00 Kevin Rushforth <mailto:kevin.rushfo...@oracle.com>>:
I haven't run these with a Locale other than en_US, but given the
n
Hi Nir,
This seems like a simple enough RFE, and I am not aware of anyone else
working on it, nor any barriers that would make it difficult.
As with any RFE that adds API (or implements a new feature) the API
additions will need to be approved first. Currently we use the CSR
process [1][2],
ks with any new JDK / JavaFX
version and hoped it would get support for new controls, if any were added to
JavaFX.
-Florian
Am Freitag, 2. März 2018, 09:12:15 CET schrieb Kevin Rushforth:
I filed the following JBS isuse to remova the SceneBuilder sources from
the OpenJF
view ID 9052971.
Interestingly, merely calling sizeToScene explicitly (which shouldn't
be necessary though) fixes the bug at 125% and 150% but not at 175%. I
added that info to the report and the test program.
Thanks, Chris
On 2018-03-12 16:02, Kevin Rushforth wrote:
Since you have a simple test pro
til I figure out if there's a problem
with the test suit.
On Fri, Feb 16, 2018 at 11:46 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
wrote:
This will take me a bit more time to look at than I have right
now (and Monday is a US holiday), so one quick
I took a quick look and had one comment:
public class BooleanConditionBuilder2 extends
ConditionBuilder { ... }
As I understand it, you have added this as a possible refactoring for
BooleanConditionBuilder (but left the original in for comparison),
right? Since this would constitute a pub
ic
classes, so that would need to be considered.
-- Kevin
It will be a couple days before I can look at the rest.
No problem.
-Nir
On Tue, Mar 13, 2018 at 5:42 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
I took a quick look and had one comment:
That will be a question for Gluon.
-- Kevin
Michael Paus wrote:
How will these changes then be synchronized with the work Gluon is
doing for the version
distributed by them? Do they work on the same repo?
Am 12.03.18 um 23:25 schrieb Kevin Rushforth:
Hi Florian,
By way of update, after
o it won't stop
after the first batch of failing tests), are there any more tests
that fail in other modules?
-- Kevin
I have no opinion what is preferable to have less maintenance
work or problems in future.
Laurent
2018-03-12 16:09 GMT+01:00 Kevin
...not so much on
Windows).
-- Kevin
Kevin Rushforth wrote:
This will happen if you: A) don't build WebKit; and B) are running
with a libwebkit.dylib that is out of date w.r.t., the java source.
In your case it looks like you are using the native webkit library
from JDK 9.0.4 and the so
hanks
Sven
Am 14.03.2018 22:08 schrieb "Kevin Rushforth"
mailto:kevin.rushfo...@oracle.com>>:
As a solution, you can download the latest EA build of Oracle JDK
11 here:
http://jdk.java.net/11/
and copy the libjfxwebkit.dylib from there into your FX build.
Phil,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8199684
http://cr.openjdk.java.net/~kcr/8199684/webrev.00/
This is long-overdue cleanup to bump the minimum boot JDK to JDK 9 GA,
which I discovered while working on the gradle changes for separating FX
bits (and whic
Approved.
-- Kevin
Johan Vos wrote:
The very simple webrev for https://bugs.openjdk.java.net/browse/JDK-8199675 is
here:
http://cr.openjdk.java.net/~jvos/8199675/webrev.00/
I'll commit once approved (adding the contributed-by smanux (Emmanuel
Bourg) )
Conceptually what you describe sounds like a good approach to explore.
Another approach worth exploring is to see whether this can be done
without API change, using the existing API. I took a (very quick) look
and didn't see anything that would preclude fixing this using the
existing API, nor
As long as it is optional, this seems like a fine idea.
When we explored it before, there was some concern about checking in the
gradlew.jar file to the repo -- we would need to get additional
third-party legal approval -- so I would need to check on that before
this can be merged to the mainl
This looks good to me, too, with one comment:
The three new files have DOS line endings. Please convert to UNIX-style
line endings, else it will fail jcheck (and fail the
tools/scripts/checkWhiteSpace).
-- Kevin
mandy chung wrote:
On 3/19/18 7:10 AM, Ambarish Rapte wrote:
Hi Kevin, Ala
I will do an initial review of the API today and suggest next steps.
-- Kevin
Michael Ennen wrote:
Ping :)
On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
I'll take a look some time after RDP2 of JDK 10.
-- Kevin
Mi
Phil,
Please review the FX change to use GTK 3 by default, as you recently did
for AWT:
https://bugs.openjdk.java.net/browse/JDK-8198654
http://cr.openjdk.java.net/~kcr/8198654/webrev.00/
I have run a full test, including all robot tests, on Ubuntu 16.04 using
two different JDKs -- one with
n).
Hopefully this will spark a discussion.
-- Kevin
Michael Ennen wrote:
Ping :)
On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
I'll take a look some time after RDP2 of JDK 10.
-- Kevin
Michael Ennen wrote:
Hey
I'll defer to Phil on this review.
I have no concerns over the fix, and can confirm that the failing tests
now pass on my system.
-- Kevin
Laurent Bourgès wrote:
Kevin,
Please review this webrev that fixes the NPE in getMediaName():
JBS: https://bugs.openjdk.java.net/browse/JDK-8196617
web
est is easy for me to follow and will be no problem.
On Tue, Mar 20, 2018 at 4:28 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
Hi Michael,
Here is some quick feedback.
I think what you have is heading in the right direction as far as
the public API goes.
Hi Daniel,
Thanks for the review.
I like the idea of removing the unused levels and methods.
As for directly using System.Logger.Level, we have enough usages of the
Level and convenience logging methods (e.g., "warn", "fine", etc.), that
I think it's better to file a follow-up issue (to minim
mandy chung wrote:
On 3/23/18 10:51 AM, Kevin Rushforth wrote:
Hi Daniel,
Thanks for the review.
I like the idea of removing the unused levels and methods.
As for directly using System.Logger.Level, we have enough usages of
the Level and convenience logging methods (e.g., "warn&qu
inline
mandy chung wrote:
On 3/23/18 9:34 AM, Ajit Ghaisas wrote:
Hi Kevin, Mandy and Daniel,
Please review the changeset that removes dependency on sun.util.logging
package from JavaFX code.
Bug : https://bugs.openjdk.java.net/browse/JDK-8195799
Fix : http://cr.openjdk.java.
The only additional comments I have are couple typos and a white-space
issue:
1. There is a typo in the Copyright year (201 rather than 2018) in the
following two files:
modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java
modules/javafx.graphics/src/main/java/j
Seems good to me, too.
-- Kevin
Michael Ennen wrote:
Sounds like a good idea to me to only have `getScreenCapture` methods
that have a WritableImage parameter which can be `null` which means a
new WritableImage will be created otherwise the given one is re-used, as
in Scene.snapshot and Node.s
thods from com.sun.javafx.logging.PlatformLogger class.
Also, I have created a new bug JDK-8200236 to address some of the valid
suggestions from Mandy and Daniel.
Request you to review the new webrev.
Regards,
Ajit
-Original Message-----
From: Kevin Rushforth
Sent: Saturday, March 24, 2018 3:27 AM
have created a new bug JDK-8200236 to address some of the valid
suggestions from Mandy and Daniel.
Request you to review the new webrev.
Regards,
Ajit
-Original Message-
From: Kevin Rushforth
Sent: Saturday, March 24, 2018 3:27 AM
To: Ajit Ghaisas
Cc: Mandy Chung; Daniel Fuchs; openjfx
Ultimately, I think you are right that a standalone JavaFX needs to be
discoverable and usable via a dependency manager like gradle or maven.
From the discussion, it seems most others agree.
I note that this doesn't preclude also making a zip bundle available for
developers who want to downloa
allel for key typed. Is it
worth?
- Nir
On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:
Seems good to me, too.
-- Kevin
Michael Ennen wrote:
Sounds like a good idea to me to only have `getScreenCapture` methods
that have a WritableImag
Hi Tom,
Yes, this is an unfortunate dependency. It is "only" an implementation
dependency, meaning that nothing in the public API depends on
java.desktop (which is why we don't "requires transient java.desktop"),
so it should be possible to remove this dependency in the future. As
noted, it i
st stuff is using java.util.Logging
could this not be ported to PlatformLogger?
Tom
On 26.03.18 22:46, Kevin Rushforth wrote:
This looks fine to me now.
-- Kevin
Ajit Ghaisas wrote:
Thanks all for the review.
I have addressed the review comments in -
http://cr.openjdk.java.net/~aghaisas
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8200277
https://github.com/javafxports/openjdk-jfx/commit/ccd5aa2ca090f0844778def02c1c1243c87fb7d4
This was merged into the GitHub sandbox 'develop' branch here:
https://github.com/javafxports/openjdk-jfx/pull/47
-- Kevin
Actually, that was a pointer to the merge changeset on GitHub. Here is
the actual changeset in question (the contents are identical)
https://github.com/javafxports/openjdk-jfx/commit/b7279fa9572472be803139898e3407fd860e2e75
-- Kevin
Kevin Rushforth wrote:
Please review the following:
https
ehavior unless we do something like adding a constructor
When(ObservableBooleanValue condition, boolean lazyEval) and default
the current one to lazyEval=false. We could also use the "we told you
so" line for developers who rely on the current undocumented behavior.
- Nir
On
I think this would be fine. We would want something that didn't conflict
with anything else and wasn't confusing. Possible choices:
github-link
github-bug
gitbug-issue
Any preferences?
-- Kevin
Nir Lisker wrote:
Kevin, can we get a label for this?
- Nir
On Mon, Mar 26, 2018 at 4:37 PM, Jo
As a prerequisite, we would need to update the minimum boot JDK to JDK
10, which I was going to propose doing anyway -- it seems the right time
now that JDK 10 is out.
I have no objections to then allowing the use of 'var' in new code.
Do any others have any concerns?
-- Kevin
Nir Lisker wr
Hi Johan,
Please review the following to add gradle wrapper:
https://bugs.openjdk.java.net/browse/JDK-8199841
http://cr.openjdk.java.net/~kcr/8199841/webrev.00/
This is the aggregation of two changesets pushed to the github mirror:
https://github.com/javafxports/openjdk-jfx/commit/7ff32048e62e
I hereby nominate Rajath Kamath [1] to OpenJFX Committer.
Rajath is a member of JavaFX team at Oracle, who has contributed 17
changesets [2][3] to OpenJFX.
Votes are due by April 12, 2018.
Only current OpenJFX Committers [4] are eligible to vote on this
nomination. Votes must be cast in the
Vote: YES
Kevin Rushforth wrote:
I hereby nominate Rajath Kamath [1] to OpenJFX Committer.
Rajath is a member of JavaFX team at Oracle, who has contributed 17
changesets [2][3] to OpenJFX.
Votes are due by April 12, 2018.
Only current OpenJFX Committers [4] are eligible to vote on this
29-Mar-2018, at 10:12 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
wrote:
>
> I hereby nominate Rajath Kamath [1] to OpenJFX Committer.
>
> Rajath is a member of JavaFX team at Oracle, who has contributed
17 changesets [2][3] to OpenJFX.
I filed:
https://bugs.openjdk.java.net/browse/JDK-8200446
I'll send out a separate heads-up today (as we always do when requiring
an update to our tool chain) and we can target this for next week if no
objections.
-- Kevin
Kevin Rushforth wrote:
As a prerequisite, we would need to u
I tend to agree, so I would prefer to see them used judiciously. The
write-up by Stuart (referenced below) raised some good points about when
to use them vs when you might not want to.
-- Kevin
Artem Ananiev wrote:
On 2018/03/29 9:36, Kevin Rushforth wrote:
As a prerequisite, we would
As mentioned in another thread [1] we should update the minimum boot JDK
used to build FX to 10, which will allow the use of JDK 10 langauge
features, such as 'var', as well as JDK 10 APIs. It's also the right
time to do this in general. I filed a new RFE [2] to track this and plan
to send it o
+1
Johan Vos wrote:
Please review the webrev http://cr.openjdk.java.net/~jvos/8200300/webrev.00/
which fixes https://bugs.openjdk.java.net/browse/JDK-8200300
Nir Lisker wrote:
Hi all,
Iv'e created another issue for collecting JavaDoc
corrections: https://bugs.openjdk.java.net/browse/JDK-8200587. If you
found any, please add them to this issue and I'll fix them along with
what's there already.
Thanks for creating this bug and providing a fix. I
x27;ll sent a review request when
I upload the fix.
- Nir
On Mon, Apr 2, 2018 at 10:11 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
Nir Lisker wrote:
Hi all,
Iv'e created another issue for collecting JavaDoc corrections:
https://bugs.open
n 29.03.18 08:42, Laurent Bourgès wrote:
Hi,
As such github references point to either issue or PR, I recommend using
the term 'github-link'.
Laurent
Le jeu. 29 mars 2018 à 03:40, Kevin Rushforth <
kevin.rushfo...@oracle.com>
a écrit :
I think this wo
Hi Matt,
Thank you for filing this bug.
Can you provide a standalone test case that reproduces this (a .java and
a .css file), so we can attach it to the bug? Our WebBugs triage
engineer will ask for this, and it will save time if you can provide it
now. Otherwise the bug report looks fine.
4, 2018, 16:43 Johan Vos <mailto:johan@gluonhq.com>> wrote:
+1
On Wed, Apr 4, 2018 at 3:30 PM Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
wrote:
Any further comments on this? If not, then I propose we start
using the
JBS la
public static void main(String[] args) {
Application.launch(args);
}
}
There are at least 3 properties I have seen doing this and depending
on the complexity of the CSS, in our case quite extensive it leads to
a lot of throw/catch/ignore. :)
M.
On 4 April 2018 at 18:06, Kevin Rushforth <mailto:k
Yes, this is very likely the issue. If you take the jfxwebkit.dll from
the latest EA build of JDK 11 then you should be fine. Alternatively, if
you have the patience to build webkit from source (at least once) then
you can use that.
Johan had a good idea that gradle :web:test should produce a
Yes, this is the plan. There has been quite a lot of discussion on this,
so I invite you to search the email archives [1]. Specifically, the
recent "modules versus SDK's" thread [2]. You are welcome to join the
mailing list [3] and contribute to the discussion if you like.
-- Kevin
[1] http:/
/61
[4] https://github.com/javafxports/openjdk-jfx/pull/63
Kevin Rushforth wrote:
As mentioned in another thread [1] we should update the minimum boot
JDK used to build FX to 10, which will allow the use of JDK 10
langauge features, such as 'var', as well as JDK 10 APIs. It's
Hi Nir,
Thank you for taking care of this.
-- Kevin
Nir Lisker wrote:
Iv'e done some house cleaning and linked whatever I found. Should have
caused a decent amount of notification spam...
- Nir
On Wed, Apr 4, 2018 at 8:10 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>
Phil & Ajit,
Please review these changes:
https://bugs.openjdk.java.net/browse/JDK-8199357
http://cr.openjdk.java.net/~kcr/8199357/webrev.00/
Details are in JBS.
-- Kevin
Voting for Rajath Kamath [1] to OpenJFX Committer [2] is now closed.
Yes: 8
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.
-- Kevin
[1] http://openjdk.java.net/census#rkamath
[2]
http://mail.openjdk.java.net/pipermail/o
OK, in that case once the OCA is in place we can evaluate the proposed fix.
Thanks.
-- Kevin
On 4/16/2018 1:10 PM, Michael Ennen wrote:
I note in the issue Kevin said:
" I note that if this really is Monocle-specific, then we will likely need
someone from the community to provide a fix. "
J
+1
On 4/18/2018 11:18 PM, Johan Vos wrote:
Can someone review/ack the simple PR for
https://bugs.openjdk.java.net/browse/JDK-8199765 ?
Thanks,
- Johan
For all platforms or just for arm? The latter should be fine. The former
would break the build, but fortunately, that flag defaults to true on
desktop platforms.
buildSrc/linux.gradle:LINUX.compileSwing = true;
buildSrc/mac.gradle:MAC.compileSwing = true;
buildSrc/win.gradle:WIN.compileSwing =
I guess I should say "for non-desktop platforms" since COMPILE_SWING is
also false for iOS and dalvik platforms.
-- Kevin
On 4/19/2018 8:21 AM, Kevin Rushforth wrote:
For all platforms or just for arm? The latter should be fine. The
former would break the build, but fortunately,
Phil,
Please review the following simple patch to update the OpenJFX license
files to match the JDK project (including adding two missing files).
https://bugs.openjdk.java.net/browse/JDK-8202036
http://cr.openjdk.java.net/~kcr/8202036/webrev/
Thanks.
-- Kevin
Please review this RFE to add support for creating a standalone FX SDK
and supporting building / running apps and tests using OpenJDK (without
FX modules) + the FX standalone SDK.
https://bugs.openjdk.java.net/browse/JDK-8198329
http://cr.openjdk.java.net/~kcr/8198329/webrev.00/
Details are in
Either way I suspect the native libs will need to be packaged in a jar file.
As Phil mentions, there are per-platform .class files as well as
per-platform native libraries. One thing to note is that unlike the JDK
build, all class files for Windows, Linux, and Mac are set up to be
built (but n
Murali,
Please review this simple test-only fix to correct a bad merge:
https://bugs.openjdk.java.net/browse/JDK-8201619
http://cr.openjdk.java.net/~kcr/8201619/webrev/
This only affects 8u-dev, since the merge in questions was done when
merging changes from 8u171 into 8u172.
-- Kevin
The native libraries are quite large -- especially jfxwebkit -- and it
does seem better to have per-platform jar files, at least for the native
libraries. The following modules could be platform-independent since
they have no natives:
javafx.base
javafx.controls
javafx.fxml
javafx.swing
We wo
rm.
Also what if anything do the jigsaw team recommend ?
-Phil.
> On Apr 30, 2018, at 4:07 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
wrote:
>
> The native libraries are quite large -- especially jfxwebkit --
and it does seem better to ha
On 4/30/2018 8:58 AM, Michael Paus wrote:
Am 30.04.18 um 17:29 schrieb Kevin Rushforth:
One thing to note is that unlike the JDK build, all class files for
Windows, Linux, and Mac are set up to be built (but not shipped) on
all three platforms, so it might be possible to create a jar file
inline
On 5/2/2018 4:52 PM, Nir Lisker wrote:
Thanks Murali,
I won’t suggest reading level value from log/config file.
Is that file user facing? If so, wouldn't ignoring the level set in the
file break current behavior? Would there need to be follow-up changes to
this file to remove the leve
701 - 800 of 5031 matches
Mail list logo
