harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Bordet" <simone.bor...@gmail.com>
Subject Re: [classlib][jmx] Options for going forward w/ MX4J
Date Mon, 02 Oct 2006 07:35:53 GMT

On 9/26/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Geir Magnusson Jr. wrote:
> > I've been talking with Simone Bordet about how we might bring MX4J into
> > Harmony.  I think it's a good code base to build our JMX implementation
> > on, as it's well tested and has been used in implementations that have
> > been tested with the JMX TCK.  (We can't say that MX4J passes, as I
> > don't believe the project has a TCK).  MX4J has served many people over
> > many years, and it's a shame that the addition of JMX into the SE
> > platform has sent this project into it's "golden years".
> I see it a bit differently -- it is a testament to the quality and broad
> use of MX4J that has helped make JMX a compelling addition to Java SE.
> I join you in commending Simone and the other contributors for their work.

Thanks for the kind words.

> > There were a lot of issues discussed, mainly about user support, time
> > Simone could commit to help us, etc , and in summary, it boils down to
> > this :
> >
> > Simone has no problem with us doing a "gentle fork" (in his words) of
> > the code to build on.  By this, we are simply taking a snapshot of the
> > project codebase, and building upon it.   This is not a hostile,
> > anti-community act, but simply a recognition that it's useful code for
> > us, we want to keep building on the code base, but need to make
> > modifications for java SE 5 that are incompatible with the needs of the
> > pre-Java 5 users that the MX4J project support.
> I read this as an indication that MX4J has no interest in pursuing a 5.0
> compatible implementation?  Likewise we have no interest in distributing
> a 1.4 version.

Correct. My take on the issue is that there is no point for MX4J to
implement JMX 1.3 (shipped in JDK 5), since it will be very rare that
people will put such an alternative implementation in the boot
classpath before the JDK classes.
I think implementing JMX 1.3 belongs more to an effort such as
Harmony, or such as Application Servers heavily based on JMX that
support J2EE 5.

> Presumably all the enhancements that are made in the Harmony SVN tree
> are 'our new enhancements', so identifying them will not be a problem.
> Putting the code into standard sounds like the right answer.  I assume
> that in this scenario, and unlike concurrent, we do not attempt to keep
> the two sites in sync.

This is also my thinking. We can agree on a best effort communication
where mx4j notifies harmony-dev of bugs discovered in mx4j, or of new
releases, and harmony can communicate bugs to mx4j, with the goal of
saving time and energy, but not with the goal of keeping the codebases
in sync.



Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message