[Re-sending with more line breaks (hopefully - looked fine when sent but most
were gone when I received it)]
Tom Schindl wrote:>So to summerize the most lacking API is in the font/text
rendering space
What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX)
features :
-
Tom Schindl wrote:>So to summerize the most lacking API is in the font/text
rendering space
What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX)
features :- Something like WritableImage.getGraphicsContext() (as we have
Image.getGraphics()).- Something like GraphicsCont
Hi,
as promised here is the list of current private api usages of our application.
Any advice how to achieve the same with public apis is always welcome.
* We use com.sun.webkit.WebPage and com.sun.javafx.webkit.Accessor to implement
our own frontend for the html editor.
It seems to be unmai
Right. The specific list of JavaFX internal packages is listed in the
JIRA I filed, but if you just grep for 'com.sun' that will hit all of them.
-- Kevin
David DeHaven wrote:
You can see any com.sun.* usage by running "jdeps -v some.jar". You'll have to
sort it all out manually, but it's al
You can see any com.sun.* usage by running "jdeps -v some.jar". You'll have to
sort it all out manually, but it's all there.
-DrD-
> I'll second the recommendation to run jdeps on your apps. I note that it
> doesn't currently flag internal FX packages as internal. I filed the
> following RFE t
I'll second the recommendation to run jdeps on your apps. I note that it
doesn't currently flag internal FX packages as internal. I filed the
following RFE to address this:
https://bugs.openjdk.java.net/browse/JDK-8077349
-- Kevin
Chris Newland wrote:
I just asked about this on the adoption
I guess a good place to start would be to eliminate usage of private APIs
from scene builder.
Agreed. I noted the needed to fix SceneBuilder in a comment in
https://javafx-jira.kenai.com/browse/RT-40184 (wherein I said I would
file a new JIRA, but hadn't done that yet). Jonathan has already
I just asked about this on the adoption-disc...@openjdk.java.net list and
the answer from Martijn Verburg is:
---
Hi Chris,
I think the strong advice for those using private APIs is to run the jdeps
tool to see where they are using APIs that will go away / be moved. I'd
then get them to post that
On 08.04.2015 23:03, Stefan Fuchs wrote:
Anyway I think especially for webstart applications, which have no
control over the installed jre should have the possibility to access
private apis.
I would suggest reading http://openjdk.java.net/jeps/200 ,
http://openjdk.java.net/jeps/201 , http://
I guess a good place to start would be to eliminate usage of private APIs
from scene builder. I understand that it doesn't seem to be supported any
more but it'd be extremely weird and embarrassing for Oracle if the UI
builder tool broke on Java 9 given all the work that went into it.
On 9 Apr 2015
For what it is worth, investigations are underway in relation to UI
control skins and behaviors. It's too early for anything definitive to
announce, but it is not inconceivable that
com.sun.javafx.scene.control.skin may become javafx.scene.control.skin,
more or less (with a lot of work cleaning
On Wed, Apr 8, 2015 at 11:03 PM, Stefan Fuchs wrote:
>
> 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 b
On Wed, Apr 8, 2015 at 9:59 PM, Tomas Mikula wrote:
> >Should I rely now on all of those fixes
> > to be backported to 8?
>
> Why do you need them to be backported to 8? Just having them fixed in
> 9 should be fine, no? (keeping the private workarounds for 8)
>
> It was a response to the point th
- Getting access to the native window to let our video player render into a
JFX screen, to have a video player with features and format support that
can compete with other players on the market (RT-36215), basically
following the example of Steve and Felipe's JavaOne presentation
"Integrating JavaF
Hi,
in SWT on JavaFX (most likely NOT a common useage of JavaFX):
-
I had to reside to private-API when it comes to:
* text calculations where there is no public API for things like
FontMetrics, TextLayout, ...
* For some of the direct
>
> For the benefit of the devs on the list, could you please point out what
> private APIs you currently need to use? That way we can make sure proper
> JIRAs are filed and we can connect those to actual real-world problems.
e.g. handling a double click of a file on MacOS is impossible without
I' ll try to compile a list of the private apis we currently use in our
application and why.
Looking forward to using only public apis in java 9 then :-)
- Stefan
On Apr 8, 2015, at 1:52 PM, Robert Krüger wrote:
our only workaround is to use private API
For the benefit of the devs on the
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 f
Just adding to the comment that a specific user has the issue will help,
especially when it comes to validating the fix.
> On Apr 8, 2015, at 2:24 PM, Hervé Girod wrote:
>
> Do you need a specific classification for such JIRAs?
>
> Sent from my iPhone
>
>> On Apr 8, 2015, at 22:05, Danno Ferr
Do you need a specific classification for such JIRAs?
Sent from my iPhone
> On Apr 8, 2015, at 22:05, Danno Ferrin wrote:
>
>
>> On Apr 8, 2015, at 1:52 PM, Robert Krüger wrote:
>> our only workaround is to use private API
>
> For the benefit of the devs on the list, could you please point o
> On Apr 8, 2015, at 1:52 PM, Robert Krüger wrote:
> our only workaround is to use private API
For the benefit of the devs on the list, could you please point out what
private APIs you currently need to use? That way we can make sure proper JIRAs
are filed and we can connect those to actual
>Should I rely now on all of those fixes
> to be backported to 8?
Why do you need them to be backported to 8? Just having them fixed in
9 should be fine, no? (keeping the private workarounds for 8)
T.
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
I do believe in making things right (like killing Unsafe, hiding private APIs).
The transition will just be so much pain now that there is so much
accumulated private APIs used in production. If there were no
accessible private APIs to start with, there would be more pressure to
fix bugs and expos
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
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
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
I think that Oracle people are right. It's more a JDK 9 or jigsaw issue than a
JavaFX issue.
Sent from my iPhone
> On Apr 8, 2015, at 20:22, Tomas Mikula wrote:
>
> My concern is that issues with existing workarounds were given lower
> priority. Now many workarounds will disappear, but I'm wor
My concern is that issues with existing workarounds were given lower
priority. Now many workarounds will disappear, but I'm worried that
the priorities will not be reconsidered.
I think part of the problem is the fact that Java does not have a good
way of marking an API as experimental. Anything p
OK, while I wrote this, all the other replies came in. So I see that your
recommendation for the cases I mentioned is then to patch OpenJDK and
submit Jira issues. Fair enough.
Regarding Jira issues, we are already doing that. Regarding code
contribution, this is a different thing, because in many
OK, if that statement holds true it is not too unlikely it will be the
death of our plans to migrate to JFX (which I am trying to convince my
partners of). I am aware that using private APIs is a last resort and we
don't do that if we don't have to. Realistically the pace at which JFX
(which we thi
> 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 r
If there are FX APIs that are currently private that folks think should be
public, or that are currently necessary to implement a work-around for another
bug, please make sure there is a Jira issue filed for this.
We’ll try to address this for JDK 9 to mitigate this, but everyone should
under
Hi Robert,
No, this is not a misunderstanding. There will be no access to any
classes in non-public packages in JDK 9 by applications for exactly the
reasons the region rep mentioned. For JavaFX this means that no
com.sun.javafx (or similar) packages will be accessible by applications
in JDK
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 visibil
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 migra
36 matches
Mail list logo
