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 <t...@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 <t...@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 <ramonjsanti...@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 <johnvalr...@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 <ramonjsanti...@gmail.com> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> -- 
>>>>>>> rjs
>>>>> -- 
>>>>> rjs
>>> 
> 

Reply via email to