com.sun.javafx vs javafx (with example/request)

[Kevin Rushforth]

While there is no plan to "open up" more of com.sun.javafx (and that 
isn't really the right way to look at it), if you have a proposed 
enhancement to the existing public javafx.* classes we could discuss it.

As for your specific example, can you say more about what your use case 
is? The GraphicsContext object is a drawing context for a Canvas node, 
so it is not a natural place to put an API that computes or returns a 
path. I get the sense that you are looking at the existing internal 
implementation classes and saying "how can I get access to some 
information that might be useful to my application" rather than 
describing what your application is trying to do. Once we understand 
what you are trying to do, we can discuss whether the need is general 
enough to propose adding to the public API of JavaFX and what form such 
a new API might take.

-- Kevin


On 5/8/2020 9:35 AM, jfx user2 wrote:
> I am aware of this and that’s why I am asking.  There are useful private features in com.sun.javafx and I explained one of them in my message.  I have an additional related example but the larger question is if there is a plan to open more of com.sun.javafx to the public api, documentation surrounding this, or possibly a complete replacement?
>
> Please consider the example I provided as a feature request.
>
>> On May 8, 2020, at 9:39 AM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> Only javafx.* packages are part of the public API. Anything else, including com.sun.javafx.*, is internal implementation details that an application should never call.
>>
>> -- Kevin
>>
>>
>>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>>> in JavaFX?
>>>
>>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>>> in the javafx.scene.shape package?  Why are there missing features from
>>> Graphics2D?
>>>
>>> I have a specific example that prompted the question:
>>>
>>> Consider the following classes:
>>>
>>> javafx.scene.shape.Shape
>>>      private static Path
>>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>>>
>>> javafx.scene.canvas.GraphicsContext
>>>      Path2D path;
>>>
>>> I want to write a line as follows:
>>> Path path = Path.createFromGeomShape(gc.path);
>>> b/c I want to inexpensively get the outline of the GraphicsContext.
>>>
>>> However:
>>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>>> by the module.
>>> We can't access Path.createFromGeomShape b/c it's private.
>>> We can't access path in GraphicsContext b/c it's default and doesn't have
>>> an accessor.
>>>
>>> A possible solution is to add a new method:
>>> javafx.scene.canvas.GraphicsContext
>>> public Path getPath() {
>>>      //implementation copied from
>>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>>> }
>>>
>>> That would solve my immediate problem but raises the question... why is
>>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>>> in progress that will impact this design?
>>>
>>> PS my example is actually very important.  I currently use reflection and
>>> module opens in the build to get the path but if the getPath method could
>>> be added to GraphicsContext, that would be great.  For performance, it
>>> would be even better to get the PathIterator directly instead of
>>> translating into a javafx..Path but that is related to the bigger question.