Fwd: gcj can not import packages

Fwd: gcj can not import packages

[mohan NMH]

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]$

Re: Fwd: gcj can not import packages

[Andrew Haley]

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.

Re: Fwd: gcj can not import packages

[mohan NMH]

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

Re: Fwd: gcj can not import packages

[Andrew Haley]

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.

RE: Fwd: gcj can not import packages

[Bill Chatfield via 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.

Re: Fwd: gcj can not import packages

[Ricardo Wurmus]

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

RE: Fwd: gcj can not import packages

[Bill Chatfield via 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

Re: Fwd: gcj can not import packages

[Anthony Green]

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
>
>

Re: Fwd: gcj can not import packages

[Andrew Haley]

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.

Re: Fwd: gcj can not import packages

[Andrew Haley]

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.

RE: Fwd: gcj can not import packages

[Bill Chatfield via 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.

Re: Fwd: gcj can not import packages

[Ricardo Wurmus]

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

Re: Fwd: gcj can not import packages

[Matthias Klose]

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

Re: Fwd: gcj can not import packages

[Ricardo Wurmus]

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

Re: Fwd: gcj can not import packages

[Andrew Haley]

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.

Re: Fwd: gcj can not import packages

[Ricardo Wurmus]

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