Prev: VDC is Interested in Your Engineering Experiences
Next: Writing jnlp program for both sandbox and all-permissions
From: EJP on 30 Mar 2010 00:22
On 30/03/2010 10:56 AM, Arne Vajh�j wrote:
> My understanding is that have improved over the last years.

I've seen no evidence of that. I am constantly running across support
cases that are cured completely by simply removing 'GNU CLASSPATH'.

> But it is a 99% only compatibility project.

99% is putting it far too high. 80% would be pretty strong, and some of
the incompatibilities are fundamental, e.g. the serialVersionUID of
java.lang.Object, and jni.h not conforming to the JNI specification.
From: Lew on 30 Mar 2010 12:37
EJP wrote:
> 99% is putting it far too high. 80% would be pretty strong, and some of
> the incompatibilities are fundamental, e.g. the serialVersionUID of
> java.lang.Object, and jni.h not conforming to the JNI specification.

How is any given value of 'serialVersionUID' a required value,
especially as 'Object' itself does not implement 'Serializable'?

It is not a compatibility violation for one version of Java to assign
different default 'serialVersionUID' values from another. Heck, even
Sun's own releases are not required to maintain that degree of
compatibility.

--
Lew
From: Paul Cager on 31 Mar 2010 08:47
On Mar 30, 12:57 am, Arne Vajhøj <a...(a)vajhoej.dk> wrote:
> On 29-03-2010 11:25, Paul Cager wrote:
>
> > On Mar 27, 12:18 am, Arne Vajhøj<a...(a)vajhoej.dk>  wrote:
> >> Performance is not a reason to pick GCJ.
>
> >> BTW, I don't know of any reason.
>
> > On some architectures (such as ARM) it is still the best choice.
>
> What are the alternatives?
>
> Arne

It's a while since I looked, but they all involved paying money.... :(
From: Lew on 31 Mar 2010 15:42
Paul Cager wrote:
>>> On some architectures (such as ARM) it [GCJ] is still the best choice.
>

Arne Vajhøj wrote:
>> What are the alternatives?
>

Paul Cager wrote:
> It's a while since I looked, but they all involved paying money.... :(
>

Communist!

Seriously (and that was a joke, btw), money isn't a Bad Thing. Some
things are worth what you pay for them, and that goes for some free
things, too.

Ergo you have not answered the question of what makes GCJ the best
choice for ARM architectures, nor what the alternatives are.

Suppose (and I don't know what the facts are here) that Brand X JVM
for ARM costs some money and Brand Y is free, but that Brand Y is
insufficient to the task due to incompatibilities, incomplete
implementation or some other difficulty. Brand Y would not be the
best choice.

I am interested in the answers to Arne's questions as well - what are
the reasons, if any, to pick GCJ over the alternatives, and what are
the alternatives?

--
Lew
From: Arne Vajhøj on 31 Mar 2010 19:37
On 31-03-2010 15:42, Lew wrote:
> Paul Cager wrote:
>>>> On some architectures (such as ARM) it [GCJ] is still the best choice.
>>
>
> Arne Vajh�j wrote:
>>> What are the alternatives?
>
> Paul Cager wrote:
>> It's a while since I looked, but they all involved paying money.... :(
>
> Communist!

It is the very essence of capitalism to pay the least possible.

> Seriously (and that was a joke, btw), money isn't a Bad Thing. Some
> things are worth what you pay for them, and that goes for some free
> things, too.
>
> Ergo you have not answered the question of what makes GCJ the best
> choice for ARM architectures, nor what the alternatives are.
>
> Suppose (and I don't know what the facts are here) that Brand X JVM
> for ARM costs some money and Brand Y is free, but that Brand Y is
> insufficient to the task due to incompatibilities, incomplete
> implementation or some other difficulty. Brand Y would not be the
> best choice.
>
> I am interested in the answers to Arne's questions as well - what are
> the reasons, if any, to pick GCJ over the alternatives, and what are
> the alternatives?

I think he has.

He likes the price tag.

Arne

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: VDC is Interested in Your Engineering Experiences
Next: Writing jnlp program for both sandbox and all-permissions