On Mon, May 02, 2005 at 11:24:32AM +0200, Arnaud Vandyck wrote: > Sat, 30 Apr 2005 23:39:00 +0200, > Mark Wielaard <[EMAIL PROTECTED]> 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
