Re-4: [ObjectWeb architecture] just an idea for (Java) native compilation

[<markus.karg@xxxxxxxxx>]

Christophe,

actually the JCP is the central point of Java Development, since they decide 
what goes into Java and what doesn't.

Sure you might invent some technology outside of JCP, but this is proprietary 
technology then and not part of the java platform and as such not guaranteed 
to work on and be available on any host platform. The idea of JCP is to have 
one central, worldwide, open committee to control development of the Java 
platform, and of Java technology.

If you look at any improvement for the Java standard (hotspot, generics, 
autoboxing, j2ee etc.), all of them was developement by an expert group of 
the JCP. So actually JCP is actively developing. Maybe the head does not, but 
the expert groups do: They have to provide RI and TCK. So if they would not 
invent stuff in their meetings, they couldn't provide RI and TCKs. Actually 
the JCP is not only a standardization organization, but the really do active 
development (again, not the administration, but the members).

I do not see ObjectWeb's legitimation of existance in providing proprietary 
solutions realized in the Java language, independent of the work of the JCP. 
Instead I see ObjectWebs value in providing the best ever possible 
implementation of a JCP standard, AND in participating in developing of that 
standards by the JCP. This means, ObjectWeb should actively contribute in the 
expert groups of the JCP, for example by leading an expert group for 
developing a standard for native compilation of Java (which includes 
providing a core RI and TCK), and AFTERWARDS implement the best ever possible 
implementation of that standard. If you do it reverse (as actually), you 
would implement Java-To-OCaml, OCaml-To-Native, then try to standardize and 
see that GCJ and you products don't match. Then you would either stop trying 
to find a standard OR throw away 30% to 50% of both projects, do a standard, 
and reimplement GCJ and your product. I do not see this beeing any effective 
development.

So why not starting a JSR for native compilation or for J2EE-Embedded-Servers 
BEFORE actually implementing anything to prevent throwing away something when 
OTHERS pushed through their ideas to become an official Java Platform 
standard?

It's the same with the one-year-old discussion on MONOLOG. ObjectWeb 
developed Monolog. Apache developed Log4J. Apache went to JCP. Actually the 
J2SE 1.4 logging API is 75% of Log4J. This means, Apache made Log4J being a 
template for the standard. And Monolog? Is still an ObjectWeb-proprietary 
solution, and it's complex to make Monolog servicing inside of Java Logging 
API. If ObjectWeb would have been participating to the JSR of Logging API 
BEFORE implementing Monolog, maybe the logging API would be far better and 
Monolog maybe would be the template for Java Logging.

We are developing proprietary solutions while others use political ways to 
make their native ideas becoming a common standard. We should go that way 
also.

That's the point why I am driving this discussion.

Have Fun
Markus

-------- Original Message --------
Subject: RE: Re-2: [ObjectWeb architecture] just an idea for (Java) native 
compilation (26-Sep-2003 8:36)
From:    christophe.ney@xxxxxxxxxxxxx
To:      markus.karg@xxxxxxxxx

> > And even if this would be the case: Java is controlled by 
> > JCP.org not by Sun. Why not just adding another JSR then 
> > instead of providing proprietary technology? I mean, if you 
> > don't like the government, do you leave the state? No, if you 
> > have trouble with Java, improve it by joining JCP.org! :-)
> 
> Just a comment on this: All cofunders of ObjectWeb are members of
> the JCP, the JCP is a standardization body not a mean to prototype
> new technology, so those two actions are complementary. 
> 
> Thanks,
> Christophe
> 
> Christophe Ney
> President of the Executive Committee
> ObjectWeb Consortium
> 
> mailto:christophe.ney@xxxxxxxxxxxxx
> http://www.objectweb.org
> phone +33 4 76 61 54 87
> mobile +33 6 87 76 96 14
> 
> To: markus.karg@xxxxxxxxx
>     architecture@xxxxxxxxxxxxx