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

[<markus.karg@xxxxxxxxx>]

Dominique,

for your historical review, you shouldn't forget that in 1996 Java was a 
closed, proprietary project of Sun. James Gosling wanted to invent a system 
to drive Sun's embedded controllers SOLELY (which where AFAIK stack based). 
Lateron Sun thought they are strong enough to push their own ideas and 
already developed VM and Language and API into other markets. They didn't 
care someone's opinion since they had that technology ready and thought to be 
a global player.

But Sun did learn something. That Java is only emerging REALLY if they open 
the development process to everyone's knowledge input.

Today, Java is developed under the democratic process of the JCP.org. Today, 
every expert has the ability to join the expert group for free and do a 
knowledge transfer from his local domain into the upcoming, global Java 
standards. So why is ObjectWeb not just opening a JSR and leading an expert 
group for this topic? Why do we still want to develop our own, local solution 
where there is the way free for developing a standard solution?

We have 2003, not 1996. We should start thinking in global effects instead of 
local interests.

Have Fun
Markus

-------- Original Message --------
Subject: RE: Re-4: [ObjectWeb architecture] just an idea for (Java) native 
compilation (26-Sep-2003 13:35)
From:    dominique.devito@xxxxxxxxxxxxxxx
To:      markus.karg@xxxxxxxxx

> >===== Original Message From <markus.karg@xxxxxxxxx> =====
> >Dominique,
> >
> >Actually not GCJ is reinventing the whell, but you do:
> >
> >- AFAIK GCJ is basing on GCC, a compiler framework that comes with a 
> common 
> optimizing backend, exchangeable frontends and code creation engines. This 
> means, GCJ is GCC supplied with a platform specific code creation engine (
> x86) 
> plus a Java
> >frontend (Java parser). Also the backend is platform dependend, which 
> means, 
> the machine code creation engine can be changed to produce Java Binaries, 
> x86 
> Machine Code etc. I cannot see any reinvention here.
> >
> >- Actually your compiler does not exist but only is an idea on the paper. 
> Since I did not hear of any breaking news from you, I am assuming that it 
> is 
> just another compiler, that compiler OCaml language into x86. So what is 
> the 
> difference here? Why
> >is your compiler NO reinvention of existing compiler technology? Why not 
> just 
> adding an OCaml frontend to GCC instead to prevent reinvention of backend 
> (optimizer, code creation)?
> >
> >What actually (in one sentence) is your invention, if you think GCJ is a 
> reinvention but OCaml-Compiler is not?
> >
> >Have Fun
> >Markus
> 
> Markus,
> 
> Your remarks (this email and the others) are valid.
> 
> I don't exclude to be wrong, even at 100 % :-)
> 
> May be I am still thinking too much about 1996-1997 where Java was emerging,
>  
> with slow VM, and people thinking about Java compilation, while Caml 
> compilation was already (!) existing (if my memories of my 199x's Caml 
> programmation are correct). And then, at this time, I was already hoping 
> about 
> "some" knowledge "transfer". So my connexion Caml-ObjectWeb consortiums (
> with 
> OCaml intermediary step *if* needed). But this may be too late to be 
> worthty.
> 
> I remember also old times (199x) where great names (Kernighan, Pike...) at 
> Bell Labs were designing a new-C-language called Limbo (for embedded 
> purposes 
> I think), some kind of Java but non-OO and running also on VM but 
> registry-based and specific memory model (see 
> <http://www.vitanuova.com/inferno/concepts.html> and more precisely, The 
> Dis 
> Virtual Machine Specification at 
> <http://www.vitanuova.com/inferno/papers/dis.html>). They have written 
> somewhere that the *first* JIT Limbo VM, they have developped, contained in 
> 
> 1600 lines of C and was achiveing 1/2 of the performance of C equivalent 
> programs (few lines of code for Limbo VM due to easy mapping between Limbo 
> VM 
> and read hardware) ! Not too bad compared to the first JIT Java VM (but, of 
> 
> course, Limbo was non-OO but even if module-based) ! Reading that, I was 
> wondering again about some Java technological choices (for example, why a 
> stack VM as most hardwares are registry based ? this is against 80-20 rule) 
> 
> and knowledge "transfers".
> 
> I think there is plenty room for innovation but my previous emails have a 
> strong chance :-) to be useless (too late), except might be in embedded 
> systems. Forget it !
> 
> Have fun also,
> Dominique
> 
> 
> 
> >-------- Original Message --------
> >Subject: RE: Re-2: [ObjectWeb architecture] just an idea for (Java) native 
> 
> compilation (25-Sep-2003 16:44)
> >From:    dominique.devito@xxxxxxxxxxxxxxx
> >To:      markus.karg@xxxxxxxxx
> >
> >> >===== Original Message From <markus.karg@xxxxxxxxx> =====
> >> >Oh, now I understand. So is the OCaml compiled native code faster than 
> the
> >>
> >> code from other compilers, e. g. from GCJ?
> >>
> >> Sure, GCJ is existing and my hypothetic compiler is still in paper form.
> >>
> >> But, when I read news in the GCJ home page <http://gcc.gnu.org/java/>, I
> >> wonder if GCJ developers are not reinventing the wheel, step by step, 
> when
> >> focusing to a high-performance native compiler. And then, I wonder if I
> >> would
> >> be simpler for join strengths.
> >>
> >> The same when I read that Python guys want to develop a native compiler, 
> I
> >> wonder why they don't generate some OCaml code as Python and OCaml are 
> so
> >> close.
> >>
> >> Of course, same as above : if GCJ provides what most people expects 
> today (
> >> I
> >> have not enough knowledge about it to validate this or not), nobody has 
> to
> >> care about my compiler in paper form !
> >>
> >> Dominique
> >>
> >>
> >>
> >> >Do you have benchmarks (I'm really interested in getting Java running
> >> faster)? For the second point: Sure constructing an
> >> >ObjectWeb own native java compiler is interesting, but do we have 
> manpower
> >>
> >> for such a project?
> >> >
> >> >-------- Original Message --------
> >> >Subject: RE: [ObjectWeb architecture] just an idea for (Java) native
> >> compilation (25-Sep-2003 11:08)
> >> >From:    dominique.devito@xxxxxxxxxxxxxxx
> >> >To:      markus.karg@xxxxxxxxx
> >> >
> >> >> >===== Original Message From <markus.karg@xxxxxxxxx> =====
> >> >> >Maybe I have not quite understood what the benefit of a cross
> >> compilation
> >> >> from Java to OCaml should be. Java is fast already and if I want to 
> make
> >> it
> >> >>
> >> >> faster, I would prefer native compilation (machine code) instead of
> >> OCaml.
> >> >> Cross compilation
> >> >>
> >> >> I also focus here native compilation for Java but between the Java 
> code
> >> and
> >> >>
> >> >> the binary code, I have just talked about an intermediary step : the
> >> OCaml
> >> >> code.
> >> >>
> >> >>
> >> >> >between Java and OCaml would weaken the idea of one common Java
> >> platform,
> >> >> since it would degrade Java to one of many possible source languages 
> for
> >> >> OCaml. But instead, the idea behind Java is that it is the only 
> target
> >> >> platform itself. So I will not
> >> >> >support this idea.
> >> >> >Also OCaml is seldomly used, while Java is widely spread. So I only 
> see
> >> a
> >> >> benefit for OCaml, not for JOnAS.
> >> >>
> >> >> No degradation here for my point of view : the OCaml language is used
> >> here
> >> >> as
> >> >> an intermediary step for Java native compilation. Just as the first C+
> +
> >> >> compilers. The C language was used for the intermediary step : C++ -> 
> C 
> -
> >> >
> >> >> native code and this compilation way has not weakened the C++ 
> language
> >> and
> >> >> it
> >> >> was not for the benefits of C.
> >> >>
> >> >> Instead of generating OCaml code from the Java code, another way 
> might
> >> be
> >> >> to
> >> >> reuse&share some parts of the outstanding OCaml compiler in order to
> >> build
> >> >> a
> >> >> Java compiler.
> >> >>
> >> >> Just my 2 cents.
> >> >>
> >> >> Best regards,
> >> >> Dominique De Vito
> >> >>
> >> >>
> >> >> >Have Fun
> >> >> >Markus
> >> >> >
> >> >> >-------- Original Message --------
> >> >> >Subject: [ObjectWeb architecture] just an idea for (Java) native
> >> >> compilation
> >> >> (24-Sep-2003 21:56)
> >> >> >From:    dominique.devito@xxxxxxxxxxxxxxx
> >> >> >To:      markus.karg@xxxxxxxxx
> >> >> >
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> This is just an idea for (Java) native compilation.
> >> >> >>
> >> >> >> INRIA has an outstanding knowledge about native compiler 
> technology.
> >> To
> >> >> be
> >> >> >> more precise, INRIA has developped a native compiler for the "
> >> Objective
> >> >> >> Caml" language. Caml is a strongly-typed functional programming
> >> language
> >> >> >> from the ML family. OCaml (Objective Caml) and Caml Light are two
> >> open
> >> >> >> source implementations of Caml developed at INRIA Rocquencourt,
> >> projet
> >> >> >> Cristal. See <http://caml.inria.fr/> and 
> <http://caml.inria.fr/ocaml/>
> >> .
> >> >> >>
> >> >> >> INRIA has started at January 2001 the Caml consortium (like the
> >> >> ObjectWeb
> >> >> >> consortium) : the Caml consortium federates the design and
> >> development
> >> >> of
> >> >> >> the Caml language and its programming environment. The Objective 
> Caml
> >> (
> >> >> >> OCaml) compiler is released by the Caml Consortium and performs 
> very
> >> >> well :
> >> >> >> Objective Caml ranks 2nd on speed (between C and C++) on Doug 
> Bagley'
> >> s
> >> >> >> computer language shootout ! See
> >> <http://www.bagley.org/~doug/shootout/>.
> >> >>
> >> >> >>
> >> >> >> So, why not joining Caml & ObjectWeb consortiums strengths for
> >> >> developping
> >> >> >> a Java compiler ? One way could/would be to develop a bridge Java->
> 
> >> OCaml
> >> >> as
> >> >> >> OCaml's object-oriented features are similar to Java's object-
> >> oriented
> >> >> >> features (Ocaml also includes functional features, module 
> features...)
> >> .
> >> >> >>
> >> >> >> What do you think about this idea ? Silly idea :-) ? Good idea ?
> >> >> >>
> >> >> >> Best regards,
> >> >> >> Dominique
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> To: architecture@xxxxxxxxxxxxx
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> To: markus.karg@xxxxxxxxx
> >> >>     architecture@xxxxxxxxxxxxx
> >>
> >>
> >>
> >>
> >> To: markus.karg@xxxxxxxxx
> >>     architecture@xxxxxxxxxxxxx
> 
> 
> 
> 
> To: markus.karg@xxxxxxxxx
>     architecture@xxxxxxxxxxxxx