It may still be worth you following up as they at least ought to
answer why they identified these as QTKit symbols when they
demonstrably are not ..
-phil.
On 09/30/2015 12:05 PM, Scott Selvia wrote:
Phil,
Yes I've done that and I've re-submitted the app again
I agree that I should not be penalized by the JRE one would hope that Oracle
and Apple worked out the JRE do's and don't when it was decided that Java
applications can be posted to the OS X App Store. However I don't think it
will do much good for me to open Apple bugs. Oracles stick is much bigger than
mine!!!
Scott
Sent from my iPhone
On Sep 30, 2015, at 2:54 PM, Phil Race <philip.r...@oracle.com> wrote:
It looks like there may be something to this :-
On mac fx in 8u60 is linking webkit against the system icu library to find
these symbols.
$ nm -a libjfxwebkit.dylib | grep ubrk_getRuleStatus
U _ubrk_getRuleStatus
$ otool -L libjfxwebkit.dylib | grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version
51.1.0)
webkit has as "undefined" a much longer list than what Apple complained about
so it is not clear if they regard the entire library as off-limits or just some
subset.
So I don't think this is anything to do with QtKit but is a webkit problem.
Removing that dylib is the apparent workaround, assuming you don't need it.
If the packager can't handle that for you I suppose you need to manually
get rid of it out of your JDK directory before packaging.
-phil.
On 09/30/2015 10:44 AM, Scott Selvia wrote:
Will do
It seems Apple is not distinguishing the difference of who is using the APIs.
Just like the jfx media qt dylib filtered out of the Java packager process when
building a Mac store app. I guess at this point they feel the WebKit dylib
falls into the category.
I had an apple issue with the embedded info.plist bundle ID that is part of the
jre packaged with the Mac application package generated with the packager. I
had to hack the jdk update 60 info.plist file and change the bundle ID with a
hashcode suffix. This I opened an apple bug for stating that embedded
frameworks should not trigger a bundle collision ID error when uploading an
application. I have not had any additional responses
I guess I'll add another bug for embedded frameworks (in this case the JRE)
using deprecated APIs
Scott
Sent from my iPhone
On Sep 30, 2015, at 12:45 PM, Donald Smith <donald.sm...@oracle.com> wrote:
Please let us know what you hear back with Apple on this given the information
below we hope they will see this as an oversight.
- Don
On 30/09/2015 12:28 PM, Phil Race wrote:
Yes, these look like ICU functions which so far as I know FX only
references from its *own* internal copy of webkit which in turn has a copy of
ICU.
What is very odd is that Apple is essentially then objecting to referencing
functions that are internal to your app. ie referenced by your app and also
fulfilled by your app, whereas I assume the app store checking should be
against deprecated Apple APIs that you reference in your app and that
are fulfilled by OSX (or iOS).
So something seems wrong here.
-phil.
On 09/30/2015 09:19 AM, Scott Selvia wrote:
Chris,
I'll update iTunes connect with that information and ask them to clarify
Thank you for the additional information, Danno explained they are used in the
WebKit dylib
Scott
Sent from my iPhone
On Sep 30, 2015, at 12:08 PM, Chris Bensen <chris.ben...@oracle.com> wrote:
Hi Scott,
Those APIs are for the text system ICU. I believe the App Store team may be in
error. Perhaps they accidentally copied the wrong forbidden APIs when writing
the message.
Thanks,
Chris
On Sep 29, 2015, at 3:15 AM, Scott Selvia <ssel...@gmail.com> wrote:
I’m using JDK 8 update 60 and I just received an email from Apple saying that
my application is using deprecated QTKit API’s. I’ve reviewed Danno Ferrin’s
JavaOne session from last year; it says that Update 40’s
libjfxmedia_qtkit.dylib or Update 20’s libjfxmedia.dylib should be removed and
are by the packager. I have this line in my packager output from the packager,
as you can see the libfxmedia.dylib is in my app and pkg. Is this an oversight
by the packager and the libfxmedia.dylib should also be removed from my
packaged application?
The original message from ITunes Connect said that these API’s are referenced,
when I questioned Apple as to what code was referencing these they said it was
the JavaFX Media library.
ITunes Connect Responce:
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
Dear developer,
We have discovered one or more issues with your recent delivery for "Examine-IT
Pro". To process your delivery, the following issues must be corrected:
Deprecated API Usage - Apple no longer accepts submissions of apps that use
QuickTime or QTKit APIs.
Once these issues have been corrected, you can then redeliver the corrected
binary.
Regards,
The App Store team
Running [codesign, -s, 3rd Party Mac Developer Application: THUNDERCLOUD
RESOURCES, LLC (82Z9WT6K6N), --prefix, com.thundercloudresources.examineit.,
-vvvv, --entitlements,
/var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/macosx/Examine-IT
Pro.entitlements,
/var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib]
/var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT
Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib:
signed Mach-O thin (x86_64) [com.thundercloudresources.examineit.libjfxmedia]
