Anyone using JMX with JavaFX?

Kevin Rushforth kevin.rushforth at oracle.com
Mon Jun 13 16:12:39 UTC 2016


Thank you for the replies. It helps confirm what I suspected, that this 
feature isn't really used. If anyone is using it who hasn't chimed in 
yet, please let me know what you are using it for.

Thanks.

-- Kevin


Scott Palmer wrote:
> I never heard of this until this thread. And after googling I still have no clue what it is. I think that explains some of why it is rarely used.
>
> Scott
>
>   
>> On Jun 10, 2016, at 6:01 AM, dalibor topic <dalibor.topic at oracle.com> wrote:
>>
>> I suspect that particular plugin is extremely rarely used, judging by https://github.com/search?utf8=%E2%9C%93&q=%22javafx-mx.jar%22&type=Code&ref=searchresults showing 0 results.
>>
>> cheers,
>> dalibor topic
>>
>>     
>>> On 09.06.2016 00:31, Kevin Rushforth wrote:
>>> As some of you may be aware, JavaFX has shipped a JMX plugin as a
>>> separate jar file along with the JDK (not part of the JRE) in
>>> <JDK>/lib/javafx-mx.jar. Development on this plugin stopped prior to JDK
>>> 8 being shipped, although we continued to ship javafx-mx.jar in JDK 8.
>>>
>>> Are there any developers that still use this? We haven't seen any bug
>>> reports or had questions on it for quite a while. I note that this jar
>>> file has been gone from JDK 9 ea since build 111 and we are trying to
>>> determine how best to address this in JDK 9.
>>>
>>> Our options are:
>>>
>>> 1) Remove it entirely and drop this tooling support
>>>
>>> 2) Continue to ship it as a legacy jar file, meaning that any use would
>>> require command line qualified exports to be added since it uses
>>> internal packages
>>>
>>> 3) Turn it into a proper JDK-only module, javafx.jmx; it would not be
>>> one of the default modules, so it would need to be added with -addmods.
>>>
>>> Obviously #1 would be the least amount of work, and given that it isn't
>>> being actively maintained, might be a viable solution. If we do need to
>>> keep it, then #2 might be less effort than #3, while still preserving
>>> the ability for developers to use it. This is only used for tooling, so
>>> requiring qualified exports, as is done for Robot and
>>> PerformanceTracker, is not a problem.
>>>
>>> Separately, if we don't remove it for JDK 9, we probably will deprecate
>>> it with the intention to remove it in a future release.
>>>
>>> -- Kevin
>>>       
>> -- 
>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>> <tel:+491737185961>
>>
>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>
>> ORACLE Deutschland B.V. & Co. KG
>> Hauptverwaltung: Riesstr. 25, D-80992 München
>> Registergericht: Amtsgericht München, HRA 95603
>>
>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>
>> <http://www.oracle.com/commitment> Oracle is committed to developing
>> practices and products that help protect the environment
>>     


More information about the openjfx-dev mailing list