Re: GCJ Native Proposal
On Mon, May 02, 2005 at 11:24:32AM +0200, Arnaud Vandyck wrote:
> Sat, 30 Apr 2005 23:39:00 +0200,
> Mark Wielaard <mark@klomp.org> wrote:
>
> > Yes, both -jbi and -bcabi are really bad choices because they are
> > somewhat obscure technical terms that don't really help the users to
> > know what is special about the package. In a future release the bcabi
> > will also be the default abi used by gcj. And in cases where backwards
> > (and forwards) compatability and seamless interoperability between
> > native and interpreted byte code is wanted you will need to use this
> > -findirect-dispatch technique always. And no, I am not proposing to use
> > -indirect-dispatch as suggix :)
> >
> > IMHO the best suffix would be to just use -gcj for the natively compiled
> > packages. That at least shows the user what the difference is and why
> > the -gcj package is faster and less resource intensive. Because it was
> > created using GCJ.
>
> and -gcj is not technical?! ;-)
>
> Why not just drop the suffix?
>
> libant
> libservlet2.4
> and so on...
This *can* create clashes, e.g. libreadline ...
> Maybe it's a stupid question, but can a C or C++ program call those
> natively compiled libraries? Don't we need to generate headers? (now
> everybody is aware that I don't know nothing about C and C++! :-D)
Sure, its possible. You can execute a JVM from C/C++ Code. And this CNI
its easily doable to create apps using Java classes. I dont think we should
put any work into this for now as I know no real world application doing
any use of this for now. When we have a real usecase we can think about
header generation and packaging.
Michael
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
Reply to: