OpenJDK support

OpenJDK support

[Pjotr Prins]

To support the JVM we'll need to add the openjdk.

Having a look at it I think it is doable. Only problem is that the
java compiler needs to be bootstrapped with itself. 

In Nix they create a binary blob to bootstrap:

    let
      # !!! These should be on nixos.org
      src = if glibc.system == "x86_64-linux" then
        fetchurl {
          url = http://tarballs.nixos.org/openjdk-bootstrap-x86_64-linux-2012-08-2
    4.tar.xz;
          sha256 = "0gla9dxrfq2w1hvgsnn8jg8a60k27im6z43a6iidi0qmwa0wah32";
        }
      else if glibc.system == "i686-linux" then
        fetchurl {
          url = http://tarballs.nixos.org/openjdk-bootstrap-i686-linux-2012-08-24.
    tar.xz;
          sha256 = "184wq212bycwbbq4ix8cc6jwjxkrqw9b01zb86q95kqpa8zy5206";
        }
      else throw "No bootstrap for system";
    in

How do we go about this one?

Pj.

Re: OpenJDK support

[Ricardo Wurmus]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> To support the JVM we'll need to add the openjdk.
>
> Having a look at it I think it is doable. Only problem is that the
> java compiler needs to be bootstrapped with itself. 
>
> In Nix they create a binary blob to bootstrap:
>
>     let
>       # !!! These should be on nixos.org
>       src = if glibc.system == "x86_64-linux" then
>         fetchurl {
>           url = http://tarballs.nixos.org/openjdk-bootstrap-x86_64-linux-2012-08-2
>     4.tar.xz;
>           sha256 = "0gla9dxrfq2w1hvgsnn8jg8a60k27im6z43a6iidi0qmwa0wah32";
>         }
>       else if glibc.system == "i686-linux" then
>         fetchurl {
>           url = http://tarballs.nixos.org/openjdk-bootstrap-i686-linux-2012-08-24.
>     tar.xz;
>           sha256 = "184wq212bycwbbq4ix8cc6jwjxkrqw9b01zb86q95kqpa8zy5206";
>         }
>       else throw "No bootstrap for system";
>     in
>
> How do we go about this one?


We already have a JDK provided by the “jdk” output of the “icedtea”
packages.  “IcedTea” is the name of the project that provides a heavily
patched framework allowing us to build the (patched) OpenJDK sources
with free software only.  Building the vanilla OpenJDK appparently isn’t
that easy – and not really necessary since we have the IcedTea-ified
version.

We are bootstrapping with GCJ.

~~ Ricardo

Re: OpenJDK support

[Ludovic Courtès]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> To support the JVM we'll need to add the openjdk.
>>
>> Having a look at it I think it is doable. Only problem is that the
>> java compiler needs to be bootstrapped with itself. 
>>
>> In Nix they create a binary blob to bootstrap:
>>
>>     let
>>       # !!! These should be on nixos.org
>>       src = if glibc.system == "x86_64-linux" then
>>         fetchurl {
>>           url = http://tarballs.nixos.org/openjdk-bootstrap-x86_64-linux-2012-08-2
>>     4.tar.xz;
>>           sha256 = "0gla9dxrfq2w1hvgsnn8jg8a60k27im6z43a6iidi0qmwa0wah32";
>>         }
>>       else if glibc.system == "i686-linux" then
>>         fetchurl {
>>           url = http://tarballs.nixos.org/openjdk-bootstrap-i686-linux-2012-08-24.
>>     tar.xz;
>>           sha256 = "184wq212bycwbbq4ix8cc6jwjxkrqw9b01zb86q95kqpa8zy5206";
>>         }
>>       else throw "No bootstrap for system";
>>     in
>>
>> How do we go about this one?
>
>
> We already have a JDK provided by the “jdk” output of the “icedtea”
> packages.  “IcedTea” is the name of the project that provides a heavily
> patched framework allowing us to build the (patched) OpenJDK sources
> with free software only.  Building the vanilla OpenJDK appparently isn’t
> that easy – and not really necessary since we have the IcedTea-ified
> version.
>
> We are bootstrapping with GCJ.

And kudos to you Ricardo for doing the right thing.  It’s much more
confidence-inspiring than the above snippet.  :-)

Ludo’.

Re: OpenJDK support

[Pjotr Prins]

On Mon, Feb 08, 2016 at 04:22:25PM +0100, Ludovic Courtès wrote:
> > We are bootstrapping with GCJ.
> 
> And kudos to you Ricardo for doing the right thing.  It’s much more
> confidence-inspiring than the above snippet.  :-)

Yes, it is very impressive in fact. Of course the journey starts here.

Maven provides similar functionality as rubygems, e.g.

  http://mvnrepository.com/artifact/junit/junit

this could mean we can write an import command that fetches 
dependency info from maven.

It looks like we can tell maven to find jars on the local 
system. Jars we have built already. So we can use it as a 
build system. I think that is a prerequisite.

Even so, getting all these jars built is going to be quite a job...

Pj.
-- 

Re: OpenJDK support

[Ricardo Wurmus]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Mon, Feb 08, 2016 at 04:22:25PM +0100, Ludovic Courtès wrote:
>> > We are bootstrapping with GCJ.
>> 
>> And kudos to you Ricardo for doing the right thing.  It’s much more
>> confidence-inspiring than the above snippet.  :-)
>
> Yes, it is very impressive in fact. Of course the journey starts here.
>
> Maven provides similar functionality as rubygems, e.g.
>
>   http://mvnrepository.com/artifact/junit/junit
>
> this could mean we can write an import command that fetches 
> dependency info from maven.

Yes, I’ve been thinking about this too.  It seems that we could get
dependency information from pom.xml files, though I’m not sure how we
can canonicalise names.  It seems that what matters to Maven is the
identifier of binary artifacts on the central Maven repository.  I don’t
know how this is derived and if the name of the library is used at all.

> It looks like we can tell maven to find jars on the local 
> system. Jars we have built already. So we can use it as a 
> build system. I think that is a prerequisite.

Yes.  I have no experience with Maven, but it is crucial that we can
tell it use what’s already in the store.  I do not know if this is
possible as we rebuild jars and thus the binary artifacts probably
differ from what Maven might expect.  We would have to figure out what
Maven’s expectations really are and how we can satisfy them without
using binaries from the central Maven repository.

> Even so, getting all these jars built is going to be quite a job...

I’ve already built a couple of jars that we need for a working Maven
with a preliminary ant-build-system.  I welcome contributions on this
end, because I’m not familiar enough with the unwritten assumptions of
Java libraries and systems.

I’ll update the ant-build-system soon and then submit a couple of
patches for libraries needed to build Maven from source (without having
to use a bootstrap Maven that’s automatically downloaded when building
Maven with Ant).

~~ Ricardo