from:"David DeHaven"

[9] RfR: 8091078: [JavaDoc] Mispelling in MediaView Constructor documentation

2017-04-06 Thread David DeHaven

Kevin, Alexander, please review this rather trivial javadoc fix for 9.

JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8091078

Patch:
diff --git 
a/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java 
b/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java
--- a/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java
+++ b/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java
@@ -325,7 +325,7 @@
  * 
  * MediaPlayer player; // initialization omitted
  * MediaView view = new MediaView();
- * view.setPlayer(player);
+ * view.setMediaPlayer(player);
  * 
  *
  * @param mediaPlayer the {@link MediaPlayer} the playback of which is to 
be

(patch is also in the JBS issue)

-DrD-

[9] RfR: 8177428: [test] Ensemble cannot play AudioClip files when running in Java 8 and hosted over http

2017-03-23 Thread David DeHaven


Kevin, please review this fix for the Ensemble test app. The bug affects JDK 8 
so will need to be back ported.

JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8177428

Webrev:
http://cr.openjdk.java.net/~ddehaven/8177428/rt.v0/

-DrD-

Re: CFV: New OpenJFX Committer: Ramesh Gangadhar

2017-01-18 Thread David DeHaven


Vote: Yes

-DrD-

> On Jan 18, 2017, at 1:53 PM, Kevin Rushforth  
> wrote:
> 
> I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer.
> 
> Ramesh is a member of JavaFX SQE team at Oracle working on test development 
> for the Java packager, who has contributed 20 changesets to OpenJFX, at least 
> 8 of which [5] are significant.
> 
> Votes are due by February 1, 2017.
> 
> Only current OpenJFX Committers [2] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3]. Nomination to a project 
> Committer is described in [4].
> 
> Thanks,
> 
> -- Kevin
> 
> 
> [1] http://openjdk.java.net/census#rgangadhar
> 
> [2] http://openjdk.java.net/census#openjfx
> 
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 
> [4] http://openjdk.java.net/projects#project-committer
> 
> [5]  List of significant changesets:
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138
> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1
>

Re: Planning for JavaFX.next

2016-12-14 Thread David DeHaven


> - RTSP support for MediaPlayer
> - expose gstreamer API for public that allows you to build the pipeline 
> yourself

RTSP was proposed at one point, I think these days supporting something like 
MPEG-DASH might gain more traction.

If we were to implement arbitrary media sources (via NIO) then a community 
developed RTSP frontend could emerge... (hint: vote for the underlying feature)

-DrD-

Re: CFV: New OpenJFX Committer: Victor Drozdov

2016-12-14 Thread David DeHaven

Vote: yes

-DrD-

> On Dec 13, 2016, at 4:21 PM, Chris Bensen  wrote:
> 
> I hereby nominate Victor Drozdov [1] to OpenJFX Committer.
> 
> Victor is a member of Java Deployment team at Oracle working on the Java 
> Packager tool, who has contributed 11 changesets [5] to OpenJFX, at least 8 
> of which are significant.
> 
> Votes are due by January 4, 2017.
> 
> Only current OpenJFX Committers [2] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3]. Nomination to a project 
> Committer is described in [4].
> 
> Thanks,
> 
> [1] http://openjdk.java.net/census#vdrozdov 
> 
> 
> [2] http://openjdk.java.net/census#openjfx 
> 
> 
> [3] http://openjdk.java.net/bylaws#lazy-consensus 
> 
> 
> [4] http://openjdk.java.net/projects#project-committer 
> 
> 
> [5] List of changesets:
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/81268b9c41f6 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4272317a42ad 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/3ca13b05a699 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6dfb3daf92cf 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2b649093eb50 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/2538169ab7bb 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/a6fafaa51082 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ac334db87ed6 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/12e6cb1e78af 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/32cc74546935 
> 
> http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/6b55a303625d 
>

Re: [9] Review request: JDK-8169443 Deprecate Java Packager Blob Signing

2016-12-13 Thread David DeHaven

This is only signing via the  mechanism, which was never fully 
supported or part of any standard. To sign webstart applications (even FX apps) 
just use jarsigner or the associated ant signjar task.

-DrD-

[1] https://ant.apache.org/manual/Tasks/signjar.html

> On Dec 13, 2016, at 11:02 AM, Stefan Fuchs  wrote:
> 
> Hi Chris,
> 
> well I think reason number 1 is not correct. The definition of self signed 
> depends on who created the signing key. If you created it yourself, it is a 
> self signed jar and will rightfully be blocked.
> If you however obtained the signing key from a Certification Authority, that 
> java accepts, it is not a self signed jar and will not be blocked.
> This is a perfectly valid usecase for fxsign jar.
> 
> For the 2nd reason: I don't think many users will go modular for Webstart 
> Applications. Normally you simply pack all your classes in a single big 
> jar-file (and perhaps a second, if you use a preloader).
> This avoids various network round trips, when the application starts and 
> makes deployment much easier.
> 
> 
> Stefan
> 
>> Hi Stefan,
>> 
>> Yes, it is being deprecated. It will continue to function as it has. Two 
>> main reasons for the deprecation are:
>> 
>> 1. Self signed jars are blocked and sign as blob is a self signed jars.
>> 
>> 2. There will be a replacement for modules that will be better.
>> 
>> Chris
>> 
>> 
>>> On Dec 12, 2016, at 11:56 PM, Stefan Fuchs  wrote:
>>> 
>>> Hi,
>>> 
>>> so blog signing as deprecated.
>>> 
>>> What are the reasons for deprecating blog signing? Are there alternatives?
>>> How do I sign a webstart application?
>>> 
>>> Stefan
>>> 
 David,
 
 Please review these changes to deprecate the blob signing from the Java 
 Packager.
 
 JIRA: https://bugs.openjdk.java.net/browse/JDK-8169443 
 
 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8169443/webrev.00/ 
 
 
 Chris
>> 
>

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

2016-11-17 Thread David DeHaven

There's no way to specify a ClassLoader when loading from a Module, so there's 
not much point in passing it. Also, the only case where appLoader will be 
non-null is LM_JAR with JavaFX-Class-Path, so mainModule and appLoader are 
mutually exclusive.

-DrD-

> I think you missed one place:
> 
> +lawa.invoke(null, new Object[] {null, mainClassName, 
> preloaderClassName, appArgs});
> 
> 
> You will want to pass in mainModule as the first argument here, too.
> 
> -- Kevin
> 
> 
> David DeHaven wrote:
>>>> Looks good with two minor comments:
>>>> 
>>>> 1) It looks like the new "mainModule" parameter to 
>>>> launchApplicationWithArgs is only ever called with "null". Did you intend 
>>>> it to be called with the application module in the case of LM_MODULE?
>>>>   
>>>> 
>>> You're correct... I wonder how that happened. It seems I never finished 
>>> that part, probably due to splitting the work over the weekend :/
>>> 
>>> That needs to be corrected. Shouldn't take long.
>>> 
>>> 
>> 
>> Updated webrev after this mornings dose of 
>> 
>> 
>> http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.1/
>> 
>> 
>> -DrD-
>> 
>>   
>>

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

2016-11-17 Thread David DeHaven


>> Looks good with two minor comments:
>> 
>> 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs 
>> is only ever called with "null". Did you intend it to be called with the 
>> application module in the case of LM_MODULE?
> 
> You're correct... I wonder how that happened. It seems I never finished that 
> part, probably due to splitting the work over the weekend :/
> 
> That needs to be corrected. Shouldn't take long.

Updated webrev after this mornings dose of 

http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.1/

-DrD-

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

2016-11-17 Thread David DeHaven


> Looks good with two minor comments:
> 
> 1) It looks like the new "mainModule" parameter to launchApplicationWithArgs 
> is only ever called with "null". Did you intend it to be called with the 
> application module in the case of LM_MODULE?

You're correct... I wonder how that happened. It seems I never finished that 
part, probably due to splitting the work over the weekend :/

That needs to be corrected. Shouldn't take long.

-DrD-

Re: [9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

2016-11-16 Thread David DeHaven


Ping? The OpenJDK portion is reviewed and ready to push. I'd prefer to push 
them at the same time so we don't have a bug that appears to be resolved when 
it isn't.

-DrD-

> Please review the JavaFX changes needed for this issue:
> https://bugs.openjdk.java.net/browse/JDK-8169289
> 
> webrev:
> http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0
> 
> For reference, the OpenJDK changes needed are here:
> http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/
> 
> These are being reviewed separately on core-libs-...@openjdk.java.net
> 
> 
> I've tested the following cases so far:
> LM_CLASS_1  : -cp some.jar main.class
> LM_CLASS_2  : -cp path/to/loose/classes main.class
> LM_JAR_1: -jar some.jar (Main-Class)
> LM_JAR_2: -jar some.jar (Main-Class + JavaFX-Application-Class) <- JAC 
> should take precedence
> LM_MODULE_1 : -m module/main.class
> LM_MODULE_2 : -m module (main class declared in module-info)
> 
> 
> and one more in progress:
> LM_JAR_3: -jar some.jar (Main-Class + JavaFX-Class-Path) <- creates new 
> ClassLoader
> 
> 
> I've tested all combinations of having changes (or not) to openjfx and 
> openjdk and there are no unexpected results, the only cases that fail are the 
> LM_MODULE launch modes which fail currently. This means the changes can be 
> pushed in any order.
> 
> I will create unit tests for this, but don't want to push it since this 
> change is split between OpenJFX and OpenJDK (else LM_MODULE modes will just 
> fail until everything is in sync). I'll file a separate issue to push the 
> unit tests at the appropriate time.
> 
> A couple other notes:
> - I brought over changes for handling diacritical marks on MacOS X [1], moved 
> class loading to a new method
> - I assumed not having a default preloader for the -jar case was a bug, so I 
> fixed it
> 
> -DrD-
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8017248
>

Re: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144

2016-11-14 Thread David DeHaven

No, this is a requirement for other, jigsaw related things.

-DrD-

> Is this going to be a weekly event ?
> 
> -phil.
> 
> On 11/14/2016 09:51 AM, Kevin Rushforth wrote:
>> +1
>> 
>> Note that this will need to wait until after the repo is "unlocked" at 1pm 
>> PT.
>> 
>> -- Kevin
>> 
>> 
>> David DeHaven wrote:
>>> Kevin, David, please review this trivial change to bump the minimum JDK 
>>> version to 9-ea+b144 which is now available on java.net.
>>> 
>>> JBS Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8169271
>>> 
>>> The diff is in a comment in the JBS issue, no webrev.
>>> 
>>> -DrD-
>>> 
>

Re: [9] RFR: 8169271: Bump JavaFX minimum build JDK to b144

2016-11-14 Thread David DeHaven


That should be fine. I still want to do test builds with other things that are 
going on.

-DrD-

> +1
> 
> Note that this will need to wait until after the repo is "unlocked" at 1pm PT.
> 
> -- Kevin
> 
> 
> David DeHaven wrote:
>> Kevin, David, please review this trivial change to bump the minimum JDK 
>> version to 9-ea+b144 which is now available on java.net.
>> 
>> JBS Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8169271
>> 
>> The diff is in a comment in the JBS issue, no webrev.
>> 
>> -DrD-
>> 
>>

[9] RFR: 8169271: Bump JavaFX minimum build JDK to b144

2016-11-14 Thread David DeHaven


Kevin, David, please review this trivial change to bump the minimum JDK version 
to 9-ea+b144 which is now available on java.net.

JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8169271

The diff is in a comment in the JBS issue, no webrev.

-DrD-

[9] RfR: 8169289: JavaFX application in named module fails to launch if no main method

2016-11-10 Thread David DeHaven


Please review the JavaFX changes needed for this issue:
https://bugs.openjdk.java.net/browse/JDK-8169289

webrev:
http://cr.openjdk.java.net/~ddehaven/8169289/openjfx-rt.0

For reference, the OpenJDK changes needed are here:
http://cr.openjdk.java.net/~ddehaven/8169289/jdk.0/

These are being reviewed separately on core-libs-...@openjdk.java.net


I've tested the following cases so far:
LM_CLASS_1  : -cp some.jar main.class
LM_CLASS_2  : -cp path/to/loose/classes main.class
LM_JAR_1: -jar some.jar (Main-Class)
LM_JAR_2: -jar some.jar (Main-Class + JavaFX-Application-Class) <- JAC 
should take precedence
LM_MODULE_1 : -m module/main.class
LM_MODULE_2 : -m module (main class declared in module-info)


and one more in progress:
LM_JAR_3: -jar some.jar (Main-Class + JavaFX-Class-Path) <- creates new 
ClassLoader


I've tested all combinations of having changes (or not) to openjfx and openjdk 
and there are no unexpected results, the only cases that fail are the LM_MODULE 
launch modes which fail currently. This means the changes can be pushed in any 
order.

I will create unit tests for this, but don't want to push it since this change 
is split between OpenJFX and OpenJDK (else LM_MODULE modes will just fail until 
everything is in sync). I'll file a separate issue to push the unit tests at 
the appropriate time.

A couple other notes:
- I brought over changes for handling diacritical marks on MacOS X [1], moved 
class loading to a new method
- I assumed not having a default preloader for the -jar case was a bug, so I 
fixed it

-DrD-

[1] https://bugs.openjdk.java.net/browse/JDK-8017248

[9] RfR: 8137324: Warning from MacOSX for deprecated Carbon Component Manager module

2016-10-28 Thread David DeHaven


Kevin, Alexander, please review the following update to the Apple provided 
CoreAudio utility classes:

JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8137324

Webrev:
http://cr.openjdk.java.net/~ddehaven/8137324/rt.v0/

The change to GstAVPlaybackPipeline.cpp is necessary to avoid a compiler error 
when building with a later version of Xcode. No changes to the media code were 
necessary, since we didn't use Component Manager.

-DrD-

Re: [8u-dev] RfR: backport of JDK-8156563: JavaFX Ensemble8 media sample hang and crash

2016-10-07 Thread David DeHaven


ping?

-DrD-


> Kevin, Alexander, please review my backport of 8156563 to 8u-dev.
> 
> Main issue:
> https://bugs.openjdk.java.net/browse/JDK-8156563
> 
> Backport issue:
> https://bugs.openjdk.java.net/browse/JDK-8167317
> 
> Code review:
> http://cr.openjdk.java.net/~ddehaven/8156563-8u/rt.0/
> 
> -DrD-
>

[8u-dev] RfR: backport of JDK-8156563: JavaFX Ensemble8 media sample hang and crash

2016-10-06 Thread David DeHaven


Kevin, Alexander, please review my backport of 8156563 to 8u-dev.

Main issue:
https://bugs.openjdk.java.net/browse/JDK-8156563

Backport issue:
https://bugs.openjdk.java.net/browse/JDK-8167317

Code review:
http://cr.openjdk.java.net/~ddehaven/8156563-8u/rt.0/

-DrD-

RfR: [9] 8156563: JavaFX Ensemble8 media sample hang and crash

2016-09-09 Thread David DeHaven

Alexander, Kevin, please review my fix for AVFMediaPlayer crashes on OSX:

JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8156563

Webrev:
http://cr.openjdk.java.net/~ddehaven/8156563/rt.0/

I believe this addresses other crashes that have been reported too, those will 
be resolved as duplicates.

-DrD-

Re: Playing a sound at regular intervals

2016-08-24 Thread David DeHaven


I see no reason for that, I'll clean it up and make it public.

-DrD-

> FYI... This issue is not visible to me 
> https://bugs.openjdk.java.net/browse/JDK-8090414
> 
> 
> Scott
> 
>> On Aug 23, 2016, at 10:15 AM, David DeHaven <david.deha...@oracle.com> wrote:
>> 
>> 
>>> We're trying to play a notification sound at a regular interval (every 
>>> 500ms) in a loop.
>>> 
>>> It should sound like "bing.bing.bing." and not like 
>>> "bing..bing..bing...bing" if you know what I mean ;)
>>> 
>>> From the JavaDoc we were guessing that an efficient way to do this would be 
>>> to set cycle count to indefinite on the audio clip / on the media player 
>>> and call play() once.
>>> 
>>> Observations:
>>> - Cycle count doesn't work for mp3 files. No problem, just use WAV.
>>> - The playback does not happen at regular intervals. -> not usable in this 
>>> scenario
>>> 
>>> Our solution so far has been to have a scheduled executor which calls 
>>> audioclip.play() every 500 ms. This creates a new thread every time (see 
>>> stack trace below) and we don't like this approach.
>> 
>> For the moment this is a better solution, until we can get a few internal 
>> things fixed in AudioClip.
>> 
>> In the current implementation there will always be at least one new thread 
>> created.
>> 
>> 
>> There are bugs filed on this already, specifically:
>> https://bugs.openjdk.java.net/browse/JDK-8090414
>> https://bugs.openjdk.java.net/browse/JDK-8087423
>> 
>> And possibly related:
>> https://bugs.openjdk.java.net/browse/JDK-8088375
>> 
>> -DrD-
>>

Re: Playing a sound at regular intervals

2016-08-23 Thread David DeHaven


> We're trying to play a notification sound at a regular interval (every 500ms) 
> in a loop.
> 
> It should sound like "bing.bing.bing." and not like 
> "bing..bing..bing...bing" if you know what I mean ;)
> 
> From the JavaDoc we were guessing that an efficient way to do this would be 
> to set cycle count to indefinite on the audio clip / on the media player and 
> call play() once.
> 
> Observations:
> - Cycle count doesn't work for mp3 files. No problem, just use WAV.
> - The playback does not happen at regular intervals. -> not usable in this 
> scenario
> 
> Our solution so far has been to have a scheduled executor which calls 
> audioclip.play() every 500 ms. This creates a new thread every time (see 
> stack trace below) and we don't like this approach.

For the moment this is a better solution, until we can get a few internal 
things fixed in AudioClip.

In the current implementation there will always be at least one new thread 
created.


There are bugs filed on this already, specifically:
https://bugs.openjdk.java.net/browse/JDK-8090414
https://bugs.openjdk.java.net/browse/JDK-8087423

And possibly related:
https://bugs.openjdk.java.net/browse/JDK-8088375

-DrD-

Re: JDK-8153350 - JavaFX webstart with javaws.exe selects wrong toolkit (unnecessary relaunch)

2016-07-26 Thread David DeHaven


> Hi,
> 
> it may be unrelated to these relaunches, but I have been wondering for 
> awhile, what the toolkit parameter in the  ant element is 
> supposed to do.
> 
> see:
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/javafx_ant_task_reference.html#CIAGCAFH
> 
> At least in my tests changing the parameter had no effect on the generated 
> jnlp file.

Good question.. maybe Chris can answer?

-DrD-

[9] Review Request: 8145602: [macosx] Remove QTKit based media player

2015-12-17 Thread David DeHaven


Kevin, Alexander, please review the changes to remove QTKMediaPlayer and do 
some cleanup in the AVF media player since we no longer build against the 10.7 
SDK.

JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8145602

webrev:
http://cr.openjdk.java.net/~ddehaven/8145602/rt/v0/

Note that this is blocked by JDK-8145604, so this won't be pushed until Kevin 
finishes that.

Also note that I've de-tabbed a few files, so the formatting looks off in the 
webrev (something is expanding the tabs to 8 spaces instead of 4). It looks 
correct in the code, if in doubt you can apply the patch and check it. 
AVFKernelProcessor.cpp and AVFMediaPlayer.mm appear to be unchanged because 
it's whitespace only (de-tabbed) and webrev was set to ignore those changes.

-DrD-

[8u-dev] Review Request for 8144678: JVM crashes when selecting video on youtube in WebView

2015-12-15 Thread David DeHaven

Kevin, Alexander, can you please review this fairly trivial fix:
https://bugs.openjdk.java.net/browse/JDK-8144678

The fix is only five lines, no webrev. It's pasted in a comment and below for 
reference.

--- cut here ---
diff --git 
a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm 
b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm
--- a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm
+++ b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm
@@ -401,6 +401,11 @@
 - (void) dispose {
 @synchronized(self) {
 if (!isDisposed) {
+if (_player != nil) {
+// this should stop and dealloc the audio processor
+_player.currentItem.audioMix = nil;
+}
+
 if (_playerOutput != nil) {
 [_playerItem removeOutput:_playerOutput];
 [_playerOutput setDelegate:nil queue:nil];
--- cut here ---

-DrD-

Re: [8u-dev] Review Request for 8144678: JVM crashes when selecting video on youtube in WebView

2015-12-15 Thread David DeHaven

Yes, I can push to 9-dev first.

-DrD-

> This is going into 9-dev first, right? I'll add comments in JIRA.
> 
> -- Kevin
> 
> 
> David DeHaven wrote:
>> Kevin, Alexander, can you please review this fairly trivial fix:
>> https://bugs.openjdk.java.net/browse/JDK-8144678
>> 
>> The fix is only five lines, no webrev. It's pasted in a comment and below 
>> for reference.
>> 
>> --- cut here ---
>> diff --git 
>> a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm 
>> b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm
>> --- 
>> a/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm
>> +++ 
>> b/modules/media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm
>> @@ -401,6 +401,11 @@
>> - (void) dispose {
>> @synchronized(self) {
>> if (!isDisposed) {
>> +if (_player != nil) {
>> +// this should stop and dealloc the audio processor
>> +_player.currentItem.audioMix = nil;
>> +}
>> +
>> if (_playerOutput != nil) {
>> [_playerItem removeOutput:_playerOutput];
>> [_playerOutput setDelegate:nil queue:nil];
>> --- cut here ---
>> 
>> -DrD-
>> 
>>

Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats

2015-09-02 Thread David DeHaven


Having heard no objections and gaining internal approval, we'll move forward 
with this plan.

-DrD-

> On Aug 26, 2015, at 11:53 AM, David DeHaven <david.deha...@oracle.com> wrote:
> 
> 
> I am proposing we deprecate support for the VP6 video encoding format and the 
> FXM/FLV file format in JFXMedia for Java 9. The current intention is to 
> completely remove support for these components in the Java 10 timeframe. Note 
> that this is only deprecation, Java 9 will still support playback of VP6 
> video in FXM or FLV containers.
> 
> The reasons in favor of deprecation:
> - Use of VP6 on the web has lost favor, it was superseded fairly quickly by 
> H.264/AVC in Flash 9 and Adobe generally recommends using H.264/AVC over it. 
> It's not even recommended for compatibility as as their "Sorenson Spark" 
> H.263 variant has a much longer history in Flash.
> - Tools for generating VP6 are non-trivial, even Adobe products no longer 
> support generating VP6 content out of the box, you have to install add-ons. 
> While there are free tools, none are particularly elegant or easy to use, or 
> produce sub-optimal results. We've heard no end of complaints from the 
> community about the lack of tools for VP6, so it seems a logical decision to 
> migrate away from it.
> - We have had (many) requests to add external codec support, if (that's a big 
> IF, please do NOT take this as any sort of promise or even the hope of a 
> promise!) we were to implement such a feature and if you absolutely had to 
> rely on VP6 then you would be able to provide one yourself.
> - The vp6 codec is the LAST closed source component in media, once removed 
> JFXMedia will be 100% open source. I think we can all agree this is a good 
> thing and something I personally look forward to achieving.
> 
> 
> The one and only reason I can think of for NOT deprecating VP6:
> - It is currently the only format (supported by JFXMedia) which supports an 
> alpha channel, though I have had thoughts on how to address that in a way 
> that would allow the use of practically any media format.
> 
> 
> While compelling for some use cases, it is a very niche use case and thus 
> cannot outweigh the benefits. So, this is a call out to any who may be using 
> VP6, please speak up now so we can discuss it or forever hold your peace.
> 
> 
> For reference, the list of supported formats in JFXMedia are in the JavaDoc 
> for javafx.scene.Media:
> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html#SupportedMediaTypes
> 
> -DrD-
>

Re: [9] Review request for 8131066: JavaFX MediaPlayer crashes on dispose with certain MP4s

2015-09-01 Thread David DeHaven


> Hi David,
> 
> Please review the fix:
> https://bugs.openjdk.java.net/browse/JDK-8131066
> http://cr.openjdk.java.net/~almatvee/8131066/webrev.00/
> 
> Crash happens, because AVPlayer was trying to notify AVFMediaPlayer about 
> frame change after AVFMediaPlayer was released. Fixed by unregistering 
> notification callback before AVFMediaPlayer is released.

Change looks good, approved. I also updated the JBS issue.

-DrD-

Re: hg: openjfx/9-dev/rt: 8043352: JEP 257: Update JavaFX/Media to Newer Version of GStreamer

2015-09-01 Thread David DeHaven


> On Aug 27, 2015, at 6:08 PM, kevin.rushfo...@oracle.com wrote:
> 
> Changeset: 241f9696e3ad
> Author:almatvee
> Date:  2015-08-27 14:35 -0700
> URL:   http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/241f9696e3ad
> 
> 8043352: JEP 257: Update JavaFX/Media to Newer Version of GStreamer
> Reviewed-by: stayer, ddehaven, kcr




-DrD-

Re: CFV: New OpenJFX Committer: Alexander Matveev

2015-08-28 Thread David DeHaven

Vote: YES

-DrD-


 On Aug 27, 2015, at 6:55 PM, Kevin Rushforth kevin.rushfo...@oracle.com 
 wrote:
 
 I hereby nominate Alexander Matveev [1] to OpenJFX Committer.
 
 Alexander was an initial member of JavaFX team at Oracle when the OpenJFX 
 project was created, and was on the initial list of approved committers [2]. 
 His status as OpenJFX committer was not recorded at that time on the Census. 
 This CVF is intended to correct this oversight.
 
 Alexander's changes prior to JavaFX becoming open-source were significant 
 (which is why he was on the initial list of committers). In particular, 
 Alexander, along with the rest of the media team, contributed much of the 
 code that went into the open-source changeset that Kirill Kirichenko pushed 
 for OpenJFX in the JDK 8 release:
 
   hg log -r aee256fde55
 
 Counting his contribution to that changeset, Alexander now also has the 
 requisite number of changes in the open-source repo to become a committer.
 
   hg log -M -u matvee
 
 Votes are due by September 10, 2015.
 
 Only current OpenJFX Committers [3] are eligible to vote on this nomination. 
 Votes must be cast in the open by replying to this mailing list.
 
 For Lazy Consensus voting instructions, see [4]. Nomination to a project 
 Committer is described in [5].
 
 Thanks,
 
 -- Kevin
 
 [1] http://openjdk.java.net/census#almatvee
 
 [2] http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html
 
 [3] http://openjdk.java.net/census#openjfx
 
 [4] http://openjdk.java.net/bylaws#lazy-consensus
 
 [5] http://openjdk.java.net/projects#project-committer

Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats

2015-08-27 Thread David DeHaven


 +1 for deprecation - I haven't used VP6 in a long while, and would value
 the whole thing being open source more than its inclusion.
 
 Out of interest, is this anything to do with JEP 257? I started looking at
 this with Kirill's guidance a year or so ago, but sadly many other things
 had to take precedence so I didn't really have the time.

No, that's unrelated. I suspect we'll hear something about that soon... Oh, I 
see Kevin let the cat out of the bag. Well, there you go :)


 I agree that codecs that are usable by the system’s default media
 framework should work.  However, I believe that is already supported in
 most cases, is it not?
 
 
 It's not - JavaFX can decode the audio / video / container formats that it
 knows about through its GStreamer plugins, and nothing else (unless you
 compile them in yourself, which isn't all that hard.)

Not entirely true... on the Mac, GStreamer does not support HLS, that gets 
routed through QTKit (for = 10.7) or AVFoundation (10.8+). With VP6 gone there 
will actually be no need for GStreamer on Mac at all.


It *used* to be the case that we allowed anything the native platform provided, 
in the previous media stack (JMC if anyone was paying attention).

The big issue, as Kirill pointed out, was it was very difficult to support due 
to the vast combinations of operating systems and codecs/media formats and 
(more importantly) there are security implications.

There are internal discussions ongoing about how we're approaching this 
problem. The security aspects only affect webstart and plugin, standalone 
applications aren't as much of a concern (except from a supportability 
standpoint) so maybe some compromise can be reached.

I would actually favor allowing formats supplied by the underlying native 
platform over trying to figure out how to provide a pluggable codec interface, 
but it needs to be done in a way that's sustainable and does not expose 
security vulnerabilities.

Again, I'm not promising anything, just know that complaints and requests have 
been heard and are being taken into consideration.

-DrD-

Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS

2015-08-26 Thread David DeHaven


 The gradle build tries to find the version of the used Java JDK by running 
 'java -version', skipping the first line and expects to find the version in 
 the second line.
 
 However, on Linux (Ubuntu) the first line of *any* Java invocation is Picked 
 up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar[1], thus 
 failing at detection of the version, aborting the build.
 
 The 'Pickup up...' line is a standard feature of the JDK and a legacy that 
 doesn't seem to be removed soon[2].
 
 I guess the build script needs to accommodate for this.
 
 Proposed fix:
 
 // Determine the verion of Java in JDK_HOME. It looks like this:
 //
 // $ java -version
 // Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
 // java version 1.7.0_45
 // Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
 // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
 //
 // The first line is optional, we need to parse the third line
 def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new 
 java.lang.ProcessBuilder(JAVA, -version).start().getErrorStream()));
 try {
String v = inStream.readLine();
 
if (v != null) {
   if (v.startsWith(Picked up)) {
  inStream.readLine();
   }
 
v = inStream.readLine();

Why not just use java -fullversion instead?

$ java -fullversion
java full version 1.8.0_60-ea-b14

$ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
java full version 1.8.0_60-ea-b14

$ java -version
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)

$ JAVA_TOOL_OPTIONS=-Xmx512M java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx512M
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)

It's a lot less stuff to parse. Also, java -fullversion does not start the 
VM, so should be faster.

-DrD-

[9] Proposal to deprecate VP6 video and the FLV/FXM file formats

2015-08-26 Thread David DeHaven

I am proposing we deprecate support for the VP6 video encoding format and the
FXM/FLV file format in JFXMedia for Java 9. The current intention is to
completely remove support for these components in the Java 10 timeframe. Note
that this is only deprecation, Java 9 will still support playback of VP6 video
in FXM or FLV containers.

The reasons in favor of deprecation:
- Use of VP6 on the web has lost favor, it was superseded fairly quickly by
H.264/AVC in Flash 9 and Adobe generally recommends using H.264/AVC over it.
It's not even recommended for compatibility as as their Sorenson Spark H.263
variant has a much longer history in Flash.
- Tools for generating VP6 are non-trivial, even Adobe products no longer
support generating VP6 content out of the box, you have to install add-ons.
While there are free tools, none are particularly elegant or easy to use, or
produce sub-optimal results. We've heard no end of complaints from the
community about the lack of tools for VP6, so it seems a logical decision to
migrate away from it.
- We have had (many) requests to add external codec support, if (that's a big
IF, please do NOT take this as any sort of promise or even the hope of a
promise!) we were to implement such a feature and if you absolutely had to rely
on VP6 then you would be able to provide one yourself.
- The vp6 codec is the LAST closed source component in media, once removed
JFXMedia will be 100% open source. I think we can all agree this is a good
thing and something I personally look forward to achieving.

The one and only reason I can think of for NOT deprecating VP6:
- It is currently the only format (supported by JFXMedia) which supports an
alpha channel, though I have had thoughts on how to address that in a way that
would allow the use of practically any media format.

While compelling for some use cases, it is a very niche use case and thus
cannot outweigh the benefits. So, this is a call out to any who may be using
VP6, please speak up now so we can discuss it or forever hold your peace.

For reference, the list of supported formats in JFXMedia are in the JavaDoc for
javafx.scene.Media:
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html#SupportedMediaTypes

-DrD-

Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS

2015-08-26 Thread David DeHaven


I can't comment on non-Oracle JDKs, but It's in libjli so anything based on 
OpenJDK should support it.

-DrD-

 I was not aware of the existence of the -fullversion option. It is not listed 
 at the Oracle site, afaik. Can it be assumed to be present in non-OpenJDK, 
 non-Oracle JDKs?
 
 David DeHaven schreef op 2015-08-26 15:38:
 The gradle build tries to find the version of the used Java JDK by running 
 'java -version', skipping the first line and expects to find the version in 
 the second line.
 However, on Linux (Ubuntu) the first line of *any* Java invocation is 
 Picked up JAVA_TOOL_OPTIONS: 
 -javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at detection of 
 the version, aborting the build.
 The 'Pickup up...' line is a standard feature of the JDK and a legacy that 
 doesn't seem to be removed soon[2].
 I guess the build script needs to accommodate for this.
 Proposed fix:
 // Determine the verion of Java in JDK_HOME. It looks like this:
 //
 // $ java -version
 // Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
 // java version 1.7.0_45
 // Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
 // Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
 //
 // The first line is optional, we need to parse the third line
 def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new 
 java.lang.ProcessBuilder(JAVA, -version).start().getErrorStream()));
 try {
   String v = inStream.readLine();
   if (v != null) {
 if (v.startsWith(Picked up)) {
inStream.readLine();
 }
   v = inStream.readLine();
 Why not just use java -fullversion instead?
 $ java -fullversion
 java full version 1.8.0_60-ea-b14
 $ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
 java full version 1.8.0_60-ea-b14
 $ java -version
 java version 1.8.0_60-ea
 Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
 Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
 $ JAVA_TOOL_OPTIONS=-Xmx512M java -version
 Picked up JAVA_TOOL_OPTIONS: -Xmx512M
 java version 1.8.0_60-ea
 Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
 Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
 It's a lot less stuff to parse. Also, java -fullversion does not
 start the VM, so should be faster.
 -DrD-

Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats

2015-08-26 Thread David DeHaven


 +1 for deprecation of VP6 and clearing the way to open sourcing of JFXMedia.
 
 On a related note, you will soon need to support H.265/HEVC.  HEVC apparently 
 also supports an alpha channel, so it may also address that concern. (See 
 http://www.itu.int/rec/T-REC-H.265-201504-I/en)

3D support too! Not sure how we'd handle that though...


 All of this might be much easier to handle if JDK-8091063 is addressed (the 
 open sourcing of JFXMedia may assist with this).
 https://bugs.openjdk.java.net/browse/JDK-8091063
 
 The brilliant guy that filed that issue nearly seven years ago was on to 
 something :-)
 
 Then legacy formats could be provided in optional downloads and new formats 
 can be supported without the need to integrate them within the JRE code.

Yes, that would be wonderful!

-DrD-

Re: MediaView fails to play HLS video encoded with Main Profile?

2015-08-04 Thread David DeHaven


 I'm trying to play an HLS file with mediaview and it is failing with a Media 
 unsupported message, I have been doing some tests with other HLS files and 
 the only difference I've found is the Profile used.
 
 The one that plays says (according to MediaInfo) AVC Baseline@L2.1 - 1 Ref 
 Frames, the one that fails says AVC Main@L3.1 1 - CABAC/ 6 Ref Frames.
 
 Is there anything I can do (other than reencode, not possible) to play it?

What platform? On Mac, it should play any flavor that QuickTime Player can 
since it uses AVFoundation.

-DrD-

Re: Understanding the com.sun.* APIs being (ab)used by the community

2015-06-08 Thread David DeHaven

It'll work as long as the class in question (Screen in this case) is exported. 
If not, you'll likely get a security exception or CNFE.

-DrD-

 On Jun 5, 2015, at 8:28 AM, Kevin Rushforth kevin.rushfo...@oracle.com 
 wrote:
 
 Yes, this will still work, although dipping into non-public state continues 
 to be something we wouldn't recommend that an application rely on...
 
 -- Kevin
 
 
 Dr. Michael Paus wrote:
 As nobody has stated it explicitly so far I would like to ask what will 
 happen
 to classes in Java9 which access methods that are within the javafx 
 namespace but
 are declared private? Will code like this still work or not?
 
public static double getPixelScale(Screen screen) throws 
 NoSuchMethodException, SecurityException, IllegalAccessException, 
 IllegalArgumentException, InvocationTargetException {
Method m = Screen.class.getDeclaredMethod(getScale);
m.setAccessible(true);
return ((Float) m.invoke(screen)).doubleValue();
}
 
 This hack for example is currently necessary because there is no other way 
 to get at
 the current pixel scale of a HiDPI screen.

Re: Private APIs not usable in Java 9?

2015-04-09 Thread David DeHaven

You can see any com.sun.* usage by running jdeps -v some.jar. You'll have to 
sort it all out manually, but it's all there.

-DrD-

 I'll second the recommendation to run jdeps on your apps. I note that it 
 doesn't currently flag internal FX packages as internal. I filed the 
 following RFE to address this:
 
 https://bugs.openjdk.java.net/browse/JDK-8077349
 
 -- Kevin
 
 
 Chris Newland wrote:
 I just asked about this on the adoption-disc...@openjdk.java.net list and
 the answer from Martijn Verburg is:
 
 ---
 Hi Chris,
 
 I think the strong advice for those using private APIs is to run the jdeps
 tool to see where they are using APIs that will go away / be moved. I'd
 then get them to post that list to jigsaw-dev, I guess the root cause of
 some of these issues should also be logged in JBS and fixed :-).
 
 Cheers,
 Martijn
 ---
 
 If you run $JAVA_HOME/bin/jdeps -jdkinternals class dir or jar then it
 will show all uses of JDK private APIs that will go away in JDK9.
 
 An example from one of my own projects:
 
 chris@chris:~$ /home/chris/jdk1.8.0_40/bin/jdeps -jdkinternals
 /home/chris/jitwatch/target/jitwatch-1.0.0-SNAPSHOT.jar
 jitwatch-1.0.0-SNAPSHOT.jar - /home/chris/jdk1.8.0_40/lib/tools.jar
   org.adoptopenjdk.jitwatch.loader.BytecodeLoader
 (jitwatch-1.0.0-SNAPSHOT.jar)
  - com.sun.tools.javap.JavapTask  JDK internal
 API (tools.jar)
  - com.sun.tools.javap.JavapTask$BadArgs  JDK internal
 API (tools.jar)
 
 Warning: JDK internal APIs are unsupported and private to JDK
 implementation that are
 subject to be removed or changed incompatibly and could break your
 application.
 Please modify your code to eliminate dependency on any JDK internal APIs.
 For the most recent update on JDK internal API replacements, please check:
 https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
 
 I think sending these reports to jigsaw-...@openjdk.java.net is a
 worthwhile effort to help them direct resources for bug fixing and new
 public APIs.
 
 Cheers,
 
 Chris

Re: Media API question regarding metadata retrieval

2015-04-02 Thread David DeHaven


  If not is there a specific reason not
  to offer this functionality independently of a player?
 
 There were plans, there were also issues as we don't have a Java based mp4 
 parser so we're relying on the underlying platforms (e.g. QTKit, 
 AVFoundation, etc..) to provide that data, which basically means we're 
 creating a player at the native level anyways. If you're using the horribly 
 outdated FXM format you get the benefit of a Java 
 
 Deferring to native code absolutely makes sense but I didn't think that you 
 needed to create a player to obtain duration, width and height in 
 AVFoundation either.

No, but for the lack of a separate interface for metadata retrieval. In 
hindsight there were a number of things that should have been done differently 
:/

-DrD-

Re: Media API question regarding metadata retrieval

2015-04-02 Thread David DeHaven


   If not is there a specific reason not
   to offer this functionality independently of a player?
 
  There were plans, there were also issues as we don't have a Java based mp4 
  parser so we're relying on the underlying platforms (e.g. QTKit, 
  AVFoundation, etc..) to provide that data, which basically means we're 
  creating a player at the native level anyways. If you're using the horribly 
  outdated FXM format you get the benefit of a Java
 
  Deferring to native code absolutely makes sense but I didn't think that you 
  needed to create a player to obtain duration, width and height in 
  AVFoundation either.
 
 No, but for the lack of a separate interface for metadata retrieval. In 
 hindsight there were a number of things that should have been done 
 differently :/
 
 
 Alright, understood. No offense intended btw.. Thanks for taking the time to 
 explain! 

None taken! :) Happy to help when I can.

-DrD-

Re: Media API question regarding metadata retrieval

2015-04-01 Thread David DeHaven


 I was a bit surprised that the metadata retrieval functionality
 of javafx.scene.media.Media is only usable in conjunction with a player, so
 if I want to retrieve the dimensions of a video file I have to instantiate
 a player and wait for it to reach ready state? That's how I read the
 javadoc. Is this a misunderstanding?

Nope, currently you have to create a player. Once a player is created it kicks 
off a parser to grab metadata or waits for the underlying native player to 
parse.


 If not is there a specific reason not
 to offer this functionality independently of a player?

There were plans, there were also issues as we don't have a Java based mp4 
parser so we're relying on the underlying platforms (e.g. QTKit, AVFoundation, 
etc..) to provide that data, which basically means we're creating a player at 
the native level anyways. If you're using the horribly outdated FXM format you 
get the benefit of a Java based parser, but honestly, who's using that these 
days?

-DrD-

Re: Media player maturity (on Mac)

2015-03-12 Thread David DeHaven


 One more question regarding this. Is it OK to have many instances of 
 AudioClip or MediaPlayer if only a few of them actually play stuff or do they 
 block audio resources even when they are stopped?

You can have as many as memory will allow :) They don’t tie up hardware 
resources until actually playing. I actually recommend pre-loading AudioClips 
to avoid startup latency, especially if they’re fetched remotely.

-DrD-

Re: Media player maturity (on Mac)

2015-03-12 Thread David DeHaven


  One more question regarding this. Is it OK to have many instances of 
  AudioClip or MediaPlayer if only a few of them actually play stuff or do 
  they block audio resources even when they are stopped?
 
 You can have as many as memory will allow :) They don’t tie up hardware 
 resources until actually playing. I actually recommend pre-loading AudioClips 
 to avoid startup latency, especially if they’re fetched remotely.
 
 Thanks for the info! 

Oh, and if you have a lot of AudioClips, it’s best to spawn a new thread to 
load them up asynchronously, otherwise you could block the main application 
thread which will render the UI unresponsive while it’s loading. We’ve seen 
this happen on a couple occasions...

I wanted to provide a library API to handle pre-loading, but didn’t have the 
time or resources :(

-DrD-

Re: MediaPlayer status changes

2015-03-12 Thread David DeHaven


 I don't see anything in the docs stating how status should change in
 MediaPlayer, e.g. will reaching end of media trigger a transition from
 PLAYING to STOPPED? Will a subsequent call to play() start at the beginning
 of the media file or do I need to seek? I was expecting some kind of status
 change on end of media but am not seeing any when playing back an audio
 sample until the end and when I checked the api doc, I didn't find anything
 (e.g. like a state diagram) to check if it's a bug or documented behavior.


The formal documentation is here (read the package Description, link at the 
top):
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/package-summary.html

There’s actually a flow chart in the docs for MediaPlayer.Status:
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/media/MediaPlayer.Status.html

Hope that helps.

-DrD-

Re: Media player maturity (on Mac)

2015-03-11 Thread David DeHaven


 No, thanks for the hint. I just did and the behavior is a bit better in the 
 sense that the sample start is not cut off on subsequent play invocations 
 (behaves more or less line instantiating a new mediaplayer for each 
 invocation, which is good) but when I loop using setCycleCount the sample 
 start is also not clean (seams to be varying, though).
 
 For my uses case I will probably need both MediaPlayer and Audioclip, because 
 I have typical cases for AudioClip (e.g. short notification sounds) and long 
 looping background samples.
 
 Wow, I just discovered, that the behavior with the sample start sounding 
 different on the first invocation also happens when I play the sample using 
 the player integrated in Finder, so I owe you a big apology. I am sorry! I 
 can also no longer reproduce the looping failure after my last reboot :-S.

No worries, these things just aren’t supposed to behave that way ;)


 Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low enough 
 to implement something like a drum kit using the keyboard. I don't know if 
 that is the benchmark you are after or if that is also a limitation of the 
 hosting system. I need to test that with other applications. The latency I 
 get with AudioClip is good enough for my current use case, though.

Yeah, the current AudioClip implementation actually uses the same engine as 
MediaPlayer, just in a slightly different way. The biggest difference (aside 
from the one-shot interface) is it caches all the audio data in memory. If you 
use uncompressed audio (aiff) it will be a bit faster.

-DrD-

Re: Media player maturity (on Mac)

2015-03-10 Thread David DeHaven


 anyone doing serious work with the media player on the Mac? I am
 experimenting and so far I am not getting the impression, this is really
 something very solid.
 
 The first Audio-Sample I tried playing plays fine the first time but when I
 play it for a second time by either issuing stop() followed by play() or
 seek(new Duration(0) and then play, the playback cuts off a few samples at
 the start (does not happen when I instantiate a new Player for each time I
 want to play it, which does not feel right). You need a suitable audio file
 like a drum beat that starts immediately in the file to notice the
 difference.
 
 If one was to implement simple sample-player-like functionality (not a full
 fledged music sequencer but something that allows timed playback to arrange
 sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to
 use or do I have to use native APIs? Last time I checked JavaSound, it was
 still an abandoned toy usable only for educational purposes but not for
 anything else. Don't know if that has changed or if this is even the Audio
 strategy for JFX.
 
 Would be great if someone could share experience/opinions in this area.

Have you tried AudioClip instead of MediaPlayer?

-DrD-

Re: Media player performance on Mac

2015-03-04 Thread David DeHaven


 I just put a MediaView with a MediaPlayer into a FlowPane and displayed it.
 Playing a Full-HD H.264 file consumes between 40 and 60% of CPU. Playing
 the same file in Quicktime consumes about 3-4% CPU. What is the reason for
 the dramatic difference? Is the player subsystem not using hardware
 acceleration for decoding h.264? Is it something else intrinsic to
 MediaPlayer oder MediaView? I thought 8u40's media support was build on top
 of the AVFoundation framework and thus could compete with native players.
 Can I set a flag to force hardware acceleration? Is something being done
 about this? I am a bit worried that an application built on top of this
 would just eat up our users' battery like crazy.

Can you link a sample of a movie that’s causing that much of a performance 
difference? There will always be a slight difference, but it should not be that 
much.

Could also be helpful to know more details about the environment you’re running 
in. Keep in mind the new AVFoundation code is only supported on 10.8 and later 
due to the lack of certain required APIs in 10.7 and 10.6.

-DrD-

[8u40] RFR: RT-39764: [macosx] Media crashes when changing EQ band center frequency

2015-01-05 Thread David DeHaven


Kevin, Kirill, please review my fix for RT-39764.

JIRA:
https://javafx-jira.kenai.com/browse/RT-39764

Webrev:
http://cr.openjdk.java.net/~ddehaven/RT-39764/rt.0/index.html

-DrD-

Re: [8u40] RFR: RT-39764: [macosx] Media crashes when changing EQ band center frequency

2015-01-05 Thread David DeHaven


I think Kirill's still out, Alexander can you review this?

-DrD-

 
 Kevin, Kirill, please review my fix for RT-39764.
 
 JIRA:
 https://javafx-jira.kenai.com/browse/RT-39764
 
 Webrev:
 http://cr.openjdk.java.net/~ddehaven/RT-39764/rt.0/index.html
 
 -DrD-

[8u40] RFR: RT-38973: Media produces extraneous debugging when running Ensemble8

2014-11-24 Thread David DeHaven


Kevin, Kirill, please review the following fix for 8u40:

JIRA:
https://javafx-jira.kenai.com/browse/RT-38973

Webrev: 
http://cr.openjdk.java.net/~ddehaven/RT-38973/rt.0/

I added an additional (annoying) compiler warning fix.

-DrD-

8u40 RFR: RT-39238: [media] Mac native platform code doesn't compile with parfait compilers

2014-10-30 Thread David DeHaven


Kevin, Steve, can you please review my build system changes?

Webrev:
http://cr.openjdk.java.net/~ddehaven/RT-39238/rt.0/

JIRA Issue:
https://javafx-jira.kenai.com/browse/RT-39238

-DrD-

Re: CFV: New OpenJFX Committer: Chris Bensen

2014-10-13 Thread David DeHaven


Vote: yes

-DrD-


 I hereby nominate Chris Bensen to OpenJFX Committer.
 
 Chris is a member of JavaFX team at Oracle working on the Java (FX) packager 
 tool.
 
 A list of Chris' commits is available by the following link:
 
 http://hg.openjdk.java.net/openjfx/8u-dev/rt/log?rev=cbensen
 
 Four of the changesets in this list for which Chris was not listed as the 
 author were contributed by him, giving him a total of 8 changesets.
 
 Additionally, the following is an aggregate changeset of significant work 
 contributed by both Danno and Chris (although the changeset comment doesn't 
 reflect that) :
 
 http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8335da240a33
 
 
 Votes are due by October 24, 2014.
 
 Only current OpenJFX Committers [1] are eligible to vote on this nomination. 
 Votes must be cast in the open by replying to this mailing list.
 
 For Lazy Consensus voting instructions, see [2]. Nomination to a project 
 Committer is described in [3].
 
 [1] http://openjdk.java.net/census#openjfx
 
 [2] http://openjdk.java.net/bylaws#lazy-consensus
 
 [3] http://openjdk.java.net/projects#project-committer
 
 Thanks,
 
 -- Kevin

Re: CFV: New OpenJFX Committer: Morris Meyer

2014-09-25 Thread David DeHaven


Vote: yes

-DrD-

[8u40] Request for review: RT-34893: [Media] Use of QuickTime prevents Mac AppStore Submission

2014-09-17 Thread David DeHaven


JIRA issue:
https://javafx-jira.kenai.com/browse/RT-34893

Webrev:
http://cr.openjdk.java.net/~ddehaven/RT-34893/rt.1/

Overview:
- Added AVFoundation based player class, implemented as a standalone module 
that will load only on 10.8 or later
- Refactored some classes that were hard wired for GStreamer (namely: Audio EQ 
and spectrum)
- Removed a couple unused/unnecessary internal media APIs
- Changed how video data is sent to prism, instead of using a single buffer and 
offsets for planes, now we have a buffer for each plane since it's possible we 
could get frames that have non-contiguous plane buffers. Chunky formats just 
use plane 0.
- Added planar Y'CbCr 4:2:0 rendering support
- Added a convenience Xcode project, not used for building but it helps with 
development significantly
- Added Xcode/OSX droppings to .hgignore, plus a couple other things that 
should be in there
- Performed some needed media code cleanup:
+ modernized some for loops
+ lambda-ified a few places in media that sorely needed it
+ updated copyright dates
+ marked a bunch of fields final that should have been originally
+ added @Override annotations as appropriate to remove annoying yellow 
marks in Netbeans

Jim and Lisa, please check the prism changes. Those will affect all platforms. 
Alexander and Kirill will review the media changes. Kevin, Steve please take a 
look at everything else like the build system.

-DrD-

hg: openjfx/8u-dev/rt: RT-38074: [macosx] Separate QTKit platform code from core media code so it can be removed for MAS

2014-08-05 Thread david . dehaven

Changeset: 24a1b2582b74
Author:ddehaven
Date:  2014-08-05 08:43 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/24a1b2582b74

RT-38074: [macosx] Separate QTKit platform code from core media code so it can 
be removed for MAS

! build.gradle
! modules/media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java
! modules/media/src/main/java/com/sun/media/jfxmediaimpl/platform/Platform.java
! 
modules/media/src/main/java/com/sun/media/jfxmediaimpl/platform/PlatformManager.java
! 
modules/media/src/main/java/com/sun/media/jfxmediaimpl/platform/ios/IOSPlatform.java
! 
modules/media/src/main/java/com/sun/media/jfxmediaimpl/platform/osx/OSXPlatform.java
! modules/media/src/main/native/jfxmedia/Utils/JObjectPeers.h
! modules/media/src/main/native/jfxmedia/Utils/JavaUtils.h
! modules/media/src/main/native/jfxmedia/platform/osx/OSXMediaPlayer.h
! modules/media/src/main/native/jfxmedia/platform/osx/OSXMediaPlayer.mm
! modules/media/src/main/native/jfxmedia/platform/osx/OSXPlatform.mm
! modules/media/src/main/native/jfxmedia/platform/osx/OSXPlayerProtocol.h
! modules/media/src/main/native/jfxmedia/projects/mac/Makefile

Re: [8u40] Review request: RT-38074: [macosx] Separate QTKit platform code from core media code so it can be removed for MAS

2014-08-01 Thread David DeHaven


Ok, thanks.

-DrD-

 The owner of the code area (Kirill) should at least be aware of what you are 
 doing.
 
 As long you have one reviewer in the area you touched (Alexander reviewed), 
 then it is OK, although I want to review non-trivial build changes (which 
 this one isn't, but your subsequent changes will be). Anyway, I just reviewed 
 it.
 
 I will follow-up with an e-mail reminder about the additional rules for next 
 week since we are ramping down for milestone M1.
 
 -- Kevin
 
 
 David DeHaven wrote:
 Ping Kevin, Kirill? (how many reviewers do I need these days?)
 
 -DrD-
 
   
 
 JIRA Issue:
 
 https://javafx-jira.kenai.com/browse/RT-38074
 
 
 Latest webrev:
 
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.2/
 
 
 Removed new makefile (eyesore), cleaned up/enhanced existing Makefile, 
 fixed a compiler warning.
 
 Last iteration hopefully, I let it bake for 12 hours and haven't had the 
 urge to change anything ;)
 
 -DrD-
 
 
 
 Kirill, Alexander, Kevin:
 
 New version up for review, please take a look:
 
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.1/
 
 
 I moved OSXPlatform and OSXMediaPlayer code back to jfxmedia, since it was 
 meant to be an abstraction point for using either QTKit or AVFoundation in 
 the first place.
 
 -DrD-
 
   
 
 Belay that review.. I have some (significant) changes to make, in 
 preparation for the larger task of implementing the AVFoundation based 
 code.
 
 -DrD-
 
 
 
 JIRA:
 
 https://javafx-jira.kenai.com/browse/RT-38074
 
 
 Webrev:
 
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.0/
 
 
 This change moves the QTKit based media platform code into it's own 
 dylib. NativeMediaManager had to be modified to allow detection of the 
 new library to determine if the platform was available or not. There may 
 be a slight performance impact due to loading the native libs sooner, 
 but the bulk of the initialization is still done at a later time.
 
 -DrD-

Re: [8u40] Review request: RT-38074: [macosx] Separate QTKit platform code from core media code so it can be removed for MAS

2014-07-31 Thread David DeHaven


Ping Kevin, Kirill? (how many reviewers do I need these days?)

-DrD-

 
 JIRA Issue:
 https://javafx-jira.kenai.com/browse/RT-38074
 
 Latest webrev:
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.2/
 
 Removed new makefile (eyesore), cleaned up/enhanced existing Makefile, fixed 
 a compiler warning.
 
 Last iteration hopefully, I let it bake for 12 hours and haven't had the urge 
 to change anything ;)
 
 -DrD-
 
 
 Kirill, Alexander, Kevin:
 
 New version up for review, please take a look:
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.1/
 
 I moved OSXPlatform and OSXMediaPlayer code back to jfxmedia, since it was 
 meant to be an abstraction point for using either QTKit or AVFoundation in 
 the first place.
 
 -DrD-
 
 
 Belay that review.. I have some (significant) changes to make, in 
 preparation for the larger task of implementing the AVFoundation based code.
 
 -DrD-
 
 JIRA:
 https://javafx-jira.kenai.com/browse/RT-38074
 
 Webrev:
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.0/
 
 This change moves the QTKit based media platform code into it's own dylib. 
 NativeMediaManager had to be modified to allow detection of the new 
 library to determine if the platform was available or not. There may be a 
 slight performance impact due to loading the native libs sooner, but the 
 bulk of the initialization is still done at a later time.
 
 -DrD-

Re: [8u40] Review request: RT-38074: [macosx] Separate QTKit platform code from core media code so it can be removed for MAS

2014-07-30 Thread David DeHaven


JIRA Issue:
https://javafx-jira.kenai.com/browse/RT-38074

Latest webrev:
http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.2/

Removed new makefile (eyesore), cleaned up/enhanced existing Makefile, fixed a 
compiler warning.

Last iteration hopefully, I let it bake for 12 hours and haven't had the urge 
to change anything ;)

-DrD-

 
 Kirill, Alexander, Kevin:
 
 New version up for review, please take a look:
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.1/
 
 I moved OSXPlatform and OSXMediaPlayer code back to jfxmedia, since it was 
 meant to be an abstraction point for using either QTKit or AVFoundation in 
 the first place.
 
 -DrD-
 
 
 Belay that review.. I have some (significant) changes to make, in 
 preparation for the larger task of implementing the AVFoundation based code.
 
 -DrD-
 
 JIRA:
 https://javafx-jira.kenai.com/browse/RT-38074
 
 Webrev:
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.0/
 
 This change moves the QTKit based media platform code into it's own dylib. 
 NativeMediaManager had to be modified to allow detection of the new library 
 to determine if the platform was available or not. There may be a slight 
 performance impact due to loading the native libs sooner, but the bulk of 
 the initialization is still done at a later time.
 
 -DrD-

[8u40] Review request: RT-38074: [macosx] Separate QTKit platform code from core media code so it can be removed for MAS

2014-07-28 Thread David DeHaven


JIRA:
https://javafx-jira.kenai.com/browse/RT-38074

Webrev:
http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.0/

This change moves the QTKit based media platform code into it's own dylib. 
NativeMediaManager had to be modified to allow detection of the new library to 
determine if the platform was available or not. There may be a slight 
performance impact due to loading the native libs sooner, but the bulk of the 
initialization is still done at a later time.

-DrD-

Re: [8u40] Review request: RT-38074: [macosx] Separate QTKit platform code from core media code so it can be removed for MAS

2014-07-28 Thread David DeHaven


Belay that review.. I have some (significant) changes to make, in preparation 
for the larger task of implementing the AVFoundation based code.

-DrD-

 JIRA:
 https://javafx-jira.kenai.com/browse/RT-38074
 
 Webrev:
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.0/
 
 This change moves the QTKit based media platform code into it's own dylib. 
 NativeMediaManager had to be modified to allow detection of the new library 
 to determine if the platform was available or not. There may be a slight 
 performance impact due to loading the native libs sooner, but the bulk of the 
 initialization is still done at a later time.
 
 -DrD-

Re: [8u40] Review request: RT-38074: [macosx] Separate QTKit platform code from core media code so it can be removed for MAS

2014-07-28 Thread David DeHaven


Kirill, Alexander, Kevin:

New version up for review, please take a look:
http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.1/

I moved OSXPlatform and OSXMediaPlayer code back to jfxmedia, since it was 
meant to be an abstraction point for using either QTKit or AVFoundation in the 
first place.

-DrD-

 
 Belay that review.. I have some (significant) changes to make, in preparation 
 for the larger task of implementing the AVFoundation based code.
 
 -DrD-
 
 JIRA:
 https://javafx-jira.kenai.com/browse/RT-38074
 
 Webrev:
 http://cr.openjdk.java.net/~ddehaven/RT-38074/rt.0/
 
 This change moves the QTKit based media platform code into it's own dylib. 
 NativeMediaManager had to be modified to allow detection of the new library 
 to determine if the platform was available or not. There may be a slight 
 performance impact due to loading the native libs sooner, but the bulk of 
 the initialization is still done at a later time.
 
 -DrD-

Re: [8u40] Review request: RT-37261: Mac: FileChooser.show() crashes in NSSavePanel when running in sandboxed environment

2014-06-27 Thread David DeHaven


 Please review the fix: https://javafx-jira.kenai.com/browse/RT-37261

My only comment so far is it looks like sandboxRequirementRef should be 
CFReleased too, since it's created with SecRequirementCreateWithString.

-DrD-

Re: All-Permissions not working properly with sun.plugin2.applet.FXAppletSecurityManager

2014-06-16 Thread David DeHaven


Run:
jarsigner -verify -verbose -certs /path/to/some.jar

This will show (excessive) signing information as well as the certs used to 
sign.

-DrD-


 I will see if I can get permission to send you the program.
 
 I believe all of my jars are signed with the same certificate. What is the 
 best way to verify that?
 
 
 Thanks Kevin,
 
 Neil
 
 
 
 
 From:   Kevin Rushforth kevin.rushfo...@oracle.com
 To: ngalarn...@abinitio.com, 
 Cc: Scott Palmer swpal...@gmail.com, dmitry cherepanov 
 dmitry.cherepa...@oracle.com, openjfx-dev@openjdk.java.net 
 openjfx-dev@openjdk.java.net
 Date:   06/16/2014 06:12 PM
 Subject:Re: All-Permissions not working properly with 
 sun.plugin2.applet.FXAppletSecurityManager
 
 
 
 Hi Neil,
 
 If you have a test program that you can send me, I can attach it for you.
 
 Question for you: are all of your jar files (including the third-party 
 libs) signed with the same certificate?
 
 -- Kevin
 
 
 ngalarn...@abinitio.com wrote: 
 Also, because I can't login, I can't add a comment to the bug report. 
 
 I am also getting a security exception even though my applet is signed  
 has all permissions. 
 
 In this case it is happening on a call to getClassLoader() on the JavaFX 
 thread (not a daemon thread): 
 
 Exception in thread JavaFX Application Thread 
 java.security.AccessControlException: access denied 
 (java.lang.RuntimePermission getClassLoader) 
at java.security.AccessControlContext.checkPermission(Unknown 
 Source) 
at java.security.AccessController.checkPermission(Unknown Source) 
at java.lang.SecurityManager.checkPermission(Unknown Source) 
at 
 sun.plugin2.applet.FXAppletSecurityManager.checkPermission(Unknown Source) 
 
at java.lang.ClassLoader.checkClassLoaderPermission(Unknown 
 Source) 
at java.lang.Class.getClassLoader(Unknown Source) 
... 
 
 The call to getClassLoader() happens from inside a 3rd party library if 
 that matters. 
 
 When I run the identical code as a desktop application it works fine EVEN 
 WHEN I ADD MY OWN SECURITY MANAGER. 
 
 
 Thank you for any help, 
 
 Neil 
 
 
 
 
 From:Scott Palmer swpal...@gmail.com 
 To:Kevin Rushforth kevin.rushfo...@oracle.com, 
 Cc:openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net 
 Date:06/13/2014 08:19 PM 
 Subject:Re: All-Permissions not working properly with   
 sun.plugin2.applet.FXAppletSecurityManager 
 Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net 
 
 
 
 Thank you.
 
 Is there a way that people that are not project authors can get 
 notifications of updates?  I can’t click to add myself to the watch list 
 or vote without a login, and it seems to be near impossible to get a 
 login.
 The Account Help” link on the login page is broken and everything I’ve 
 found in the wiki indicates I need to be a project author to get an 
 account.
 
 Scott
 
 
 On Jun 13, 2014, at 8:05 PM, Kevin Rushforth kevin.rushfo...@oracle.com 
 wrote:
 
 Hi Scott,
 
 I created two new non-confidential bugs and closed the original ones as 
 duplicates. Here are the new bugs:
 
 
 reflection in daemon thread: 
 JDK-8046825 (was JDK-8040699) : All-Permissions not working properly 
 with sun.plugin2.applet.FXAppletSecurityManager
 
 security manager and applet-desc webstart mode: 
 JDK-8046826 (was JDK-8040231) : All permission fx javaws app could not 
 set Security Manager to null.
 
 I have copied Dmitry in case he has any information about these bugs.
 
 -- Kevin
 
 
 Kevin Rushforth wrote:
 
 Dmitry can comment further, but it is possible that this issue could be 
 backported to 8u40 if done soon enough. 
 
 I will double-check whether the bugs can be made non-confidential (so 
 you can at least track progress), but I suspect they cannot in their 
 current form, in which case new bugs should be filed with the confidential 
 information moved to confidential comments in the bug. I will help with 
 this. 
 
 -- Kevin 
 
 
 Scott Palmer wrote: 
 Drat... I was hoping to see something much sooner, like 8u20 
 (obviously too late now) or 8u40.  I'm unable to use Web Start deployment 
 because of this. 
 
 Is it necessary for these issues to be blocked from anonymous viewing? 
 
 
 Thanks for the update. 
 
 Scott 
 
 
 On Wed, Jun 11, 2014 at 11:57 AM, Kevin Rushforth 
 kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com wrote: 
 
These are now assigned to Dmitry Cherapanov who I have copied here 
 
in case he isn't on the openjfx alias. They are both targeted to 
JDK 9. 
 
-- Kevin 
 
 
Scott Palmer wrote: 
 
I tried to send an email to Thomas asking about the status of 
these issues 
(they are not visible to me), but the email bounced (user 
unknown).  Could 
someone let me know the status? 
 
Thanks, 
 
Scott 
 
 
On Thu, Apr 17, 2014 at 1:25 AM, Thomas Ng 
thomas.v...@oracle.com

Re: All-Permissions not working properly with sun.plugin2.applet.FXAppletSecurityManager

2014-06-16 Thread David DeHaven


Oh, right. Blob signing can't be verified with jarsigner...

-DrD-

 Thank you David. 
 
 Interesting. 
 
 Output from my gradle build (which uses the shemnon javafx-plugin) looks like 
 this: 
 ... 
 :classes 
 :jar 
 :jfxJar 
 :jfxSignJar 
 Signing (BLOB) C:\Users\ngalarneau\.gradle\caches\3rdpartylibrary.jar 
 Signed as C:\directory\to\3rdpartylibrary.jar 
 Signing (BLOB) C:\our\test\app.jar 
 Signed as C:\our\test\app.jar 
 :jfxCopyLibs 
 :compilePackageJava UP-TO-DATE 
 :compilePackageGroovy UP-TO-DATE 
 :processPackageResources UP-TO-DATE 
 :packageClasses UP-TO-DATE 
 :jfxDeploy 
 :assemble 
 :compileTestJava UP-TO-DATE 
 :compileTestGroovy UP-TO-DATE 
 :processTestResources UP-TO-DATE 
 :testClasses UP-TO-DATE 
 :test UP-TO-DATE 
 :check UP-TO-DATE 
 :build 
 
 BUILD SUCCESSFUL 
 
 And, when I run the Applet, it runs just fine. 
 
 But yet, when I run the command line David sent, jarsigner reports: jar is 
 unsigned 
 
 
 I'm confused. 
 
 
 Thanks, 
 
 Neil 
 
 
 
 From:David DeHaven david.deha...@oracle.com 
 To:ngalarn...@abinitio.com, 
 Cc:Kevin Rushforth kevin.rushfo...@oracle.com, 
 openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net 
 Date:06/16/2014 06:18 PM 
 Subject:Re: All-Permissions not working properly with 
 sun.plugin2.applet.FXAppletSecurityManager 
 
 
 
 
 Run:
 jarsigner -verify -verbose -certs /path/to/some.jar
 
 This will show (excessive) signing information as well as the certs used to 
 sign.
 
 -DrD-
 
 
  I will see if I can get permission to send you the program.
  
  I believe all of my jars are signed with the same certificate. What is the 
  best way to verify that?
  
  
  Thanks Kevin,
  
  Neil
  
  
  
  
  From:   Kevin Rushforth kevin.rushfo...@oracle.com
  To: ngalarn...@abinitio.com, 
  Cc: Scott Palmer swpal...@gmail.com, dmitry cherepanov 
  dmitry.cherepa...@oracle.com, openjfx-dev@openjdk.java.net 
  openjfx-dev@openjdk.java.net
  Date:   06/16/2014 06:12 PM
  Subject:Re: All-Permissions not working properly with 
  sun.plugin2.applet.FXAppletSecurityManager
  
  
  
  Hi Neil,
  
  If you have a test program that you can send me, I can attach it for you.
  
  Question for you: are all of your jar files (including the third-party 
  libs) signed with the same certificate?
  
  -- Kevin
  
  
  ngalarn...@abinitio.com wrote: 
  Also, because I can't login, I can't add a comment to the bug report. 
  
  I am also getting a security exception even though my applet is signed  
  has all permissions. 
  
  In this case it is happening on a call to getClassLoader() on the JavaFX 
  thread (not a daemon thread): 
  
  Exception in thread JavaFX Application Thread 
  java.security.AccessControlException: access denied 
  (java.lang.RuntimePermission getClassLoader) 
 at java.security.AccessControlContext.checkPermission(Unknown 
  Source) 
 at java.security.AccessController.checkPermission(Unknown Source) 
 at java.lang.SecurityManager.checkPermission(Unknown Source) 
 at 
  sun.plugin2.applet.FXAppletSecurityManager.checkPermission(Unknown Source) 
  
 at java.lang.ClassLoader.checkClassLoaderPermission(Unknown 
  Source) 
 at java.lang.Class.getClassLoader(Unknown Source) 
 ... 
  
  The call to getClassLoader() happens from inside a 3rd party library if 
  that matters. 
  
  When I run the identical code as a desktop application it works fine EVEN 
  WHEN I ADD MY OWN SECURITY MANAGER. 
  
  
  Thank you for any help, 
  
  Neil 
  
  
  
  
  From:Scott Palmer swpal...@gmail.com 
  To:Kevin Rushforth kevin.rushfo...@oracle.com, 
  Cc:openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net 
  Date:06/13/2014 08:19 PM 
  Subject:Re: All-Permissions not working properly with   
  sun.plugin2.applet.FXAppletSecurityManager 
  Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net 
  
  
  
  Thank you.
  
  Is there a way that people that are not project authors can get 
  notifications of updates?  I can’t click to add myself to the watch list 
  or vote without a login, and it seems to be near impossible to get a 
  login.
  The Account Help” link on the login page is broken and everything I’ve 
  found in the wiki indicates I need to be a project author to get an 
  account.
  
  Scott
  
  
  On Jun 13, 2014, at 8:05 PM, Kevin Rushforth kevin.rushfo...@oracle.com 
  wrote:
  
  Hi Scott,
  
  I created two new non-confidential bugs and closed the original ones as 
  duplicates. Here are the new bugs:
  
  
  reflection in daemon thread: 
  JDK-8046825 (was JDK-8040699) : All-Permissions not working properly 
  with sun.plugin2.applet.FXAppletSecurityManager
  
  security manager and applet-desc webstart mode: 
  JDK-8046826 (was JDK-8040231) : All permission fx javaws app could not 
  set Security Manager to null.
  
  I have copied Dmitry in case he has any information about these bugs

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread David DeHaven


 For a one shot screen capture - we would pass in top left and width and 
 height to make the bottom right.
 Currently this should work on Mac I am told, though what is in the out of 
 bounds pixels is not known.
 And if we added a third tall screen to the left, life gets even more 
 complicated :-(

When pressing Command+Shift+3, the Mac creates separate images for each display.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

2014-03-25 Thread David DeHaven


 Hi All,
 Apparently the JavaFX includes some libraries that use the obsolete 
 Quicktime. When some submits to the Apple Store a JavaFX app it gets rejected 
 based on JavaFX having the obsolete API. I found out how to fix it from 
 someone else running into the same issue.
 
 http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

2014-03-25 Thread David DeHaven

Therein lies The Problem, and why we had to go with QTKit when we supported
10.6... Every two releases they seem to deprecate half-baked APIs in favor of
some new half-baked API. At least as of 10.8 that seems to have stabilized
somewhat, as we transition more and more to an iOS clone.

We had issues with AVFoundation not working the way we needed and it wasn't
available on 10.6. It's supposed to work correctly (never had time to confirm)
on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to
stick with QTKit for older releases and move to AVFoundation in 10.8 and later.
Ideally, the QTKit component would be separate so it could be removed allowing
MAS apps to still support A/V playback. I think the QTKit component can be
dropped completely in FX 9 but it needs to be there in FX 8.

AVKit is a high level component that sits on top of AVFoundation, it doesn't
look useful for our purposes at first glance.

-DrD-

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets 10.8 if its
unable to use QTKit since that's all there is on 10.8 or earlier.

Does the AppStore really disallow targeting something like half the
installed base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:
Here is the JIRA that is tracking this:
https://javafx-jira.kenai.com/browse/RT-34893

Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:
Thanks for the verification. No matter what state Quicktime is in it is no
longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I could be
wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven
david.deha...@oracle.com wrote:

Hi All,
Apparently the JavaFX includes some libraries that use the obsolete
Quicktime. When some submits to the Apple Store a JavaFX app it gets
rejected based on JavaFX having the obsolete API. I found out how to fix
it from someone else running into the same issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

2014-03-25 Thread David DeHaven

Yes, this is true, but QuickTime (despite it's horrible component architecture)
was stable and actually useful for a very long time, then they dropped it and
replaced it with what amounts to absolutely nothing useful. Only in 10.8 did
they start putting useful bits back in, it's still a long ways to go to catch
up to the utility of QuickTime.

-DrD-

Apple has a long history of burning developers like this. It's the price of
running on their platform.

Steve

On 2014-03-25 3:30 PM, Phil Race wrote:
I see .. so AVFoundation was already there since 10.7, its AVKit that's new
in 10.9
but AV Foundation is what FX would use.
It looks like Apple starting encouraging migration to AV Foundation about 18
months ago
based on the date of this document :-
https://developer.apple.com/library/mac/technotes/tn2300/_index.html
I suppose we need to learn read the apple seeds and interpret that as a big,
urgent, hint.

-phil.

On 3/25/2014 12:09 PM, David DeHaven wrote:
Therein lies The Problem, and why we had to go with QTKit when we supported
10.6... Every two releases they seem to deprecate half-baked APIs in favor
of some new half-baked API. At least as of 10.8 that seems to have
stabilized somewhat, as we transition more and more to an iOS clone.

We had issues with AVFoundation not working the way we needed and it wasn't
available on 10.6. It's supposed to work correctly (never had time to
confirm) on 10.8 but that still leaves 10.7 out in the cold. So we'll
likely have to stick with QTKit for older releases and move to AVFoundation
in 10.8 and later. Ideally, the QTKit component would be separate so it
could be removed allowing MAS apps to still support A/V playback. I think
the QTKit component can be dropped completely in FX 9 but it needs to be
there in FX 8.

AVKit is a high level component that sits on top of AVFoundation, it
doesn't look useful for our purposes at first glance.

-DrD-

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets 10.8 if
its
unable to use QTKit since that's all there is on 10.8 or earlier.

Does the AppStore really disallow targeting something like half the
installed base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:
Here is the JIRA that is tracking this:
https://javafx-jira.kenai.com/browse/RT-34893

Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:
Thanks for the verification. No matter what state Quicktime is in it is
no longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I could
be wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven
david.deha...@oracle.com wrote:

Hi All,
Apparently the JavaFX includes some libraries that use the obsolete
Quicktime. When some submits to the Apple Store a JavaFX app it gets
rejected based on JavaFX having the obsolete API. I found out how to
fix it from someone else running into the same issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Adding GStreamer plugins

2014-03-25 Thread David DeHaven


 I mainly wanted to do this as a personal exercise, though I'd imagine this
 is a useful piece of functionality for many others also - so should I
 submit a patch of the changes, or is this unlikely to be accepted? (Again,
 sorry for the perhaps obvious question, I'm rather new to this.) I've had a
 look at the code review process and it seems to suggest adding a patch to
 the relevant JIRA issue for those who don't have commit access (in this
 case 18009), but I don't seem to have permission to do that either?
 
 It sounds like there are perhaps two different ways to move forward here, the 
 first is to take a submission in the form of WIKI writeup that we can post so 
 that anybody else who wants to try extending the media files can follow the 
 path you took. The other is to take a patch for the given JIRA issue. Sadly, 
 the JIRA server doesn’t allow just anybody to supply patches, so you will 
 have to email to Steve or Kevin and they can attach it to the issue for you.

Be careful how these are implemented. We cannot just enable formats in 
GStreamer, there are licensing and legal issues involved. I think the Matroska 
licenses are fairly benign, but it still requires some amount of process.

What I would recommend is adding a switch to optionally enable additional 
formats, so those building GStreamer or OpenJFX themselves can turn whatever 
they want on or off, and they are on their own for dealing with legal issues.

That being said, we actually tested with MKV during development and it was 
pretty solid :)

-DrD-

Re: Launching JavaFX apps

2014-02-12 Thread David DeHaven


Use of JavaFX-Class-Path is supported but highly discouraged as it leads to 
ClassLoader juggling, it was required when there was no SE launcher support for 
JavaFX. It is only supported for backward compatibility, new applications 
should NOT use it.

Either JavaFX-Application-Class or Main-Class can be used to specify the main 
entry point for the application. If both are present, then 
JavaFX-Application-Class will be used. Whichever is used, the presence of main 
is not required if it's a JavaFX application as the entire launch process is 
handed over to the JavaFX launcher impl. As with JavaFX-Class-Path, use of 
JavaFX-Application-Class is now discouraged but not quite as strongly.

The SE launcher ignores JavaFX-Version. I don't think it's used any more in 
JavaFX either, the only mention of it is // If we ever need to check 
JavaFX-Version, do that here... in LauncherImpl.java.


History:
JDK-8001533 allowed Main-Class to specify a JavaFX application as the main 
class, but it ignored JavaFX-Application-Class (among others)
JDK-8004547 fixed the above issue, the SE launcher now checks for J-A-C in the 
manifest and uses it as the Main-Class if present

-DrD-

On Feb 12, 2014, at 2:07 PM, Florian Brunner fbrunnerl...@gmx.ch wrote:

 Could someone elaborate on this?
 
 Thanks!
 
 -Florian
 
 Am Samstag, 18. Januar 2014, 13.27:07 schrieb Florian Brunner:
 Hi Kevin,
 
 Thanks for this clarifiacation! I'm also interested in this kind of 
 information as I'm in the process of upgrading Drombler FX to JavaFX 8 and 
 Drombler FX comes with a custom Maven Plugin, which makes sure the 
 application can start.
 
 Another related question:
 
 While the Ant task for JavaFX 2.x added the following Manifest entries:
 
 JavaFX-Version: 2.2
 JavaFX-Application-Class: myPackage.MyApplication
 JavaFX-Class-Path: 
 Main-Class: com/javafx/main/Main
 
 
 the Ant task for JavaFX 8 added the following Manifest entries:
 JavaFX-Version: 2.2
 Class-Path: 
 Main-Class: myPackage.MyApplication
 
 So it seems JavaFX-Application-Class is not used anymore if one doesn't 
 use com.javafx.main.Main to start the JavaFX application, and 
 JavaFX-Class-Path has been replaced with the standard Class-Path entry.
 
 The JavaFX-Version seems still to be needed, however. For what is it used? 
 An why is this version set to 2.2 for JavaFX 8 applications? Shouldn't it 
 be 8.0 or something?
 Can I get this version from somewhere? Either the JavaFX API or from the 
 ant-javafx.jar?
 
 -Florian
 
 Am Mittwoch, 8. Januar 2014, 06.45:36 schrieb Kevin Rushforth:
 Hi Scott,
 
 The Java 8 launcher has been modified to recognize JavaFX applications 
 -- that is, classes that extend javafx.application.Application -- and 
 launch them directly by calling into the JavaFX launcher code. See 
 JDK-8001533 https://bugs.openjdk.java.net/browse/JDK-8001533. This is 
 why the com.javafx.main.Main class is no longer needed.
 
 Somewhat independent of this, for standalone applications (but not 
 applets or web start applications) the JavaFX launcher code will now 
 call the main() method if it is present (see RT-28755 
 https://javafx-jira.kenai.com/browse/RT-28755), but will still happily 
 launch the application if it isn't. So the main() method is still 
 optional. If present, it must call Application.launch() in order to 
 launch the application.
 
 So yes, it does seem that Netbeans should modify the wording of their 
 javadoc comment for the main() method of a JavaFX application.
 
 -- Kevin
 
 
 Scott Palmer wrote:
 Based on the discussion I saw in the comments for RT-34236 I discovered
 that using com.javafx.main.Main is not the way JavaFX 8 is supposed to
 work. There are comments that read, ...making sure their Application class
 has a main that calls launcher(String[] args).
 
 This seems to imply that a main method is now required in the Application
 class when writing apps for JavaFX 8.
 
 Is this correct?
 
 If so. Somebody should tell NetBeans to stop injecting this comment in the
 generated application class for JavaFX projects:
 /**
 * The main() method is ignored in correctly deployed JavaFX application.
 * main() serves only as fallback in case the application can not be
 * launched through deployment artifacts, e.g., in IDEs with limited FX
 * support. NetBeans ignores main().
 *
 * @param args the command line arguments
 */
 
 Are the changes to the launching of JavaFX apps docuemtned somewhere?  Is
 using javafxpackager or the ant task the *only* supported way of creating
 JavaFX applications?  I'm currently using my own stub that runs on Java 7
 and adds the jfxrt.jar to the classpath if required and then calls the
 launch method on the Applicaiton class.
 
 Regards,
 
 Scott

Re: javafxpackager and launcher

2014-01-10 Thread David DeHaven


 An application bundle mode could probably be
 triggered via the contents of a resource that is injected much like the
 custom icon is injected into the fx launcher (I'm not sure if something
 needs to be done for preloader support too.  I think the embedded launcher
 stub handles that on Java 7, but I believe it isn't used on JavaFX 8.
 
 
 One of the advantages of our own launcher (as you point out later in your
 mail) is we can customize the launcher.  Put a custom icon on, and
 (potentially) load up custom meta-data to the executable, and maybe even
 sign it (we don't sign it today).  Tweaking the existing Java.exe in this
 manner on windows could be problematic.

I'd like to add the point that java (.exe) is simply a wrapper for libjli 
(jli.dll). In 7/8 the custom launcher uses this same interface to launch the 
application, so it  technically already uses the same code to launch. The other 
features of the custom launcher *cannot* be replicated by the SE launcher 
without massive changes to JLI and the SE launcher code.

Having said that... it's not entirely unreasonable to think that some useful 
parts of the launcher could be contributed to JLI. But that brings a host of 
other issues to the table, namely dealing with getting changes into OpenJDK and 
convincing the guys on the JDK tl team that such changes are necessary. By 
keeping the launcher code in fx packager, we keep the noise to a minimum which 
allows us to be able to be more flexible and responsive to developer demands. 
Once the product is mature enough, maybe we can revisit this.

-DrD-

Re: Review request for RT-34236 FXMLLoader throws java.lang.InternalError: CallerSensitive annotation expected at frame 1

2013-11-18 Thread David DeHaven


Looks fine to me.

-DrD-

 Thanks Mark. Can you please add this information to the JIRA (including the 
 link to the new webrev) ?
 
 -- Kevin
 
 
 Mark Howe wrote:
 This is a slightly dialed back version. Basically the same thing as the 
 first webrev except left the API for setEmbeddedLauncher, because that is 
 used by some app.s
 
 
 Kevin and David please review
 http://cr.openjdk.java.net/~kcr/RT-34236.1/
 
 
 On Nov 14, 2013, at 7:08 PM, Mark Howe mark.h...@oracle.com wrote:
 
 Jira: https://javafx-jira.kenai.com/browse/RT-34236
 Webrev: http://cr.openjdk.java.net/~kcr/RT-34236/
 
 Thanks
 Mark

Re: CFV: New OpenJFX Committer: Joseph Andresen

2013-09-25 Thread David DeHaven


Vote: Yes!

-DrD-

 
 I hereby nominate Joe Andresen to OpenJFX Committer.
 
 Joe is a member of JavaFX Graphics team at Oracle. His first changeset in 
 Prism is dated by 2009, and total number of commits is close to one hundred. 
 Full list of Joe's changesets in the open workspace is available from command 
 line:
 
hg log -u Joseph Andresen
 
 Only current OpenJFX Committers [1] are eligible to vote on this nomination. 
 Votes must be cast in the open by replying to this mailing list.
 
 For Lazy Consensus voting instructions, see [2]. Nomination to a project 
 Committer is described in [3].
 
 [1] http://openjdk.java.net/census#openjfx
 
 [2] http://openjdk.java.net/bylaws#lazy-consensus
 
 [3] http://openjdk.java.net/projects#project-committer
 
 Thanks,
 
 Artem

Re: CFV: New OpenJFX Committer: Yao Wang

2013-09-25 Thread David DeHaven


Vote: Yes

-DrD-

 I hereby nominate Yao Wang to OpenJFX Committer.
 
 Yao is a member of JavaFX Graphics team at Oracle. Most of recent Yao's 
 changes are in 3D support code, but not only there:
 
 hg log -u Yao Wang
 
 Incomplete list of Yao's commits and reviews is also available by the 
 following link:
 
 http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=wang
 
 Votes are due by Oct 09, 2013.
 
 Only current OpenJFX Committers [1] are eligible to vote on this nomination. 
 Votes must be cast in the open by replying to this mailing list.
 
 For Lazy Consensus voting instructions, see [2]. Nomination to a project 
 Committer is described in [3].
 
 [1] http://openjdk.java.net/census#openjfx
 
 [2] http://openjdk.java.net/bylaws#lazy-consensus
 
 [3] http://openjdk.java.net/projects#project-committer
 
 Thanks,
 
 Artem

Re: hello and macosx build trouble

2013-08-12 Thread David DeHaven


 Thank you. This worked, and it got further, but it is missing the netscape 
 javascript package now, as illustrated by the below:
 
 :checkJfxrtJar
 :updateCacheIfNeeded UP-TO-DATE
 :verifyJava
 :base:processVersionInfo UP-TO-DATE
 :base:compileJava UP-TO-DATE
 :base:processResources UP-TO-DATE
 :base:classes UP-TO-DATE
 :base:jar UP-TO-DATE
 :graphics:compileJava
 Download 
 http://download.eclipse.org/eclipse/updates/3.7/R-3.7.2-201202080800/plugins/org.eclipse.swt.cocoa.macosx.x86_64_3.7.2.v3740f.jar
 [ant:javac] 
 /Users/rvjansen/apps/rt/modules/graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java:34:
  error: package netscape.javascript does not exist
 [ant:javac] import netscape.javascript.JSObject;
 [ant:javac]   ^
 [ant:javac] 
 /Users/rvjansen/apps/rt/modules/graphics/src/main/java/com/sun/javafx/application/HostServicesDelegate.java:88:
  error: cannot find symbol
 [ant:javac] public abstract JSObject getWebContext();
 [ant:javac] ^
 [ant:javac]   symbol:   class JSObject
 [ant:javac]   location: class HostServicesDelegate
 [ant:javac] 
 /Users/rvjansen/apps/rt/modules/graphics/src/main/java/javafx/application/HostServices.java:30:
  error: package netscape.javascript does not exist
 [ant:javac] import netscape.javascript.JSObject;
 etc.
 
 This might have to do with Nashorn replacing Rhino?

No, I believe that's also a deployment dependency.

Does a JIRA task exist to disable deployment dependencies for OpenJFX/OpenJDK 
builds?

-DrD-

Re: JavaFX Media issues

2013-08-09 Thread David DeHaven

 So called arbitrary input stream support is among the features for the 
 future.
 
 Could somebody post back a reference to the jira, I've seen the feature 
 referred to from other jiras, but I've never been able to find the actual 
 jira reference for this.  Thanks!

Here's an umbrella issue that would cover this:
https://javafx-jira.kenai.com/browse/RT-14938

Unfortunately the media team is rather starved for resources these days (even 
more so than in the past).

-DrD-

74 matches

Mail list logo