I'll update the thread when I get a response from Apple on my latest submission. I believe someone is doing an App Store talk or packager talk at JavaOne. They can include the information in the thread
Sent from my iPhone > On Sep 30, 2015, at 3:05 PM, Scott Selvia <ssel...@gmail.com> 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] >>
