It'll work as long as the class in question (Screen in this case) is exported.
If not, you'll likely get a security exception or CNFE.
-DrD-
> On Jun 5, 2015, at 8:28 AM, Kevin Rushforth
> wrote:
>
> Yes, this will still work, although dipping into non-public state continues
> to be somethin
I promise to ditch that code as soon as there is a viable alternative. :-)
Am 05.06.15 um 17:28 schrieb Kevin Rushforth:
Yes, this will still work, although dipping into non-public state
continues to be something we wouldn't recommend that an application
rely on...
-- Kevin
Dr. Michael Paus w
Yes, this will still work, although dipping into non-public state
continues to be something we wouldn't recommend that an application rely
on...
-- Kevin
Dr. Michael Paus wrote:
As nobody has stated it explicitly so far I would like to ask what
will happen
to classes in Java9 which access me
As nobody has stated it explicitly so far I would like to ask what will
happen
to classes in Java9 which access methods that are within the javafx
namespace but
are declared private? Will code like this still work or not?
public static double getPixelScale(Screen screen) throws
NoSuchMetho
Oh, of course, never mind then.
Jdeps output from our application is on its way to Jonathan.
Stefan
Right. They won't be flagged as problematic by the tool, but Jonathan
knows which ones are -- namely, any JavaFX package that doesn't begin
with "javafx."
-- Kevin
Nicolai Parlog wrote:
Hi
Thanks everyone for emailing me your jdeps output - I now have 15 files
and plenty of data to do some more analysis. You can stop emailing me
files now! :-)
Also, Nicolai and Kevin are correct - I'm not relying on JDeps to do any
analysis of the output for me, I'm just using it to dump all ref
Right. They won't be flagged as problematic by the tool, but Jonathan
knows which ones are -- namely, any JavaFX package that doesn't begin
with "javafx."
-- Kevin
Nicolai Parlog wrote:
Hi Stefan,
running jdeps as shown in Jonathans post (with "-v") "[p]rints all
class-level dependencies"[
Hi Stefan,
running jdeps as shown in Jonathans post (with "-v") "[p]rints all
class-level dependencies"[1]. This includes the ones which will not be
accessible in Java 9.
The bug you cite is based on a missing definition of some packages as
internal API, so running with -jdkinternals will not li
Hi Jonathan,
thank you for your effort.
Note however, that the output of the current version of jdeps may be
incomplete.
See https://bugs.openjdk.java.net/browse/JDK-8077349 Update jdeps to
recognize JavaFX internal packages,
which seems not to be fixed yet.
Stefan
Hi folks,
I've writt
Thanks! However I have also jars which are using JavaFX on which I will use the
tool against !
Sent from my iPhone
> On Jun 3, 2015, at 18:08, Phil Race wrote:
>
> I can't speak for Jonathan on that point but if you find you are using
> something not on the list at the URL below, you may want
I can't speak for Jonathan on that point but if you find you are using
something not on the list at the URL below, you may want to ask
on the appropriate list what would be a suitable replacement
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
Note that sometimes it can
I know that it's the openjfx list, but are you also interested on other
internal APIs usages?
Hervé
Sent from my iPhone
> On Jun 3, 2015, at 08:17, Jonathan Giles wrote:
>
> Hi folks,
>
> I've written a tool that analyses the output of JDeps. This allows for me to
> quickly understand what
Do you mean elsewhere in the JDK? Those would be better discussed on
either the jigsaw-interest list or on the relevant list for those APIs
(e.g., awt, swing, java2d have their own lists).
-- Kevin
Hervé Girod wrote:
I know that it's the openjfx list, but are you also interested on other inte
Hi folks,
I've written a tool that analyses the output of JDeps. This allows for
me to quickly understand what com.sun.* APIs are being used by projects.
It basically just gives a tally of each com.sun.* class that is being
used, given a directory of files that are output from JDeps (where eac
14 matches
Mail list logo
