Private APIs not usable in Java 9?

[Stefan Fuchs]

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
>>>>>
>>>
>>>
>>
>
>