[9] review request: 8139326: [TEST] Unit tests for JFXPanel with security manager don't detect errors

[Kevin Rushforth]

Chien,

Please review the following test fix:

https://bugs.openjdk.java.net/browse/JDK-8139326
http://cr.openjdk.java.net/~kcr/8139326/webrev.00/

-- Kevin

Re: Linux X11 based setup: touch gesture related problem

[David Hill]

On 10/9/15, 3:55 AM, Prasant J wrote:

Hi,


Hi Prasant,
   Not a known issue. I suspect that the gesture recognition is not getting 
reset properly, expecting that both fingers should be lifted.
Probably not terribly hard to fix, but would have to add it to the queue.

You should file a bug.

Dave



I'm using Intel atom based hardware (which runs custom linux and has intel
HD graphics) to test JavaFX based application. I have built javaFX with
monocle X11 support. I have correct graphics library setup and the verbose
log confirms that es2 pipeline (X11 platform) is being used.


My trouble is with touch gesture. Generally speaking gestures are working
but not completely as expected. I'm not using X11 touch, but the touch
events are being taken from linux drivers directly. I have an eGalax touch
controller.


One specific touch gesture trouble is (can be reproduced by the following
steps):
1) Two finger pinch and zoom (works)
2) Lift only one finger from touch screen
3) Put the finger back on the touch screen
4) Pinch and zoom again (does not work) until both fingers are lifted


Does it sound like a known issue in JavaFX (es2 X11 pipeline)?


Some more information about my setup:
- monocle.input.touchRadius is set to 1 (my application needs that
resolution)
- I'm not setting any monocle touch filters
- The same application and touch controller work fine when used on Windows
system.


This is a very critical problem for us and we may not consider this
platform if this problem is not solved. So all input is welcome. Any inputs
will be of help.


Thanks in advance.


Regards, Pj



--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

In(Sanity) Testing Mondays

[Vadim Pakhnushev]

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PDT until 1pm 
PDT.


Happy testing!

Thanks,
Vadim

Re: Mac App Store Refusal because of QTKit API's

[Dr. Michael Paus]

Am 09.10.15 um 13:43 schrieb Scott Selvia:


So my question now, Is there a JavaFX application in the Mac OSx Store?

There still is the Ensemble 8 app in the OSX store. But it is already more
than a year old.


com.apple.security.temporary-exception.files.absolute-path.read-write

—>

Thanks,

Scott


On Oct 9, 2015, at 6:32 AM, Scott Selvia  wrote:

Same results…Apple just does not like API’s used within the JRE

October 8, 2015 at 9:10 PM
 From Apple
2.5 - Apps that use non-public APIs will be rejected
2.31 - Apps that are not sandboxed appropriately may be rejected
2.5

The use of non-public APIs can lead to a poor user experience should these APIs 
change in the future, and is therefore not permitted. The following non-public 
APIs are included in your application:

com.apple.security.temporary-exception.files.absolute-path.read-write: True

If you have defined methods in your source code with the same names as the 
above-mentioned APIs, we suggest altering your method names so that they no 
longer collide with Apple's private APIs to avoid your application being 
flagged in future submissions.

Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do 
not have access to the library's source, you may be able to search the compiled binary using "strings" or 
"otool" command line tools. The "strings" tool can output a list of the methods that the library 
calls and "otool -ov" will output the Objective-C class structures and their defined methods. These 
techniques can help you narrow down where the problematic code resides.

2.31

Your app incorrectly implements sandboxing, or it contains one or more 
entitlements with invalid values. Please review the included entitlements and 
sandboxing documentation and resolve this issues before resubmitting a new 
binary.

ubrk_getRuleStatus
ubrk_setUText
ucnv_getCanonicalName
ucnv_reset
ucol_strcollIter

For information on common app sandboxing issues, please see Technical Q&A QA1773 
Common app sandboxing issues 
.

See App Sandboxing  for 
links to essential video and documentation to learn how to sandbox your application.

As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed 
will be rejected. Updates to non-sandboxed apps may be submitted if they only 
addresses bug fixes and new OS X feature adoption provided that your app was on 
the Mac App Store prior to June 1st.

Should you need code-level assistance implementing sandboxing, contact Apple 
Developer Technical Support 
.

If you are unable to reproduce this issue, ensure you are testing the exact version of 
the app that you submitted for review, and that you're doing so in a minimally privileged 
environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App 
Store submissions .

For information on how to symbolicate and read a crash log, please see Technical Note 
TN2123 - CrashReporter 
.

Here is my entitlements, so it must be somewhere, I just don’t know where:


http://www.apple.com/DTDs/PropertyList-1.0.dtd 
">


com.apple.security.app-sandbox
 
com.apple.security.files.user-selected.read-write
 





On Oct 2, 2015, at 2:36 PM, Scott Selvia mailto:ssel...@gmail.com>> wrote:

Chris,

The app is in "waiting for review" state again.  Last time it sat there for 
about 5 days then was rejected. Based on the app getting past the deprecated APIs issue I 
hope I will hear something soon. The bugs, I plan on updating them with a status note ??? 
This weekend.

I thinking Apple has some integration issues between OS X apps and iOS apps. My 
current bundle has a note the it does not include beta testing entitlement. 
From our understanding of the apple docs, that is for iOS apps only. We do not 
have that option enabled in iTunes connect

Scott

Sent from my iPhone


On Oct 2, 2015, at 1:53 PM, Chris Bensen mailto:chris.ben...@oracle.com>> wrote:

Hi Scott,

Let me know what happens with this because we are tracking it with two bugs on 
our end — one in the packager and one in WebKit. I’ve spoken with a couple 
friends at Apple and they don’t think it’s right either but none of them have 
control over the AppStore. At this point there’s really nothing we can do. With 
regards tot he CFBundleIndentifier collision, that’s another problem on their 
end as far as I can tell.

Thanks,
Chris



On Sep 30, 2015, at 3:41 PM, Scott Selvia mailto:ssel...@gmail.com>> wrote:

See you at JavaOne, hopefully I’ll have good results to pass along.

Again thanks to ALL, there are two Apple 

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

I also found that the temporary-exception in Apples response was in my Inherit 
entitlements file however, it was commented out.  This was added after the 
first submission did not upload by using the App Loader application because it 
complained about missing entitlements.  After doing some research on the ITunes 
Connect site it said that OSx apps also needed the temporary exception.  Once 
that was set in the Inherit entitlement our application was able to be 
uploaded, which then resulted in a rejected because of the deprecated API’s 
used within the JRE.  At this point I’m updating my bug on the apple bug report 
system and going to use one of my code tech support requests to get some 
answers that will get me past this point.  To summarize I updated the JDK/JRE 
Bundle ID to prevent a collision and I removed the JavaFX WebKit dylib that the 
Apple review team complained about last time.

I’ve attached the AppLoaderAPIAnalysisFile just in case someone at Oracle can 
see something that Apple is complaining about.

So my question now, Is there a JavaFX application in the Mac OSx Store?

com.apple.security.temporary-exception.files.absolute-path.read-write

—>

Thanks,

Scott

> On Oct 9, 2015, at 6:32 AM, Scott Selvia  wrote:
> 
> Same results…Apple just does not like API’s used within the JRE
> 
> October 8, 2015 at 9:10 PM
> From Apple
> 2.5 - Apps that use non-public APIs will be rejected
> 2.31 - Apps that are not sandboxed appropriately may be rejected
> 2.5
> 
> The use of non-public APIs can lead to a poor user experience should these 
> APIs change in the future, and is therefore not permitted. The following 
> non-public APIs are included in your application:
> 
> com.apple.security.temporary-exception.files.absolute-path.read-write: True
> 
> If you have defined methods in your source code with the same names as the 
> above-mentioned APIs, we suggest altering your method names so that they no 
> longer collide with Apple's private APIs to avoid your application being 
> flagged in future submissions.
> 
> Additionally, one or more of the above-mentioned APIs may reside in a library 
> included with your application. If you do not have access to the library's 
> source, you may be able to search the compiled binary using "strings" or 
> "otool" command line tools. The "strings" tool can output a list of the 
> methods that the library calls and "otool -ov" will output the Objective-C 
> class structures and their defined methods. These techniques can help you 
> narrow down where the problematic code resides.
> 
> 2.31
> 
> Your app incorrectly implements sandboxing, or it contains one or more 
> entitlements with invalid values. Please review the included entitlements and 
> sandboxing documentation and resolve this issues before resubmitting a new 
> binary.
> 
> ubrk_getRuleStatus
> ubrk_setUText
> ucnv_getCanonicalName
> ucnv_reset
> ucol_strcollIter
> 
> For information on common app sandboxing issues, please see Technical Q&A 
> QA1773 Common app sandboxing issues 
> .
> 
> See App Sandboxing  
> for links to essential video and documentation to learn how to sandbox your 
> application.
> 
> As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed 
> will be rejected. Updates to non-sandboxed apps may be submitted if they only 
> addresses bug fixes and new OS X feature adoption provided that your app was 
> on the Mac App Store prior to June 1st.
> 
> Should you need code-level assistance implementing sandboxing, contact Apple 
> Developer Technical Support 
> .
> 
> If you are unable to reproduce this issue, ensure you are testing the exact 
> version of the app that you submitted for review, and that you're doing so in 
> a minimally privileged environment. See Technical Q&A QA1778: How to 
> reproduce bugs reported against Mac App Store submissions 
> .
> 
> For information on how to symbolicate and read a crash log, please see 
> Technical Note TN2123 - CrashReporter 
> .
> 
> Here is my entitlements, so it must be somewhere, I just don’t know where:
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
> ">
> 
> 
>   com.apple.security.app-sandbox
> 
>   com.apple.security.files.user-selected.read-write
> 
> 
> 
> 
> 
>> On Oct 2, 2015, at 2:36 PM, Scott Selvia > > wrote:
>> 
>> Chris, 
>> 
>> The app is in "waiting for review" state again.  Last time it sat there for 
>> about 5 days then was rejected. Based on the app getting past the deprecated 
>> APIs issue I hope I will hear something soon. The bugs, I plan on

Re: Mac App Store Refusal because of QTKit API's

[Scott Selvia]

Same results…Apple just does not like API’s used within the JRE

October 8, 2015 at 9:10 PM
From Apple
2.5 - Apps that use non-public APIs will be rejected
2.31 - Apps that are not sandboxed appropriately may be rejected
2.5

The use of non-public APIs can lead to a poor user experience should these APIs 
change in the future, and is therefore not permitted. The following non-public 
APIs are included in your application:

com.apple.security.temporary-exception.files.absolute-path.read-write: True

If you have defined methods in your source code with the same names as the 
above-mentioned APIs, we suggest altering your method names so that they no 
longer collide with Apple's private APIs to avoid your application being 
flagged in future submissions.

Additionally, one or more of the above-mentioned APIs may reside in a library 
included with your application. If you do not have access to the library's 
source, you may be able to search the compiled binary using "strings" or 
"otool" command line tools. The "strings" tool can output a list of the methods 
that the library calls and "otool -ov" will output the Objective-C class 
structures and their defined methods. These techniques can help you narrow down 
where the problematic code resides.

2.31

Your app incorrectly implements sandboxing, or it contains one or more 
entitlements with invalid values. Please review the included entitlements and 
sandboxing documentation and resolve this issues before resubmitting a new 
binary.

ubrk_getRuleStatus
ubrk_setUText
ucnv_getCanonicalName
ucnv_reset
ucol_strcollIter

For information on common app sandboxing issues, please see Technical Q&A 
QA1773 Common app sandboxing issues 
.

See App Sandboxing  for 
links to essential video and documentation to learn how to sandbox your 
application.

As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed 
will be rejected. Updates to non-sandboxed apps may be submitted if they only 
addresses bug fixes and new OS X feature adoption provided that your app was on 
the Mac App Store prior to June 1st.

Should you need code-level assistance implementing sandboxing, contact Apple 
Developer Technical Support 
.

If you are unable to reproduce this issue, ensure you are testing the exact 
version of the app that you submitted for review, and that you're doing so in a 
minimally privileged environment. See Technical Q&A QA1778: How to reproduce 
bugs reported against Mac App Store submissions 
.

For information on how to symbolicate and read a crash log, please see 
Technical Note TN2123 - CrashReporter 
.

Here is my entitlements, so it must be somewhere, I just don’t know where:


http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


com.apple.security.app-sandbox

com.apple.security.files.user-selected.read-write





> On Oct 2, 2015, at 2:36 PM, Scott Selvia  wrote:
> 
> Chris, 
> 
> The app is in "waiting for review" state again.  Last time it sat there for 
> about 5 days then was rejected. Based on the app getting past the deprecated 
> APIs issue I hope I will hear something soon. The bugs, I plan on updating 
> them with a status note ??? This weekend. 
> 
> I thinking Apple has some integration issues between OS X apps and iOS apps. 
> My current bundle has a note the it does not include beta testing 
> entitlement. From our understanding of the apple docs, that is for iOS apps 
> only. We do not have that option enabled in iTunes connect
> 
> Scott
> 
> Sent from my iPhone
> 
>> On Oct 2, 2015, at 1:53 PM, Chris Bensen  wrote:
>> 
>> Hi Scott,
>> 
>> Let me know what happens with this because we are tracking it with two bugs 
>> on our end — one in the packager and one in WebKit. I’ve spoken with a 
>> couple friends at Apple and they don’t think it’s right either but none of 
>> them have control over the AppStore. At this point there’s really nothing we 
>> can do. With regards tot he CFBundleIndentifier collision, that’s another 
>> problem on their end as far as I can tell.
>> 
>> Thanks,
>> Chris
>> 
>> 
>>> On Sep 30, 2015, at 3:41 PM, Scott Selvia  wrote:
>>> 
>>> See you at JavaOne, hopefully I’ll have good results to pass along.
>>> 
>>> Again thanks to ALL, there are two Apple bug reports:  22751708 - 
>>> CFBundleIdentifier Collision for JavaFX Application because of the embedded 
>>> JRE Info.plist and 22923832 - Rejection of App based on Deprecated API’s 
>>> used by JavaFX webkit and component and API’s not reference by App.
>>> 
>>> I’ll update the thread once I here back from ITunes Connect on the App 
>>> submit or when Apple gets back to me on the b

Linux X11 based setup: touch gesture related problem

[Prasant J]

Hi,


I'm using Intel atom based hardware (which runs custom linux and has intel
HD graphics) to test JavaFX based application. I have built javaFX with
monocle X11 support. I have correct graphics library setup and the verbose
log confirms that es2 pipeline (X11 platform) is being used.


My trouble is with touch gesture. Generally speaking gestures are working
but not completely as expected. I'm not using X11 touch, but the touch
events are being taken from linux drivers directly. I have an eGalax touch
controller.


One specific touch gesture trouble is (can be reproduced by the following
steps):
1) Two finger pinch and zoom (works)
2) Lift only one finger from touch screen
3) Put the finger back on the touch screen
4) Pinch and zoom again (does not work) until both fingers are lifted


Does it sound like a known issue in JavaFX (es2 X11 pipeline)?


Some more information about my setup:
- monocle.input.touchRadius is set to 1 (my application needs that
resolution)
- I'm not setting any monocle touch filters
- The same application and touch controller work fine when used on Windows
system.


This is a very critical problem for us and we may not consider this
platform if this problem is not solved. So all input is welcome. Any inputs
will be of help.


Thanks in advance.


Regards, Pj