JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net

The open source
grid computing

 Home   About   Features   Download   Documentation   On Github   Forums 
September 29, 2020, 07:18:59 PM *
Please login or register.

Login with username, password and session length
Advanced search  
News: New users, please read this message. Thank you!
  Home Help Search Login Register  
Pages: [1]   Go Down

Author Topic: jmxremote_optional.jar  (Read 2777 times)


  • JPPF Master
  • ***
  • Posts: 25
« on: August 20, 2012, 04:07:22 PM »

There is a license text file for jmxremote_optional.jar included.
The license seems to be a proprietary Sun license.

Does that mean I only have to ship this license and mention it when my project has an opensource license?

According to this page JMX is built-in since JDK 5.
Is this jmxremote_optional.jar left due to a lack of time to adapt to (possibly) changed API of the built-in JMX?


  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2262
    • JPPF Web site
Re: jmxremote_optional.jar
« Reply #1 on: August 21, 2012, 07:50:40 AM »


The JMX APIs are indeed now part of the JDK, including the default implmentation of the RMI connector.
However, JPPF uses the Reference Implementation of the JMX remote APIs, which isn't part of the JDK. It is distributed under different license terms, which we include in the JPPF distribution.
These licensing terms, at least as far a we could understand them, include a right to redistribute the reference implementation when it is needed for the software to work.

So, yes, I would recommend that you ship the associated license in your own project, I don't think you need to do anything else.
I believe it would have been much more practical to include the license within the jar itself, but then it might constitute a modification of the redistributable ...
As you have probably noticed already, navigating the legal subtleties in an open source project has become quite complicated, and we try to avoid any possible issue for our users.

As to the reasons which we chose to use the Reference Implementation rather than the built-in RMI connector:
- the RMI connector is cumbersome, as it requires an RMI registry and an additional associated TCP port
- it generates more network traffic
- it has severe limitations with regards to security

I hope this clarifies.



  • JPPF Master
  • ***
  • Posts: 25
Re: jmxremote_optional.jar
« Reply #2 on: August 21, 2012, 10:44:54 AM »

Thanks. Very informative!  :)
Pages: [1]   Go Up
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at Fast, secure and Free Open Source software downloads