Re: Bug when combining ListView and SortedList?

[fastegal]

Zitat von "Fisher, Robert" :


https://bugs.openjdk.java.net/browse/JDK-8141124

This is a regression introduced in 1.8.0_60, so it might have a  
different origin than the problems you mention.




Thanks!

You are right, the "visible" behavior indeed is a regression. The  
underlying reason - incorrect handling of disjoint changes - is the  
same, just a technical variant :-) Commented the issue.


The old version "just" fired incorrect changes, the new doesn't even  
update the selection as needed.


Cheers
Jeanette

Re: pisces, produceFillAlphas

[Felix Bembrick]

Hi Johan,

Have you been able to find enough time to be able to answer this question? In 
my present situation, clarity on these issues is extremely important to me and 
I would guess to many others as well.

Thanks,

Felix 

> On 18 Oct 2015, at 19:01, Felix Bembrick  wrote:
> 
> Hi Johan,
> 
> If you have been getting acceptable but not stunning performance on Android 
> and all this time hardware acceleration was not being utilised then it sounds 
> like there is some serious room for some dramatic performance increases.
> 
> Not being that familiar with the finer points of how JavaFX is implemented on 
> Android, just how much work is involved in accessing that hardware 
> acceleration?  Any timeline?
> 
> I expect that implementing this significant change could be a make-or-break 
> factor in determining whether JavaFX is truly viable and successful on 
> Android.
> 
> Good luck Johan!
> 
> Cheers,
> 
> Felix 
> 
>> On 17 Oct 2015, at 19:49, Johan Vos  wrote:
>> 
>> As a follow-up on the second part: after about 2 years working on JavaFX on
>> Android, I discovered we are not even using Hardware Acceleration. We
>> create a SurfaceView and render on that, but it turns out SurfaceView is
>> never Hardware Accelerated. The positive thing is that this means there is
>> even more room for optimization :)
>> 
>> - Johan
>> 
>>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos  wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for the suggestions. There are 2 different things:
>>> 
>>> 1. It seems indeed there is not much being cached, so there are definitely
>>> improvements possible. It also require e.g. VirtualFlow to use the
>>> Node.setCache(true) in order to cache. The combination of this with the
>>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty
>>> is memory, but so far, we didn't run into issues with too high GC activity.
>>> 
>>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times
>>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns).
>>> I'll have to look into some EGL options.
>>> 
>>> - Johan
>>> 
>>> 
>>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham 
>>> wrote:
>>> 
 Chien pointed out a system property that is currently disabling the
 scrolling optimization.  For its implementation look at CacheFilter.java,
 in particular the invalidateByTranslation() method and all that it kicks
 off.
 
 Another thing to look at is that we added alpha batching to the code
 which should be batching all of the output of the produceAlphas calls into
 a texture and then drawing all of the quads together - provided that they
 are all being filled with simple colors (they can have alpha, but they
 can't be gradients, etc.).  This should be managed by the
 BaseContext.updateMaskTexture() method which controls the single batch
 texture.
 
 Again, are there similar number of invocations of the glDrawElements on
 the 2 platforms?
 
   ...jim
 
> On 10/15/15 12:30 PM, Johan Vos wrote:
> 
> Thanks Jim.
> I tried with different optimization flags, but it doesn't make a big
> difference. Tracing it down to system calls, somehow the gl
> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads
> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS)
> per invocation. The number of invocations is comparable between iOS and
> Android.
> 
> If you can give me a direction on where to search for the disabled
> scrolling optimization, I'll try to re-enable that and see how it
> improves performance. It might be a huge and quick win...
> 
> Thanks again,
> 
> - Johan
> 
> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham  > wrote:
> 
>   Perhaps optimization flags with the native compiler?  Also, was it
>   called a similar number of times on both?
> 
>   Ideally we'd just be using copyArea for the scrolling, but at one
>   point we disabled the scrolling optimizations on retina MBP because
>   they didn't work with a scale factor and I don't think we reenabled
>   them yet.  That would kill scrolling performance on mobile as a
>   result of having to rerender the scene on each scroll regardless of
>   how long produceAlphas takes...
> 
>...jim
> 
> 
>   On 10/15/15 4:27 AM, Johan Vos wrote:
> 
>   After spending lots of time optimizing JavaFX on iOS, I am now
>   at the point
>   where scrolling is 10 times faster on iOS than on Android.
>   The scrolling in the iOS version of the Gluon JavaOne mobile
>   schedule
>   builder is pretty good imho. On Android, it is much slower. I
>   

FW: [9] Review request for JDK-8134716 - Remove use of internal classes methods from toys/Hello

[Elina Kleyman]

Kevin, guys,

 

HelloFPS.java and HelloHighContrast.java can't be removed, therefore they 
should be moved to rt/tests.

Please review the following solution:

BUG: https://bugs.openjdk.java.net/browse/JDK-8134716

WEBREV: http://cr.openjdk.java.net/~ekleyman/JDK-8134716/

 

Thanks,

Elina

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Kevin Rushforth]

[taking awt-dev off of this thread]

The fix that was put into 8u72-b02 is that the packager will no longer 
include libjfxwebkit.dylib in the packaged app. Is this not working 
correctly?


-- Kevin


Sergey Bylokhov wrote:
I think openjfx-dev@openjdk.java.net (cc) is correct place to ask this 
question.


On 16.11.15 23:10, Ondřej Kvasnovský wrote:

Hi,

We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue here, with
all my findings:
http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html 



In short, the issue is that we are not able to release Java app into app
store since 1.8_60 because it uses private API (see the link above if
you want to know how to verify that).

I spoke about this issue with Martijn Verburg and he pointed me to these
two issues:
https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
(replace private libs with public ones)

I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
https://jdk8.java.net/download.html):
otool -L
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 


| grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
version 51.1.0)
And it the issue is still there, Build b05 still references private API.

I could even try to build and app and try to publish it for code review
by Apple... but since there is this reference, I do not believe it is
going to be successful.

Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
considered to be fixed, but it seems it is not, could someone help with
that?


Best wishes,
Ondrej Kvasnovsky

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Dr. Michael Paus]

Just in order to better understand this issue and the fix. Does this 
mean that the packager
will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? 
That would mean
that I could not bundle and distribute any application anymore for the 
Mac which uses
a WebView. Have you considered the fact that many people do bundle their 
apps but
have their own distribution channels and do not upload the apps to the 
Apple store.

There should at least be some switch to override this behavior.
Just my 2+1/2 cents.
Michael




Am 17.11.15 um 18:31 schrieb Kevin Rushforth:

[taking awt-dev off of this thread]

The fix that was put into 8u72-b02 is that the packager will no longer 
include libjfxwebkit.dylib in the packaged app. Is this not working 
correctly?


-- Kevin


Sergey Bylokhov wrote:
I think openjfx-dev@openjdk.java.net (cc) is correct place to ask 
this question.


On 16.11.15 23:10, Ondřej Kvasnovský wrote:

Hi,

We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue here, 
with

all my findings:
http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html 



In short, the issue is that we are not able to release Java app into 
app

store since 1.8_60 because it uses private API (see the link above if
you want to know how to verify that).

I spoke about this issue with Martijn Verburg and he pointed me to 
these

two issues:
https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
(replace private libs with public ones)

I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
https://jdk8.java.net/download.html):
otool -L
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 


| grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
version 51.1.0)
And it the issue is still there, Build b05 still references private 
API.


I could even try to build and app and try to publish it for code review
by Apple... but since there is this reference, I do not believe it is
going to be successful.

Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
considered to be fixed, but it seems it is not, could someone help with
that?


Best wishes,
Ondrej Kvasnovsky

Re: Bug when combining ListView and SortedList?

[fastegal]

Jonathan,

thanks for the clarification, I indeed misunderstood the new tag.

On the other hand: not all (related) selection issues are tagged as such,
are those in danger of not being fixed for 9?

Anyway, all of them _could_ be fixed in one stroke by throwing away
the evil MultipleSelectionModelBase, particularly its usage of
ReadOnlyUnbackedObservableList which forces those ominous manual
change notifications (which are not trivial to get right).

Instead, implement a bitset-backed observableList with the available
(since 8, very sound in my experience) collections infrastructure
that does all the heavy lifting plus a coupled (kind-of transformed)
items list. You know where to find a POC replacement :-)

CU
Jeanette

HEADS-UP: switching to gradle 2.8 for FX 9 builds

[Kevin Rushforth]

As a heads-up, we will be switching FX 9 production builds to using 
gradle 2.8 for building in the near future. See:


https://bugs.openjdk.java.net/browse/JDK-8090171

Very soon -- later this week if all goes well -- we will "flip the 
switch" to make 2.8 the default for building the FX jake bits (for 
Jigsaw). Not too long after that we will make 2.8 the default for 9-dev.


Here is a rough timeline that we are considering:

11/20 - switch 9-jake nightly builds to gradle 2.8
12/4 - switch 9-dev nightly builds to gradle 2.8
12/7 - switch 9 master builds to gradle 2.8
12/11 - push change to make 2.8 the minimum supported version

All developers will need to upgrade to gradle 2.8 before the 12/11 date. 
Note that you don't need to wait that long. I've been using gradle 2.8 
for over a week on all of my machines (and earlier gradle 2.X versions 
for longer).


Note that FX 8u will continue to build with gradle 1.8, although it is 
buildable with gradle 2.X for developers.


-- Kevin

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Kevin Rushforth]

Yes, this is correct. We consider this only a short term workaround for 
the problem. A longer term solution will be needed that will allow 
distributing WebView applications.


Chris: is there a way to override this behavior?

-- Kevin


Dr. Michael Paus wrote:
Just in order to better understand this issue and the fix. Does this 
mean that the packager
will now ALWAYS delete the libjfxwebkit.dylib when building a DMG 
file? That would mean
that I could not bundle and distribute any application anymore for the 
Mac which uses
a WebView. Have you considered the fact that many people do bundle 
their apps but
have their own distribution channels and do not upload the apps to the 
Apple store.

There should at least be some switch to override this behavior.
Just my 2+1/2 cents.
Michael




Am 17.11.15 um 18:31 schrieb Kevin Rushforth:

[taking awt-dev off of this thread]

The fix that was put into 8u72-b02 is that the packager will no 
longer include libjfxwebkit.dylib in the packaged app. Is this not 
working correctly?


-- Kevin


Sergey Bylokhov wrote:
I think openjfx-dev@openjdk.java.net (cc) is correct place to ask 
this question.


On 16.11.15 23:10, Ondřej Kvasnovský wrote:

Hi,

We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue here, 
with

all my findings:
http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html 



In short, the issue is that we are not able to release Java app 
into app

store since 1.8_60 because it uses private API (see the link above if
you want to know how to verify that).

I spoke about this issue with Martijn Verburg and he pointed me to 
these

two issues:
https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
(replace private libs with public ones)

I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
https://jdk8.java.net/download.html):
otool -L
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 


| grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
version 51.1.0)
And it the issue is still there, Build b05 still references private 
API.


I could even try to build and app and try to publish it for code 
review

by Apple... but since there is this reference, I do not believe it is
going to be successful.

Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
considered to be fixed, but it seems it is not, could someone help 
with

that?


Best wishes,
Ondrej Kvasnovsky

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Danno Ferrin]

Not for a DMG file, just .pkgs that are intended for the app store.

So .app, .dmg, and normal .pkgs will have unaltered jres.  The Mac App Store 
.pkgs will be made to conform to mac app store standards.

> On Nov 17, 2015, at 11:50 AM, Dr. Michael Paus  wrote:
> 
> Just in order to better understand this issue and the fix. Does this mean 
> that the packager
> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? That 
> would mean
> that I could not bundle and distribute any application anymore for the Mac 
> which uses
> a WebView. Have you considered the fact that many people do bundle their apps 
> but
> have their own distribution channels and do not upload the apps to the Apple 
> store.
> There should at least be some switch to override this behavior.
> Just my 2+1/2 cents.
> Michael
> 
> 
> 
> 
> Am 17.11.15 um 18:31 schrieb Kevin Rushforth:
>> [taking awt-dev off of this thread]
>> 
>> The fix that was put into 8u72-b02 is that the packager will no longer 
>> include libjfxwebkit.dylib in the packaged app. Is this not working 
>> correctly?
>> 
>> -- Kevin
>> 
>> 
>> Sergey Bylokhov wrote:
>>> I think openjfx-dev@openjdk.java.net (cc) is correct place to ask this 
>>> question.
>>> 
>>> On 16.11.15 23:10, Ondřej Kvasnovský wrote:
 Hi,
 
 We are facing to an issue with latest Java updates when we try to
 release apps into Apple app store. I have described the issue here, with
 all my findings:
 http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html
  
 
 In short, the issue is that we are not able to release Java app into app
 store since 1.8_60 because it uses private API (see the link above if
 you want to know how to verify that).
 
 I spoke about this issue with Martijn Verburg and he pointed me to these
 two issues:
 https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
 https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
 (replace private libs with public ones)
 
 I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
 https://jdk8.java.net/download.html):
 otool -L
 /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
  
 | grep icu
 /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
 version 51.1.0)
 And it the issue is still there, Build b05 still references private API.
 
 I could even try to build and app and try to publish it for code review
 by Apple... but since there is this reference, I do not believe it is
 going to be successful.
 
 Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
 considered to be fixed, but it seems it is not, could someone help with
 that?
 
 
 Best wishes,
 Ondrej Kvasnovsky
>>> 
>>> 
> 

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Michael Hall]

> On Nov 17, 2015, at 11:31 AM, Kevin Rushforth  
> wrote:
> 
> [taking awt-dev off of this thread]
> 
> The fix that was put into 8u72-b02 is that the packager will no longer 
> include libjfxwebkit.dylib in the packaged app. Is this not working correctly?

> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from 
> https://jdk8.java.net/download.html ):
> otool -L 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
>  | grep icu
>   /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current 
> version 51.1.0)
> And it the issue is still there, Build b05 still references private API.

If I followed this correctly the OP seems to be saying that libfxwebkit.dylib 
is present in 1.8.0_72 b05? So that fix did not work correctly somehow.
Is there any chance the change, which was to remove this(?) was missed or 
disappeared between b02 and b05?

Michael Hall

Re: pisces, produceFillAlphas

[Johan Vos]

This is an ongoing effort.
Performance is #1 on my list, but it is also a very complex issue. I will
inform this list on relevant progress I make. It is impossible to say how
much time I need for this, but in the end, I'll get there (and only then I
will be able to tell how much time it took).

- Johan

On Tue, Nov 17, 2015 at 11:56 AM, Felix Bembrick 
wrote:

> Hi Johan,
>
> Have you been able to find enough time to be able to answer this question?
> In my present situation, clarity on these issues is extremely important to
> me and I would guess to many others as well.
>
> Thanks,
>
> Felix
>
> > On 18 Oct 2015, at 19:01, Felix Bembrick 
> wrote:
> >
> > Hi Johan,
> >
> > If you have been getting acceptable but not stunning performance on
> Android and all this time hardware acceleration was not being utilised then
> it sounds like there is some serious room for some dramatic performance
> increases.
> >
> > Not being that familiar with the finer points of how JavaFX is
> implemented on Android, just how much work is involved in accessing that
> hardware acceleration?  Any timeline?
> >
> > I expect that implementing this significant change could be a
> make-or-break factor in determining whether JavaFX is truly viable and
> successful on Android.
> >
> > Good luck Johan!
> >
> > Cheers,
> >
> > Felix
> >
> >> On 17 Oct 2015, at 19:49, Johan Vos  wrote:
> >>
> >> As a follow-up on the second part: after about 2 years working on
> JavaFX on
> >> Android, I discovered we are not even using Hardware Acceleration. We
> >> create a SurfaceView and render on that, but it turns out SurfaceView is
> >> never Hardware Accelerated. The positive thing is that this means there
> is
> >> even more room for optimization :)
> >>
> >> - Johan
> >>
> >>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Thanks for the suggestions. There are 2 different things:
> >>>
> >>> 1. It seems indeed there is not much being cached, so there are
> definitely
> >>> improvements possible. It also require e.g. VirtualFlow to use the
> >>> Node.setCache(true) in order to cache. The combination of this with the
> >>> prism.scrollcacheopt reduces the rendering calls. I think the only
> penalty
> >>> is memory, but so far, we didn't run into issues with too high GC
> activity.
> >>>
> >>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100
> times
> >>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs
> 1000ns).
> >>> I'll have to look into some EGL options.
> >>>
> >>> - Johan
> >>>
> >>>
> >>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham 
> >>> wrote:
> >>>
>  Chien pointed out a system property that is currently disabling the
>  scrolling optimization.  For its implementation look at
> CacheFilter.java,
>  in particular the invalidateByTranslation() method and all that it
> kicks
>  off.
> 
>  Another thing to look at is that we added alpha batching to the code
>  which should be batching all of the output of the produceAlphas calls
> into
>  a texture and then drawing all of the quads together - provided that
> they
>  are all being filled with simple colors (they can have alpha, but they
>  can't be gradients, etc.).  This should be managed by the
>  BaseContext.updateMaskTexture() method which controls the single batch
>  texture.
> 
>  Again, are there similar number of invocations of the glDrawElements
> on
>  the 2 platforms?
> 
>    ...jim
> 
> > On 10/15/15 12:30 PM, Johan Vos wrote:
> >
> > Thanks Jim.
> > I tried with different optimization flags, but it doesn't make a big
> > difference. Tracing it down to system calls, somehow the gl
> > implementation seems be be slower (glDrawElements(GL_TRIANGLES,
> numQuads
> > * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on
> iOS)
> > per invocation. The number of invocations is comparable between iOS
> and
> > Android.
> >
> > If you can give me a direction on where to search for the disabled
> > scrolling optimization, I'll try to re-enable that and see how it
> > improves performance. It might be a huge and quick win...
> >
> > Thanks again,
> >
> > - Johan
> >
> > On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham  > > wrote:
> >
> >   Perhaps optimization flags with the native compiler?  Also, was it
> >   called a similar number of times on both?
> >
> >   Ideally we'd just be using copyArea for the scrolling, but at one
> >   point we disabled the scrolling optimizations on retina MBP because
> >   they didn't work with a scale factor and I don't think we reenabled
> >   them yet.  That would kill scrolling performance on 

[Review request] 8090865: Please make Toolkit.enterNestedEventLoop and exitNestedEventLoop public API

[Jonathan Giles]

Hi all,

Please review the new API proposal for the ability to enter and exit 
nested event loops at the URL below. The proposed patch file is attached 
to the jira issue.


https://bugs.openjdk.java.net/browse/JDK-8090865

Thanks,
-- Jonathan

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Chris Bensen]

The change is only for the Mac App Store. You can easily look at the changeset 
associated with JDK-8138650 to verify this:

http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/761213753af4 



This is the relevant code change:

+++ 
b/modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java
Fri Oct 02 15:33:14 2015 -0600 

@@ -290,13 +290,33 @@ 

 
I18N.getString("error.non-existent-runtime.advice"))); 

 } 
  
-if (new File(baseDir, 
"Contents/Home/lib/libjfxmedia_qtkit.dylib").exists() 

-|| new File(baseDir, 
"Contents/Home/jre/lib/libjfxmedia_qtkit.dylib").exists()) 

-{ 
+int majorVersion; 

+int updateVersion; 

+ 
+try { 

+majorVersion = 
Integer.parseInt(params.get(".runtime.version.major").toString()); 

+updateVersion = 
Integer.parseInt(params.get(".runtime.version.update").toString()); 

+} catch (Exception e) { 

+// assume the worst 

+majorVersion = 8; 

+updateVersion = 60; 

+} 
+ 
+// Quicktime 

+// before 8u40 it was all of media 

+// after 8u40 QTKit dependencies are isolated in it's own library 

+if (majorVersion == 8 && updateVersion >= 40) { 

 
rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxmedia_qtkit.dylib")); 

 } else { 

 rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxmedia.dylib")); 

 } 
+ 
+// webkit 

+// 8u60 webkit started using an API Apple didn't like 

+if (majorVersion == 8 && updateVersion >= 60) { 

+rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxwebkit.dylib")); 

+} 
+ 
 return rules.toArray(new JreUtils.Rule[rules.size()]); 

 }

Chris


> On Nov 17, 2015, at 11:00 AM, Kevin Rushforth  
> wrote:
> 
> Yes, this is correct. We consider this only a short term workaround for the 
> problem. A longer term solution will be needed that will allow distributing 
> WebView applications.
> 
> Chris: is there a way to override this behavior?
> 
> -- Kevin
> 
> 
> Dr. Michael Paus wrote:
>> Just in order to better understand this issue and the fix. Does this mean 
>> that the packager
>> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? That 
>> would mean
>> that I could not bundle and 

Re: HEADS-UP: switching to gradle 2.8 for FX 9 builds

[Kevin Rushforth]

And of course right after I sent this out, I see that gradle 2.9 was 
released today.


If testing looks good, we might switch to 2.9 instead.

-- Kevin


Kevin Rushforth wrote:
As a heads-up, we will be switching FX 9 production builds to using 
gradle 2.8 for building in the near future. See:


https://bugs.openjdk.java.net/browse/JDK-8090171

Very soon -- later this week if all goes well -- we will "flip the 
switch" to make 2.8 the default for building the FX jake bits (for 
Jigsaw). Not too long after that we will make 2.8 the default for 9-dev.


Here is a rough timeline that we are considering:

11/20 - switch 9-jake nightly builds to gradle 2.8
12/4 - switch 9-dev nightly builds to gradle 2.8
12/7 - switch 9 master builds to gradle 2.8
12/11 - push change to make 2.8 the minimum supported version

All developers will need to upgrade to gradle 2.8 before the 12/11 
date. Note that you don't need to wait that long. I've been using 
gradle 2.8 for over a week on all of my machines (and earlier gradle 
2.X versions for longer).


Note that FX 8u will continue to build with gradle 1.8, although it is 
buildable with gradle 2.X for developers.


-- Kevin

Re: Bug when combining ListView and SortedList?

[Jonathan Giles]

If there are any that I've missed or that you think are higher priority, 
leave a comment in the jira issue or email me the issue IDs.


-- Jonathan

On 18/11/15 1:55 AM, faste...@swingempire.de wrote:


Jonathan,

thanks for the clarification, I indeed misunderstood the new tag.

On the other hand: not all (related) selection issues are tagged as such,
are those in danger of not being fixed for 9?

Anyway, all of them _could_ be fixed in one stroke by throwing away
the evil MultipleSelectionModelBase, particularly its usage of
ReadOnlyUnbackedObservableList which forces those ominous manual
change notifications (which are not trivial to get right).

Instead, implement a bitset-backed observableList with the available
(since 8, very sound in my experience) collections infrastructure
that does all the heavy lifting plus a coupled (kind-of transformed)
items list. You know where to find a POC replacement :-)

CU
Jeanette

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Scott Palmer]

> On Nov 17, 2015, at 7:21 PM, Michael Hall  wrote:
> 
>> On Nov 17, 2015, at 11:31 AM, Kevin Rushforth  
>> wrote:
>> 
>> [taking awt-dev off of this thread]
>> 
>> The fix that was put into 8u72-b02 is that the packager will no longer 
>> include libjfxwebkit.dylib in the packaged app. Is this not working 
>> correctly?
> 
>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from 
>> https://jdk8.java.net/download.html ):
>> otool -L 
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
>>  | grep icu
>>  /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current 
>> version 51.1.0)
>> And it the issue is still there, Build b05 still references private API.
> 
> If I followed this correctly the OP seems to be saying that libfxwebkit.dylib 
> is present in 1.8.0_72 b05? So that fix did not work correctly somehow.
> Is there any chance the change, which was to remove this(?) was missed or 
> disappeared between b02 and b05?
> 
> Michael Hall

What you’ve copied above shows that libfxwebkit.dylib is present in the JDK.  
Not that it is present in a JRE bundled in an App Store packaged application.

The libfxwebkit.dylib still references the private API. which is why, as Kevin 
mentioned, that library is removed when packaging for the App Store.

A longer term solution is still needed for those the want to use WebKit and 
still submit apps to the App Store.

Scott

[9] RFR: 8091485: Ensemble8: Review each sample description, playground, appearance, related docs and links

[Morris Meyer]

Kevin, Jonathan and Leif,

Could you please review my changes for 8091485?  The issues that I found 
are enumerated in the bug description.


Thanks much,

--morris

WEBREV - http://cr.openjdk.java.net/~morris/JDK-8091485.01/
BUG - https://bugs.openjdk.java.net/browse/JDK-8091485

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Sergey Bylokhov]

I think openjfx-dev@openjdk.java.net (cc) is correct place to ask this 
question.


On 16.11.15 23:10, Ondřej Kvasnovský wrote:

Hi,

We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue here, with
all my findings:
http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html

In short, the issue is that we are not able to release Java app into app
store since 1.8_60 because it uses private API (see the link above if
you want to know how to verify that).

I spoke about this issue with Martijn Verburg and he pointed me to these
two issues:
https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
(replace private libs with public ones)

I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
https://jdk8.java.net/download.html):
otool -L
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib
| grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
version 51.1.0)
And it the issue is still there, Build b05 still references private API.

I could even try to build and app and try to publish it for code review
by Apple... but since there is this reference, I do not believe it is
going to be successful.

Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
considered to be fixed, but it seems it is not, could someone help with
that?


Best wishes,
Ondrej Kvasnovsky



--
Best regards, Sergey.