Has any consideration been made to move the Charts into s separate module?

[John-Val Rose]

I think we actually agree Tom.

I have not established what is “core” JavaFX simply because it has never crossed my mind that some modules are “core” whereas others must (by inference) be “peripheral”.

I don’t see any value in refactoring charts into their own module given that, as I said, without controls there’s not much value in using JavaFX.

There are lots of really good 3rd-party controls libraries such as those of Gerrit that you mentioned but there are numerous other 3rd-party JavaFX libraries that do not relate to controls at all.

I guess I just don’t see any reason to strip JavaFX right down to the “core” (whatever that is) by for example moving charts or any other specific type of control into separate JPMS modules.

And does anyone have some actual real-world stats as to how frequently charts are used? I, for one, certainly do not view them as “dead weight”.

> On 6 Jan 2019, at 23:16, Tom Eugelink <tbee at tbee.org> wrote:
> 
> I'm responding to your "moving he charts to a separate JPMS  module". It would make sense to have a javafx.charts, but at least charts are not in javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal JPMS module to have them in. But since they are now, it's not really worth a refactor. Given the typical size of a controls application, the charts classes won't make much of a difference.
> 
> Whether charts belong in OpenJFX in the first place, and this what I think you mean with "core" (you have not established that concept either), is another topic. I would say no, the chart library of Gerrit illustates that. But someone at some point thought it was a good idea, just like half of Maven is/was in the JRE (a new HTTP client implementation???). So because of backward compatibility keeping in OpenJFX what was in Oracle's JRE makes sense. Call it historical debt or something. We just need a better alternative and then the classes can be removed at some point in the future.
> 
> 
>> On 6-1-2019 10:43, John-Val Rose wrote:
>> So Tom are you saying that javafx.base and javafx.graphics are the only “core” modules in JavaFX?
>> 
>> Has that ever been officially stated or established?
>> 
>> How can javafx.controls or javafx.fxml not be considered core modules?
>> 
>> There’s not much you can do with JavaFX without controls and FXML (albeit optional) is a critical part of most JavaFX apps.
>> 
>>> On 6 Jan 2019, at 20:27, Tom Eugelink <tbee at tbee.org> wrote:
>>> 
>>> But (I assumed charts was in core as Ramon said) taking a look at the javadoc; charts are in the controls module, not in the core (javafx-base or javafx-graphics). So that seems quite ok.
>>> 
>>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html
>>> 
>>> 
>>>> On 6-1-2019 02:58, John-Val Rose wrote:
>>>> I doubt any JavaFX application would use ALL the features so couldn’t you make the same argument for “detachment” about many other parts of JavaFX?
>>>> 
>>>> And what are the “core components”? That is probably a subjective question.
>>>> 
>>>>> On 6 Jan 2019, at 00:56, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>> 
>>>>> Yes, I meant removing charts from the core of JavaFX and moving he charts to a separate JPMS  module.
>>>>> 
>>>>> Why? They are not really core components are they? They are dead weight in applications that never will use them.
>>>>> 
>>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>>>>>> Hi Ramon,
>>>>>> 
>>>>>> I personally have never seen or heard of any such discussion and I’m not entirely sure in which context you are using the word “module”.
>>>>>> 
>>>>>> Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS?
>>>>>> 
>>>>>> Either way, can you tell us why you have thought of this idea?
>>>>>> 
>>>>>> Graciously,
>>>>>> 
>>>>>> John-Val
>>>>>> 
>>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago <ramonjsantiago at gmail.com> wrote:
>>>>>>> 
>>>>>>> -- 
>>>>>>> rjs
>>>>> -- 
>>>>> rjs
>>> 
>