* Fwd: gcj can not import packages [not found] <CANV4OqjehvrZUaMGbwn0Gu3KsesTy7aWVhY9cPETpnqwf_Zo0A@mail.gmail.com> @ 2016-11-09 11:29 ` mohan NMH 2016-11-09 12:26 ` Andrew Haley 0 siblings, 1 reply; 16+ messages in thread From: mohan NMH @ 2016-11-09 11:29 UTC (permalink / raw) To: java Can someone help me to understand why gcj can not import packages while javac can? Any CLASSPATH setting required? [user5@FOO-51 tmp]$ gcj -v Using built-in specs. Reading specs from /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig COLLECT_GCC=gcj COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --with-java-home=/usr/jdk1.8.0_111/jre/ --with-ecj-jar=/usr/share/java/eclipse-ecj.jar Thread model: posix gcc version 4.9.0 (GCC) [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ cat HelloWorld.java import java.util.Objects; import java.nio.file.*; import java.util.concurrent.CompletableFuture; import java.util.concurrent.CompletionStage; public class HelloWorld { public static void main (String[] args) { System.out.println ("Hello World!"); } } [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ echo $CLASSPATH [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ javac -version javac 1.8.0_111 [user5@FOO-51 tmp]$ javac HelloWorld.java [user5@FOO-51 tmp]$ java HelloWorld Hello World! [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ gcj --main=HelloWorld HelloWorld.class [user5@FOO-51 tmp]$ ./a.out Hello World! [user5@FOO-51 tmp]$ [user5@FOO-51 tmp]$ gcj --main=HelloWorld HelloWorld.java HelloWorld.java:1: error: The import java.util.Objects cannot be resolved import java.util.Objects; ^^^^^^^^^^^^^^^^^ HelloWorld.java:2: error: The import java.nio.file cannot be resolved import java.nio.file.*; ^^^^^^^^^^^^^ HelloWorld.java:3: error: The import java.util.concurrent.CompletableFuture cannot be resolved import java.util.concurrent.CompletableFuture; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ HelloWorld.java:4: error: The import java.util.concurrent.CompletionStage cannot be resolved import java.util.concurrent.CompletionStage; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 4 problems (4 errors) [user5@FOO-51 tmp]$ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2016-11-09 11:29 ` Fwd: gcj can not import packages mohan NMH @ 2016-11-09 12:26 ` Andrew Haley 2016-11-09 12:49 ` mohan NMH 0 siblings, 1 reply; 16+ messages in thread From: Andrew Haley @ 2016-11-09 12:26 UTC (permalink / raw) To: mohan NMH, java 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. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2016-11-09 12:26 ` Andrew Haley @ 2016-11-09 12:49 ` mohan NMH 2016-11-09 13:29 ` Andrew Haley 0 siblings, 1 reply; 16+ messages in thread From: mohan NMH @ 2016-11-09 12:49 UTC (permalink / raw) To: Andrew Haley; +Cc: java 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. > > Andrew. > > 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? 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2016-11-09 12:49 ` mohan NMH @ 2016-11-09 13:29 ` Andrew Haley 2017-01-16 17:41 ` Bill Chatfield via java 0 siblings, 1 reply; 16+ messages in thread From: Andrew Haley @ 2016-11-09 13:29 UTC (permalink / raw) To: mohan NMH; +Cc: java 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Fwd: gcj can not import packages 2016-11-09 13:29 ` Andrew Haley @ 2017-01-16 17:41 ` Bill Chatfield via java 2017-01-16 20:10 ` Ricardo Wurmus 2017-01-17 9:58 ` Andrew Haley 0 siblings, 2 replies; 16+ messages in thread From: Bill Chatfield via java @ 2017-01-16 17:41 UTC (permalink / raw) To: 'Andrew Haley', 'mohan NMH'; +Cc: java 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2017-01-16 17:41 ` Bill Chatfield via java @ 2017-01-16 20:10 ` Ricardo Wurmus 2017-01-16 22:58 ` Bill Chatfield via java 2017-01-17 9:58 ` Andrew Haley 1 sibling, 1 reply; 16+ messages in thread From: Ricardo Wurmus @ 2017-01-16 20:10 UTC (permalink / raw) To: Bill Chatfield; +Cc: 'Andrew Haley', 'mohan NMH', java Bill Chatfield via java <java@gcc.gnu.org> writes: > 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. [â¦] > > 2 gij is more memory efficient than OpenJDK at runtime. [â¦] > > 3. OpenJDK only supports a few platforms. [â¦] I would like to add one point: GCJ can be used to cleanly bootstrap the OpenJDK from source with a chain that starts with GCCâs C compiler, to GCJ, to OpenJDK 6 (via IcedTea). (The only wart is that later versions of GCJ rely on a pre-built jar of ecj.) This is why the bootstrappable builds project lists âMaintaining the GNU Compiler for Javaâ as a collaboration project.[1] [1]: http://bootstrappable.org/projects.html -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Fwd: gcj can not import packages 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 0 siblings, 2 replies; 16+ messages in thread From: Bill Chatfield via java @ 2017-01-16 22:58 UTC (permalink / raw) To: 'Ricardo Wurmus' Cc: 'Andrew Haley', 'mohan NMH', java From the link, it looks like it would be correct to say that gcj is the *only* open source way to bootstrap OpenJDK. -----Original Message----- From: Ricardo Wurmus [mailto:rekado@elephly.net] Sent: Monday, January 16, 2017 3:10 PM To: Bill Chatfield <bill_chatfield@yahoo.com> Cc: 'Andrew Haley' <aph@redhat.com>; 'mohan NMH' <mohan.nmh2@gmail.com>; java@gcc.gnu.org Subject: Re: Fwd: gcj can not import packages Bill Chatfield via java <java@gcc.gnu.org> writes: > 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. […] > > 2 gij is more memory efficient than OpenJDK at runtime. […] > > 3. OpenJDK only supports a few platforms. […] I would like to add one point: GCJ can be used to cleanly bootstrap the OpenJDK from source with a chain that starts with GCC’s C compiler, to GCJ, to OpenJDK 6 (via IcedTea). (The only wart is that later versions of GCJ rely on a pre-built jar of ecj.) This is why the bootstrappable builds project lists “Maintaining the GNU Compiler for Java” as a collaboration project.[1] [1]: http://bootstrappable.org/projects.html -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2017-01-16 22:58 ` Bill Chatfield via java @ 2017-01-16 23:24 ` Anthony Green 2017-01-17 9:56 ` Andrew Haley 1 sibling, 0 replies; 16+ messages in thread From: Anthony Green @ 2017-01-16 23:24 UTC (permalink / raw) To: bill.chatfield, Bill Chatfield Cc: Ricardo Wurmus, Andrew Haley, mohan NMH, java This is an interesting question... For the extremely security conscious, how can we build OpenJDK from source, assuming we have no trusted JDK? Can something simpler than gcj be used, like kaffe? AG On Mon, Jan 16, 2017 at 5:58 PM, Bill Chatfield via java <java@gcc.gnu.org> wrote: > From the link, it looks like it would be correct to say that gcj is the *only* open source way to bootstrap OpenJDK. > > -----Original Message----- > From: Ricardo Wurmus [mailto:rekado@elephly.net] > Sent: Monday, January 16, 2017 3:10 PM > To: Bill Chatfield <bill_chatfield@yahoo.com> > Cc: 'Andrew Haley' <aph@redhat.com>; 'mohan NMH' <mohan.nmh2@gmail.com>; java@gcc.gnu.org > Subject: Re: Fwd: gcj can not import packages > > > Bill Chatfield via java <java@gcc.gnu.org> writes: > >> 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. […] >> >> 2 gij is more memory efficient than OpenJDK at runtime. […] >> >> 3. OpenJDK only supports a few platforms. […] > > I would like to add one point: GCJ can be used to cleanly bootstrap the OpenJDK from source with a chain that starts with GCC’s C compiler, to GCJ, to OpenJDK 6 (via IcedTea). > > (The only wart is that later versions of GCJ rely on a pre-built jar of > ecj.) > > This is why the bootstrappable builds project lists “Maintaining the GNU Compiler for Java” as a collaboration project.[1] > > [1]: http://bootstrappable.org/projects.html > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 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 1 sibling, 1 reply; 16+ messages in thread From: Andrew Haley @ 2017-01-17 9:56 UTC (permalink / raw) To: bill.chatfield, 'Ricardo Wurmus'; +Cc: 'mohan NMH', java On 16/01/17 22:58, Bill Chatfield via java wrote: > From the link, it looks like it would be correct to say that gcj is > the *only* open source way to bootstrap OpenJDK. OpenJDK can bootstrap itself. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2017-01-17 9:56 ` Andrew Haley @ 2017-01-18 20:29 ` Ricardo Wurmus 2017-01-18 20:40 ` Matthias Klose 0 siblings, 1 reply; 16+ messages in thread From: Ricardo Wurmus @ 2017-01-18 20:29 UTC (permalink / raw) To: Andrew Haley; +Cc: bill.chatfield, 'mohan NMH', java Andrew Haley <aph@redhat.com> writes: > On 16/01/17 22:58, Bill Chatfield via java wrote: > >> From the link, it looks like it would be correct to say that gcj is >> the *only* open source way to bootstrap OpenJDK. > > OpenJDK can bootstrap itself. It can bootstrap only with pre-built binaries, though. The only route that doesnât involve these binaries is by using GCJ. I would be happy to be shown that this is a misunderstanding. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2017-01-18 20:29 ` Ricardo Wurmus @ 2017-01-18 20:40 ` Matthias Klose 2017-01-18 20:59 ` Ricardo Wurmus 0 siblings, 1 reply; 16+ messages in thread From: Matthias Klose @ 2017-01-18 20:40 UTC (permalink / raw) To: Ricardo Wurmus, Andrew Haley; +Cc: bill.chatfield, 'mohan NMH', java On 18.01.2017 21:28, Ricardo Wurmus wrote: > > Andrew Haley <aph@redhat.com> writes: > >> On 16/01/17 22:58, Bill Chatfield via java wrote: >> >>> From the link, it looks like it would be correct to say that gcj is >>> the *only* open source way to bootstrap OpenJDK. >> >> OpenJDK can bootstrap itself. > > It can bootstrap only with pre-built binaries, though. The only route > that doesnât involve these binaries is by using GCJ. > > I would be happy to be shown that this is a misunderstanding. yes, you need some trusted binaries. For example, there are various Linux distributions which provide these binaries. And even if you want to build for a target that doesn't have binaries, you can first build a native openjdk on your build platform, and then cross-build for your target. I built several Linux architectures this way ... Matthias ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2017-01-18 20:40 ` Matthias Klose @ 2017-01-18 20:59 ` Ricardo Wurmus 2017-01-19 9:59 ` Andrew Haley 0 siblings, 1 reply; 16+ messages in thread From: Ricardo Wurmus @ 2017-01-18 20:59 UTC (permalink / raw) To: Matthias Klose; +Cc: Andrew Haley, bill.chatfield, 'mohan NMH', java Matthias Klose <doko@ubuntu.com> writes: > yes, you need some trusted binaries. For example, there are various Linux > distributions which provide these binaries. And even if you want to build for a > target that doesn't have binaries, you can first build a native openjdk on your > build platform, and then cross-build for your target. I built several Linux > architectures this way ... The Bootstrappable Builds project[1] ties to remove the number of trusted binaries to bootstrap a modern system. One way to get there is to have a bootstrap path that leads to the unavoidable C compiler. And even the C compiler doesnât *have* to be a trusted binary. The Mes project[2] tries to build a C compiler using a minimal, hand-verifyable Scheme implementation, for example. I just find it sad to see GCJ go, because it makes it quite a bit harder to build the OpenJDK without a trusted JDK. Relying on the last release of GCC that included the GCJ sources isnât a viable long-term solution, because, as experience has shown, build systems of the past become unsupported and harder to satisfy as time passes. It is, for example, quite a challenge to build the GNU Pascal compiler (needed to bootstrap the self-hosted Freepascal compiler from source) from a decade back with a modern toolchain. [1]: http://bootstrappable.org [2]: https://gitlab.com/janneke/mes -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2017-01-18 20:59 ` Ricardo Wurmus @ 2017-01-19 9:59 ` Andrew Haley [not found] ` <CAFXTvn525N1D_EOuCAWXSJugCpZCZCkc5GfuhNJ1nPoDK0DAoQ@mail.gmail.com> 0 siblings, 1 reply; 16+ messages in thread From: Andrew Haley @ 2017-01-19 9:59 UTC (permalink / raw) To: Ricardo Wurmus, Matthias Klose; +Cc: bill.chatfield, 'mohan NMH', java On 18/01/17 20:59, Ricardo Wurmus wrote: > The Bootstrappable Builds project[1] ties to remove the number of > trusted binaries to bootstrap a modern system. One way to get there is > to have a bootstrap path that leads to the unavoidable C compiler. > > And even the C compiler doesnât *have* to be a trusted binary. The Mes > project[2] tries to build a C compiler using a minimal, hand-verifyable > Scheme implementation, for example. > > I just find it sad to see GCJ go, because it makes it quite a bit harder > to build the OpenJDK without a trusted JDK. It could be done with a chain of OpenJDK versions going back to OpenJDK 6. Each release can build the previous one. You'd also need a chain of old GCC releases, because old OpenJDK wasn't necessarily compilable with a modern GCC. But bear in mind that even GCJ needed precompiled binaries: the class library could be recompiled from source, but it needed a binary class library. So I'm not convinced that it's much of an advantage to use GCJ, really. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <CAFXTvn525N1D_EOuCAWXSJugCpZCZCkc5GfuhNJ1nPoDK0DAoQ@mail.gmail.com>]
* Re: Fwd: gcj can not import packages [not found] ` <CAFXTvn525N1D_EOuCAWXSJugCpZCZCkc5GfuhNJ1nPoDK0DAoQ@mail.gmail.com> @ 2017-05-17 20:26 ` Ricardo Wurmus 0 siblings, 0 replies; 16+ messages in thread From: Ricardo Wurmus @ 2017-05-17 20:26 UTC (permalink / raw) To: Andïï Cc: Andrew Haley, java, bill.chatfield, mohan NMH, Matthias Klose Andïï <gnu_andrew@member.fsf.org> writes: > On 19 Jan 2017 09:59, "Andrew Haley" <aph@redhat.com> wrote: > > On 18/01/17 20:59, Ricardo Wurmus wrote: >> The Bootstrappable Builds project[1] ties to remove the number of >> trusted binaries to bootstrap a modern system. One way to get there is >> to have a bootstrap path that leads to the unavoidable C compiler. >> >> And even the C compiler doesnât *have* to be a trusted binary. The Mes >> project[2] tries to build a C compiler using a minimal, hand-verifyable >> Scheme implementation, for example. >> >> I just find it sad to see GCJ go, because it makes it quite a bit harder >> to build the OpenJDK without a trusted JDK. > > It could be done with a chain of OpenJDK versions going back to > OpenJDK 6. Each release can build the previous one. You'd also > need a chain of old GCC releases, because old OpenJDK wasn't > necessarily compilable with a modern GCC. > > > Currently, it's possible to go from GCJ 6.2 straight to building OpenJDK 7 > with IcedTea 2.x. There's no need to involve OpenJDK 6 unless needed. > > > But bear in mind that even GCJ needed precompiled binaries: the > class library could be recompiled from source, but it needed a > binary class library. So I'm not convinced that it's much of an > advantage to use GCJ, really. > > > Exactly. There's nothing particular to GCJ that makes it more amenable to > bootstrapping. It just happened to contain pre-built class files and be > part of the compiler collection that was already being built to provide C > and C++ compilers. Lack of development in recent years has meant we've had > to work around a number of issues with it in IcedTea. Thank you for this comment. I really wasnât aware of the fact that the GCC sources bundled pre-built class files. In the past few days Iâve experimented with a clean bootstrap from source with GNU Guix and it looks like itâs possible. Unfortunately, it does depend on unmaintained software (such as sablevm, jamvm, and an older version of ECJ), and it would be great if the parts that are needed for a from-source bootstrap would eventually make it into IcedTea. The resulting patches for Guix, which demonstrate the bootstrap chain are shown here: http://lists.gnu.org/archive/html/guix-patches/2017-05/msg00942.html (I may add a full write-up later and publish it at http://bootstrappable.org.) > Going forward, my intention is to make IcedTea self-sufficient by using > pre-compiled class files in the same manner as GCJ. This should make > bootstrapping easier in the long run. Unfortunately, bootstrapping from binaries is not desirable for most distributions of the GNU system. Ideally, there would be an optional interpreter written in some language other than Java that would be just sufficient to interpret enough of Java to compile a first stage. This is what GNU Guile does. Admittedly, this might be a considerably more challenging task for the JDK. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Fwd: gcj can not import packages 2017-01-16 17:41 ` Bill Chatfield via java 2017-01-16 20:10 ` Ricardo Wurmus @ 2017-01-17 9:58 ` Andrew Haley 2017-01-17 15:21 ` Bill Chatfield via java 1 sibling, 1 reply; 16+ messages in thread From: Andrew Haley @ 2017-01-17 9:58 UTC (permalink / raw) To: bill.chatfield, 'mohan NMH'; +Cc: java On 16/01/17 17:40, Bill Chatfield via java wrote: > > 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. Well, yeah, but it'd take a lot of work to maintain GCJ. And unmaintained software is a major liability. For anyone who needs GCJ, its old sources are not going to disappear. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: Fwd: gcj can not import packages 2017-01-17 9:58 ` Andrew Haley @ 2017-01-17 15:21 ` Bill Chatfield via java 0 siblings, 0 replies; 16+ messages in thread From: Bill Chatfield via java @ 2017-01-17 15:21 UTC (permalink / raw) To: 'Andrew Haley', bill.chatfield, 'mohan NMH'; +Cc: java OK, then I'm going to fork it to github and someday gcj is going to overtake gcc and g++. Haha. :-) Actually, I'll be lucky if I can get it to compile. My previous attempts have all failed. I can get a working gcc and g++, but gcj never succeeds for me. It takes several days to get through just one iteration of the preliminary gcc build on my PowerBook G4 before it fails. I'd probably be better off to run a cross compile on my i5 Fedora machine to get a version for my PowerBook G4. I could probably pull the old Fedora source rpm as a starting point to get the right configuration parameters. I think it's the missing gcj dependencies that always cause the failures. I've never gotten a successful compile of gcj on Windows either. I've tried using other people's configure parameters, but they're always for a different version of gcc/gcj than what I'm trying to compile and they don't work. -----Original Message----- From: Andrew Haley [mailto:aph@redhat.com] Sent: Tuesday, January 17, 2017 4:59 AM To: bill.chatfield@yahoo.com; 'mohan NMH' <mohan.nmh2@gmail.com> Cc: java@gcc.gnu.org Subject: Re: Fwd: gcj can not import packages On 16/01/17 17:40, Bill Chatfield via java wrote: > > 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. Well, yeah, but it'd take a lot of work to maintain GCJ. And unmaintained software is a major liability. For anyone who needs GCJ, its old sources are not going to disappear. Andrew. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-05-17 20:26 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CANV4OqjehvrZUaMGbwn0Gu3KsesTy7aWVhY9cPETpnqwf_Zo0A@mail.gmail.com> 2016-11-09 11:29 ` Fwd: gcj can not import packages 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 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
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).