Private APIs not usable in Java 9?

Wed Apr 8 19:52:42 UTC 2015

exactly. I don't give a **** about Unsafe but I have to deal with the
realities of Java(FX) in its current state and as long as bugs or
limitations that simply make it impossible to ship a product that can
compete with others in our market sit there for months or years and our
only workaround is to use private API and that is taken away then we only
have the choice to move to another technology, which we do not really want
to do. Luckily we are in a better position than Stefan still being able to
modify the JRE in those emergencies but I absolutely see his point.

Your point about Java 8 being available for a long time is moot in a JFX
context as we all know that JFX is very much in motion and needs to be,
because it is far from mature. _All_ of my 6 open issues in Jira plus some
others I am watching because we have run tinto them as well haven been
scheduled for Java 9. _All_ of them are either serious problems or even
showstoppers for products of ours. Should I rely now on all of those fixes
to be backported to 8?

On Wed, Apr 8, 2015 at 9:21 PM, Stefan Fuchs <snfuchs at gmx.de> wrote:

> Hi,
>
> you are right, there are still years to the end of public updates to JDK
> 8....   We can use them to migrate to other technologies.
>
> - Stefan
>
>
>
>  Making any theoretical flag available to the deployment side would
>> entirely miss the point.
>>
>> Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait for
>> it -- Unsafe.  It must go.  Ignore any kind of theoretical rope and start
>> the path to righteousness _*/now/*_. It is still years until the end of
>> public updates to JDK 8, so we have /*years */to work this out properly.
>> But sticking our heads in the collective sands and hoping for trivial work
>> arounds to Unsafe is not going to work.  If you're using Unsafe, this is
>> the year to explain where the API is broken and get it straight....
>>
>> Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do
>> so as quickly as possible to the ultimate benefit of everyone.
>>
>>  - Don
>>
>> On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
>>
>>> Hi,
>>>
>>> then I can only hope, that this flag is available to webstart
>>> applications.
>>> Webstart applications have no control over the installed jre. In the
>>> past we encountered various bugs in the jre, which required using internal
>>> apis for workarounds.
>>> For example in some releases of Java 7 the swing gui thread did not
>>> start unless hacking internal apis (see https://javafx-jira.kenai.com/
>>> browse/RT-31205 for details). If such an error occurs again in the
>>> future and we are no longer able to hack around the problem, our only
>>> choice to keep our business alive, is to discourage users from upgrading to
>>> newer versions of the jre, exposing them to security risks.
>>>
>>> - Stefan
>>>
>>>
>>>
>>>> >  it's not strictly JFX-only.
>>>>
>>>> Its not remotely FX only, in fact I could argue FX is not so affected,
>>>> as being relatively new it does not have 20 years of accumulation
>>>> of people using internal APIs that the larger JDK does, often dating
>>>> from
>>>> when there were no suitable public APIs. There still remains some
>>>> of that with sun.misc.Unsafe as pointed out which will indeed be
>>>> inaccessible in modular mode. But the FX list isn't really the place
>>>> for that discussion. The jigsaw-dev is the appropriate list. FX
>>>> is simply bound by the rules that are set there.
>>>>
>>>> There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
>>>> transition.
>>>>
>>>> Also remember FX is open source. You can propose patches !
>>>> If there are specific APIs that are missing from FX that are suitable
>>>> to be *supported* public APIs then those could be considered here (this
>>>> list).
>>>>
>>>> -phil.
>>>>
>>>> On 4/8/2015 9:28 AM, Mike Hearn wrote:
>>>>
>>>>> sed -i 's/private/public/g' ;)
>>>>>
>>>>> The whole notion of a strongly enforced private keyword is IMHO dumb
>>>>> when
>>>>> not using sandboxing. The number of gross hacks that occur in an
>>>>> attempt to
>>>>> work around overly strict enforcement of this stuff is crazy. The D
>>>>> compiler has a special flag that disables visibility enforcement when
>>>>> compiling unit tests, and that's a good idea, but why not go all the
>>>>> way
>>>>> and just make accessing of private state a compiler warning a la
>>>>> deprecated?
>>>>>
>>>>> I also need to use private JFX APIs. I think any real JFX app does,
>>>>> way too
>>>>> much basic stuff relies on it. Heck, the number of popular Java
>>>>> libraries
>>>>> that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
>>>>> in
>>>>> this regard then I will just write a simple tool that flips
>>>>> private->public
>>>>> either at the source level or via bytecode editing, and see what
>>>>> happens :-)
>>>>>
>>>>>
>>>>> On Wed, Apr 8, 2015 at 6:14 PM, Robert Krüger <krueger at lesspain.de>
>>>>> wrote:
>>>>>
>>>>>  Hi,
>>>>>>
>>>>>> I hope this is not too off-topic, because although it came up in a JFX
>>>>>> context it's not strictly JFX-only.
>>>>>>
>>>>>> Someone from our team recently had a chat with a high-ranking regional
>>>>>> Oracle representative who gave a talk on the state of JFX. Our guy
>>>>>> explained our situation (evaluating JFX to migrate our swing-based
>>>>>> product,
>>>>>> feeling it's in principle the right technology but still having
>>>>>> show-stopping limitations like RT-36215) and the Oracle guy offered to
>>>>>> relay our concrete questions to the right people, which he did.
>>>>>>
>>>>>> The answer we got contained one thing that really was a bit of a
>>>>>> shock and
>>>>>> I would like someone to either confirm this or clear up a
>>>>>> misunderstanding.
>>>>>>
>>>>>> The statement was that private APIs will not be available in JDK 9
>>>>>> due to
>>>>>> modularity restrictions. If that is the case and we no longer have the
>>>>>> ability to build temporary workarounds using private APIs (which in
>>>>>> our
>>>>>> case is controllable as we ship the JRE with our product), I would
>>>>>> probably
>>>>>> have to stop any development going into the direction of JFX as we
>>>>>> will
>>>>>> probably have to use 9 at some point because many things now
>>>>>> scheduled for
>>>>>> 9 will not get fixed in 8 and we will most likely still need
>>>>>> workarounds
>>>>>> using private API, at least that's what my current experience with JFX
>>>>>> tells me.
>>>>>>
>>>>>> Please tell me that this was a misunderstanding (maybe meant for the
>>>>>> general case where one does not ship the JRE) or a non-engineering
>>>>>> source
>>>>>> that simply made mistake.
>>>>>>
>>>>>> Best regards and thanks in advance,
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>

-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com