"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahlsqi$29sg$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ahgenb$rsj$1@digitaldaemon.com...
> > It's conservative. The source comes with the alpha compiler.
> Is it all in the the dmd/src/phobos/gc2 directory?

Yes.

"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahltg0$2aic$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ahgenb$rsj$1@digitaldaemon.com...
> > > > Symantec did the first JIT for Java.
> > > oops. I really wasn't sure. It was probably that ms had the fastest
jvm
> > > there for a while.
> > Well, no, Symantec's was faster, too <g>. (Microsoft had better
marketing,
> > though.)
> Probably a vicious rumour :-)

One of my educations in the power of marketing was a compiler roundup in a programming magazine a few eons ago. There was a nice neat table, with my compiler winning all the speed benchmarks. The text of the article concluded that Brand X's compiler was faster.

"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahltmr$2akd$1@digitaldaemon.com...
> You can call CreateWindowEx or whatever from Java. Just dot directly
> afaik. I think that Microsoft's Java implementation did allow you to do it
> more or less directly - via JDirect. That got them in trouble with Sun and
> hence we
> have C# and dotnet.

It's not just a matter of getting the calling conventions right to interface with a C function. Many, many C functions take and return structs. For Java this requires writing a marshaller and unmarshaller for the arguments. Then there's the problem of C functions returning multiple values, again requiring some arbitrary translation piece to deal with that. Add to that the issues of groups of C functions sharing some "handle" type that must somehow be converted too/from a Java type, C functions returning pointers to things that must be released with a call to free(), and things simply not representable in Java, such as returning a pointer to a memory mapped file.

None of these issues are any problem for D code to deal with.

"Walter" <walter@digitalmars.com> wrote in message news:ahnkef$14d6$1@digitaldaemon.com...
>
> "Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahltmr$2akd$1@digitaldaemon.com...
> > You can call CreateWindowEx or whatever from Java. Just dot directly afaik. I think that Microsoft's Java implementation did allow you to do
it
> > more or less directly - via JDirect. That got them in trouble with Sun
and
> > hence we
> > have C# and dotnet.
>
> It's not just a matter of getting the calling conventions right to
interface
> with a C function. Many, many C functions take and return structs. For
Java
> this requires writing a marshaller and unmarshaller for the arguments.
Then
> there's the problem of C functions returning multiple values, again requiring some arbitrary translation piece to deal with that. Add to that the issues of groups of C functions sharing some "handle" type that must somehow be converted too/from a Java type, C functions returning pointers
to
> things that must be released with a call to free(), and things simply not representable in Java, such as returning a pointer to a memory mapped
file.

Yep, I'm with you, Walter. This is what I think of as the data-sharing
problem.
Many languages provide a ffi but it's no good if you can just pass int,
long, float, double and
pointers. You need to be able to share data structures. I've seen a bit of
nasty jni code!

Please tell me more about C functions returning multiple values... oh I think you mean muliple "out" or "inout" parameters. ok.

I came across this problem one. I thought that we could replace a proprietary scripting language, I'll call Fudge, with Java. There existed much C and C++ code that already used Fudge values (a C union). This is what makes it difficult. There is no way to natively access those same values from Java. Needless to say, the replacement was never attempted. The increase in speed from Java just-in-time compilation would likely have been thwarted by the glue (marshall/unmarshall). The alternative of replacing the Fudge values with primitive Java values wasn't fully explored as much of the existing code relied in implementation details of the Fudge values.

>
> None of these issues are any problem for D code to deal with.

Great.

Regards, Steve.