Hi,
and one more thing, I don't care about Unsafe. It can die unless it is
involved in a workaround for the StringIndexOutOfBoundsException in
CertUtils.checkWildcardDomain we currently see in java 8u60-ea when
opening an https connection to our servers. Hopefully this can be fixed
till the final release.
But in all artificial restrictions to implement your own workarounds
using private apis its another minus on our assessment of the risks
involved, when investing in the javafx technology. Others are the
diminishing plugin support by browser vendors and a lack of commitment
from oracle for growing platforms like android or ios.
On the other side of the equation is unrestricted access of the
application to the local filesystem and cpu resources and the rich java
apis.
Currently the equation still holds in favor of javafx, but is constantly
evaluated.
And as you can see at http://easyprint.com we currently use different
technologies for the online editors of our print products. Still adobe
flash for the simple products (Print products and Textile products) and
an new JavaFX based editor in the same design as the flash editor for
the more complex photo products. So an html5 editor could certainly
become the successor of the javafx editor.
Anyway I think especially for webstart applications, which have no
control over the installed jre should have the possibility to access
private apis. If a installed application can do it, why shouldn't the
same be possible for a webstart application?
<evil grin>
Or perhaps, as it has full access to the filesystem, my application
could start patching class files in the installed jre....
</evil grin>
No, I don't think that would be a good idea.
- Stefan
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
<krue...@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
