Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: gcj compiled executable performance

Reply
Thread Tools

Re: gcj compiled executable performance

 
 
EJP
Guest
Posts: n/a
 
      03-29-2010
> I have never earlier tested gcj as I thought it was obsolete in its Java
> language support.


It is. It doesn't even support all of 1.2. It also doesn't support all
of 1.3, 1.4, 1.5, or 1.6, according to its own documentation. My guess
is that it never will. In any case there are too many well-known
incompatibilities between 'GNU CLASSPATH' and Java for anyone to
seriously mistake one for the other.

Don't do this.
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      03-29-2010
On 29-03-2010 02:45, EJP wrote:
>> I have never earlier tested gcj as I thought it was obsolete in its Java
>> language support.

>
> It is. It doesn't even support all of 1.2. It also doesn't support all
> of 1.3, 1.4, 1.5, or 1.6, according to its own documentation. My guess
> is that it never will. In any case there are too many well-known
> incompatibilities between 'GNU CLASSPATH' and Java for anyone to
> seriously mistake one for the other.


My understanding is that have improved over the last years.

But it is a 99% only compatibility project. Mono with .NET have
the same problem.

Arne
 
Reply With Quote
 
 
 
 
EJP
Guest
Posts: n/a
 
      03-30-2010
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.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-30-2010
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
 
Reply With Quote
 
EJP
Guest
Posts: n/a
 
      04-01-2010
On 31/03/2010 3:37 AM, Lew wrote:
> How is any given value of 'serialVersionUID' a required value?


Sorry, I forget the details, it was years ago, but it came up in a
support context, and it was a genuine problem. There are plenty of other
major incompatibilities. I had another one just yesterday with the GNU
RMI Registry being unable to accept a bind() call from a JRE. Removing
GNU fixed it, as it invariably does.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: gcj compiled executable performance Arne Vajh°j Java 7 04-04-2010 07:31 PM
Re: gcj compiled executable performance Roedy Green Java 1 03-28-2010 05:29 PM
If I create a page, then it's compiled upon first request, where cani find the compiled code?? lander ASP .Net 5 03-05-2008 04:34 PM
g++ compiled C++ code called from gcc compiled C code Klaus Schneider C++ 1 12-02-2004 01:44 PM
Re: Finding the full path of a c++ compiled executable in Visual C++ Josephine Schafer C++ 1 07-21-2003 09:44 AM



Advertisments