Re: gcj compiled executable performance

Discussion in 'Java' started by EJP, Mar 29, 2010.

  1. EJP

    EJP Guest

    > 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.
     
    EJP, Mar 29, 2010
    #1
    1. Advertising

  2. EJP

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Mar 30, 2010
    #2
    1. Advertising

  3. EJP

    EJP Guest

    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.
     
    EJP, Mar 30, 2010
    #3
  4. EJP

    Lew Guest

    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
     
    Lew, Mar 30, 2010
    #4
  5. EJP

    EJP Guest

    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.
     
    EJP, Apr 1, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Josephine Schafer
    Replies:
    1
    Views:
    3,631
    Philip Morley
    Jul 21, 2003
  2. Klaus Schneider
    Replies:
    1
    Views:
    582
    Rolf Magnus
    Dec 2, 2004
  3. lander
    Replies:
    5
    Views:
    625
    bruce barker
    Mar 5, 2008
  4. Arne Vajhøj
    Replies:
    7
    Views:
    1,004
    Paul Cager
    Apr 4, 2010
  5. Roedy Green
    Replies:
    1
    Views:
    406
    Arne Vajhøj
    Mar 28, 2010
Loading...

Share This Page