This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The problems with StringBuilders...


>>>>> "Adam" == Adam Megacz <megacz@gcc.gnu.org> writes:

>> ("we" == "the part of Red Hat working actively on gcj")

Adam> I have to say that, above all else, I'm quite grateful that such a
Adam> part exists.

Me too :-)

Adam> Interesting.  The fact that RedHat is willing to put nontrivial
Adam> resources into gcj, coupled with this particular choice of focus makes
Adam> me speculate on the goals: is RedHat interested in becoming less
Adam> dependent on Sun for Java support?  This would explain quite a bit.

I certainly can't speak for Red Hat.

It is plainly true that the only way to ship java applications in
Fedora is if there is a free VM on which to run them.

Adam> I'm skeptical about whether or not morphing gcj into a fully-fledged,
Adam> every-last-feature, TCK-compatible JVM is the best way to get this,
Adam> although it certainly does give you support for a huge number of
Adam> architectures "for free", which would be an insane amount of work
Adam> any other way.

I have some skepticism in this area too, but IMO gcj is the
front-runner when I look at the combination of platform support,
performance, and debuggability.  It also has the advantages that folks
at RH have a lot of experience working on it, and, as you said, we can
reuse all the work done on GCC back ends with little effort on our
part.  Finally, yeah, there is a possibility that we won't be able to
match JIT performance (say, for some important set of workloads); but
OTOH we haven't exactly reached gcj's limits either.  There are plenty
of unknowns, which in this case is good :-)

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]