public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Bill Chatfield via java" <java@gcc.gnu.org>
To: "'Andrew Haley'" <aph@redhat.com>,	"'mohan NMH'" <mohan.nmh2@gmail.com>
Cc: <java@gcc.gnu.org>
Subject: RE: Fwd: gcj can not import packages
Date: Mon, 16 Jan 2017 17:41:00 -0000	[thread overview]
Message-ID: <59a501d2701f$b1bb1290$153137b0$@yahoo.com> (raw)
In-Reply-To: <9335b6e8-ed7f-1e8d-4022-656da4681770@redhat.com>

I understand that OpenJDK is available as open source now, to "replace" gcj. But, gcj still has certain advantages that OpenJDK does not have:

1. gcj can compile to a native executable. OpenJDK cannot do this. It is a great feature for distributing programs that don't require a JRE to also exist on all the target machines. As a Java developer this is often a hurdle that cannot be overcome as there are users that absolutely refuse to install Java. It also makes it easier to invoke the application because running an executable is many times easier than running a Java program that requires a CLASSPATH setup and possibly other complex command line arguments to run properly. That kind of setup is beyond the ability of end-users. But running a single executable is not.

Compiling to a native executable may violate the intent of Java, but I don't really care. There are times when this is necessary. As a Java developer, most of the time you want to create .class files, but sometimes you really need a native executable.

2 gij is more memory efficient than OpenJDK at runtime. Gij may not execute programs as fast and the native executables generated by gcj might not be as fast as OpenJDK. But they're still faster than Python programs :-) and they use less memory than the standard OpenJDK JVM. This is again a great thing when you're targeting end users where memory usage is important, rather than corporate servers where it doesn't matter how much RAM you waste.

3. OpenJDK only supports a few platforms. It is very hard to get it to work on platforms besides the officially supported ones. But, gcj, being based on gcc is a lot more portable, allowing Java programs (if they're written to work with gcj) to run on a wider range of platforms. Case in point: my Mac PowerBook G4 with OSX 10.4.11. It has a good version of Java 1.5 from Apple, but if gcj were updated I wouldn't be stuck on an old version of Java. I understand my PowerBook is not much more than a toy at this point, but it does show the types of problems that gcj could solve on platforms that could be more important, like small devices for the "Internet of Things". OpenJDK really isn't even available on Windows as production product. But gcj could be.

Also, I feel that gcj was a great achievement on the part of the FSF and the open source community. It's nothing to be ashamed of. It shows the resourcefulness and ingenuity of the community.


-----Original Message-----
From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf Of Andrew Haley
Sent: Wednesday, November 09, 2016 8:30 AM
To: mohan NMH <mohan.nmh2@gmail.com>
Cc: java@gcc.gnu.org
Subject: Re: Fwd: gcj can not import packages

On 09/11/16 12:49, mohan NMH wrote:
> On Wed, Nov 9, 2016 at 5:55 PM, Andrew Haley <aph@redhat.com> wrote:
>> On 09/11/16 11:29, mohan NMH wrote:
>>> Can someone help me to understand why gcj can not import packages 
>>> while javac can? Any CLASSPATH setting required?
>>
>> java.util.Objects is Java 1.7.  gcj is at the level of 1.4 - 1.5.
> 
> Thanks Andrew. Could you please let me know what makes gcj at level of
> 1.4 - 1.5? Is it /usr/share/java/eclipse-ecj.jar?

It's the GCJ runtime library.

> Before this installation I tried with
> --with-ecj-jar=/usr/share/java/ecj4.4.jar. But the gcj failed to load 
> org.eclipse.jdt.internal.compiler.batch.GCCMain.class. The ecj4.4.jar 
> contains org.eclipse.jdt.internal.compiler.batch.Main.class while 
> eclipse-ecj.jar contains 
> org.eclipse.jdt.internal.compiler.batch.GCCMain.class. Therefore I 
> chose eclipse-ecj.jar
> 
> Please advise how to upgrade gcj to Java 1.8

It'd take a few programmer-years of work, I suspect.  Maybe one programmer could do it in a year, but that programmer would have to be very expert.

GCJ is obsolete and its sources have been deleted from GCC.

Andrew.



  reply	other threads:[~2017-01-16 17:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CANV4OqjehvrZUaMGbwn0Gu3KsesTy7aWVhY9cPETpnqwf_Zo0A@mail.gmail.com>
2016-11-09 11:29 ` mohan NMH
2016-11-09 12:26   ` Andrew Haley
2016-11-09 12:49     ` mohan NMH
2016-11-09 13:29       ` Andrew Haley
2017-01-16 17:41         ` Bill Chatfield via java [this message]
2017-01-16 20:10           ` Ricardo Wurmus
2017-01-16 22:58             ` Bill Chatfield via java
2017-01-16 23:24               ` Anthony Green
2017-01-17  9:56               ` Andrew Haley
2017-01-18 20:29                 ` Ricardo Wurmus
2017-01-18 20:40                   ` Matthias Klose
2017-01-18 20:59                     ` Ricardo Wurmus
2017-01-19  9:59                       ` Andrew Haley
     [not found]                         ` <CAFXTvn525N1D_EOuCAWXSJugCpZCZCkc5GfuhNJ1nPoDK0DAoQ@mail.gmail.com>
2017-05-17 20:26                           ` Ricardo Wurmus
2017-01-17  9:58           ` Andrew Haley
2017-01-17 15:21             ` Bill Chatfield via java

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='59a501d2701f$b1bb1290$153137b0$@yahoo.com' \
    --to=java@gcc.gnu.org \
    --cc=aph@redhat.com \
    --cc=bill.chatfield@yahoo.com \
    --cc=mohan.nmh2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).