From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47201 invoked by alias); 16 Jan 2017 17:41:10 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 47190 invoked by uid 89); 16 Jan 2017 17:41:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*java, toy, Things, 1.7 X-HELO: nm12-vm6.bullet.mail.ne1.yahoo.com Received: from nm12-vm6.bullet.mail.ne1.yahoo.com (HELO nm12-vm6.bullet.mail.ne1.yahoo.com) (98.138.91.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jan 2017 17:40:59 +0000 Received: from [98.138.226.176] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2017 17:40:57 -0000 Received: from [98.138.84.46] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jan 2017 17:40:57 -0000 Received: from [127.0.0.1] by smtp114.mail.ne1.yahoo.com with NNFMP; 16 Jan 2017 17:40:57 -0000 X-Yahoo-SMTP: xSRxJi2swBA2lXzwDXz5MgBBPUf2RZ69QvnX Reply-To: From: "Bill Chatfield via java" Reply-To: "Bill Chatfield" To: "'Andrew Haley'" , "'mohan NMH'" Cc: References: <9335b6e8-ed7f-1e8d-4022-656da4681770@redhat.com> In-Reply-To: <9335b6e8-ed7f-1e8d-4022-656da4681770@redhat.com> Subject: RE: Fwd: gcj can not import packages Date: Mon, 16 Jan 2017 17:41:00 -0000 Message-ID: <59a501d2701f$b1bb1290$153137b0$@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00000.txt.bz2 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 ex= ist 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 instal= l Java. It also makes it easier to invoke the application because running a= n 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 runni= ng 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 t= hey use less memory than the standard OpenJDK JVM. This is again a great th= ing 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 t= o work with gcj) to run on a wider range of platforms. Case in point: my Ma= c PowerBook G4 with OSX 10.4.11. It has a good version of Java 1.5 from App= le, 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 cou= ld be more important, like small devices for the "Internet of Things". Open= JDK really isn't even available on Windows as production product. But gcj c= ould be. Also, I feel that gcj was a great achievement on the part of the FSF and th= e open source community. It's nothing to be ashamed of. It shows the resour= cefulness and ingenuity of the community. -----Original Message----- From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf Of A= ndrew Haley Sent: Wednesday, November 09, 2016 8:30 AM To: mohan NMH 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 wrote: >> On 09/11/16 11:29, mohan NMH wrote: >>> Can someone help me to understand why gcj can not import packages=20 >>> while javac can? Any CLASSPATH setting required? >> >> java.util.Objects is Java 1.7. gcj is at the level of 1.4 - 1.5. >=20 > 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=3D/usr/share/java/ecj4.4.jar. But the gcj failed to load=20 > org.eclipse.jdt.internal.compiler.batch.GCCMain.class. The ecj4.4.jar=20 > contains org.eclipse.jdt.internal.compiler.batch.Main.class while=20 > eclipse-ecj.jar contains=20 > org.eclipse.jdt.internal.compiler.batch.GCCMain.class. Therefore I=20 > chose eclipse-ecj.jar >=20 > 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.