Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

Yeah.  There's a couple tickets that could probably be subsumed by a new
one.  I'll have a look.

On Thu, Jun 16, 2022 at 8:04 PM Gilles Sadowski 
wrote:

> Hello.
>
> Le jeu. 16 juin 2022 à 19:36, Alex Remily  a écrit
> :
> >
> > Do you think we could simply use CRYPTO-120
> > ?
>
> Maybe.
> Or open a new one with an up-to-date description,
> and signal that it replaces old/obsolete reports...
>
> Gilles
>
> > On Thu, Jun 16, 2022 at 1:31 PM Gilles Sadowski 
> > wrote:
> >
> > > Hello.
> > >
> > > Since there is an issue to be solved, could you file a report on JIRA?
> > > [And post there patches or new files, and instructions.]
> > >
> > > Thanks,
> > > Gilles
> > >
> > > Le jeu. 16 juin 2022 à 19:18, Alex Remily  a
> écrit
> > > :
> > > >
> > > > I just ran [2], and whatever it does, it doesn't appear to do a
> build of
> > > > commons-crypto.  I'd appreciate it if any developers who have the
> time
> > > > would take a look at the dockerfile here:
> > > >
> > > > https://github.com/aremily/commons-crypto
> > > >
> > > > If you're copying the dockerfile into your own fork, you'll need the
> > > > makefile.common file as well.
> > > >
> > > > Alex
> > > >
> > > > On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann <
> > > jochen.wiedm...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> > > > >
> > > > > > [1] src/docker/Dockerfile
> > > > > > [2] src/conf/Docker/Dockerfile-luw
> > > > >
> > > > > Have to admit, that I wasn't aware of [2], when I created [1].
> Mine is
> > > > > incomplete, and can easily be removed. Was basically just an
> attempt
> > > > > to reproduce the build instructions in the hope, that others would
> > > > > verify, and fix my errors.
> > > > >
> > > > > Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Gilles Sadowski]

Hello.

Le jeu. 16 juin 2022 à 19:36, Alex Remily  a écrit :
>
> Do you think we could simply use CRYPTO-120
> ?

Maybe.
Or open a new one with an up-to-date description,
and signal that it replaces old/obsolete reports...

Gilles

> On Thu, Jun 16, 2022 at 1:31 PM Gilles Sadowski 
> wrote:
>
> > Hello.
> >
> > Since there is an issue to be solved, could you file a report on JIRA?
> > [And post there patches or new files, and instructions.]
> >
> > Thanks,
> > Gilles
> >
> > Le jeu. 16 juin 2022 à 19:18, Alex Remily  a écrit
> > :
> > >
> > > I just ran [2], and whatever it does, it doesn't appear to do a build of
> > > commons-crypto.  I'd appreciate it if any developers who have the time
> > > would take a look at the dockerfile here:
> > >
> > > https://github.com/aremily/commons-crypto
> > >
> > > If you're copying the dockerfile into your own fork, you'll need the
> > > makefile.common file as well.
> > >
> > > Alex
> > >
> > > On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann <
> > jochen.wiedm...@gmail.com>
> > > wrote:
> > >
> > > > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> > > >
> > > > > [1] src/docker/Dockerfile
> > > > > [2] src/conf/Docker/Dockerfile-luw
> > > >
> > > > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > > > incomplete, and can easily be removed. Was basically just an attempt
> > > > to reproduce the build instructions in the hope, that others would
> > > > verify, and fix my errors.
> > > >
> > > > Jochen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Crypto] What is it ?

[sebb]

On Thu, 16 Jun 2022 at 22:07, Alex Remily  wrote:
>
> sebb,
>
> Thanks for taking the time to test it out and provide feedback.  Much
> appreciated.  My thoughts below.
>
>  container and it's not obvious how to extract it.>
>
> Good point.  I could modify the script to dump the final artifact in the
> project root directory.

It would still have to be copied back to the host somehow.

>  a new version is released (e.g. 3.6.4) the link will break.>
>
> That link is static to that release and won't change with new updates.  The
> directory structure maintains the version history:
>
> https://downloads.apache.org/maven/maven-3/

I'm not sure that is true.

If there are no more 3.6.x releases, then it probably will remain for
a while, but in theory old releases will eventually be removed from
the download directory and will only be available from the archives.

Note that the src/docker/Dockerfile from Jochen downloads Maven 3.8.5
- that no longer works as it has already been replaced by 3.8.6.

Also, that host is not supposed to be used for public downloads;
should use dlcdn.apache.org instead.

>  required software has been installed, rather than continuing to build the
> code.>
>
> That's the approach Gary took for the last release, and it's an open
> question that I've posed to the community via another thread.  My
> inclination is to do both.  Have one dockerfile that builds the
> environment, and another that builds the artifact.

That more than doubles the space requirement.

>  source; at present the source is built-in.>
>
> Actually the source is copied in from the host.  See "COPY .
> /commons-crypto".

Exactly; once the build is created it contains a fixed copy of the source.

The build has to be partially redone for every change to the source.
Whereas a virtual mount will pick up changes automatically.

>  object and generate the release.>
>
> Agreed.  The Mac is the only build that can't be cross-compiled.  I think
> it was Matt who noted on another thread that AWS offers MacVMs, which I
> think is a promising route.

Maybe; depends on whether ASF allows 3rd party builds to be published.

> Thanks again for taking the time to provide feedback.
>
> Alex
>
>
> On Thu, Jun 16, 2022 at 2:48 PM sebb  wrote:
>
> > On Thu, 16 Jun 2022 at 18:21, Alex Remily  wrote:
> > >
> > > Forwarding to the community dev list. Didn't realize it was dropped along
> > > the way.
> > >
> > > Alex
> > >
> > > -- Forwarded message -
> > > From: Alex Remily 
> > > Date: Thu, Jun 16, 2022 at 1:01 PM
> > > Subject: Re: [Crypto] What is it ?
> > > To: Jochen Wiedmann 
> > >
> > >
> > > Jochen,
> > >
> > > Please give my attempt at a docker build a try.  Copy the dockerfile and
> > > the makefile.common file from the project directory at the link below
> > into
> > > your own project directory and try doing a "docker build . -t
> > yourtagname"
> > > from the project directory. The makefile.common is required because there
> > > was a minor syntax error in the build args for the linux-arm build ("/"
> > > omitted after JAVA_HOME) that caused the directory to resolve
> > improperly).
> > > Alternatively, you may be able to check out my fork and build it
> > directly;
> > > I'm not sure what the repo permissions allow.
> > >
> > > https://github.com/aremily/commons-crypto
> > >
> > > The dockerfile builds and tests the linux x86_64 build on Ubuntu 14.04
> > and
> > > cross compiles the remaining builds.  Note that I've omitted the Win32
> > > build because I don't think anyone in the world uses 32 bit Windows
> > > anymore, and the script itself can't do the Mac build (perhaps it's
> > > possible to cross-compile for the Mac, but I lack the motivation to find
> > > out at this point).  The workaround to perform a build that includes the
> > > Mac is to perform Maven build on a Mac and then run the docker build.
> > > Docker will copy the output of the Mac build into the container and
> > bundle
> > > it into the final artifact.
> > >
> > > Please provide feedback.  If it works, I'll update the build
> > documentation
> > > and submit a PR to close out CRYPTO-120
> > > .
> > >
> >
> > It works for me using Docker on macOS, though the output is in the
> > container and it's not obvious how to extract it.
> >
> > I think it would be advisable to install Maven as a separate run step;
> > if a new version is released (e.g. 3.6.4) the link will break.
> > Ideally install the changeable items as separate steps, with the most
> > volatile last to avoid rebuilds.
> >
> > Also I wonder if it would make sense to stop the build once all the
> > required software has been installed, rather than continuing to build
> > the code.
> >
> > This would make it easier to re-use the container with an updated
> > crypto source; at present the source is built-in.
> > This would require mapping the host source tree to the container; it
> > would have the advantage that the output would 

Re: [Crypto] What is it ?

[Alex Remily]

sebb,

Thanks for taking the time to test it out and provide feedback.  Much
appreciated.  My thoughts below.



Good point.  I could modify the script to dump the final artifact in the
project root directory.



That link is static to that release and won't change with new updates.  The
directory structure maintains the version history:

https://downloads.apache.org/maven/maven-3/



That's the approach Gary took for the last release, and it's an open
question that I've posed to the community via another thread.  My
inclination is to do both.  Have one dockerfile that builds the
environment, and another that builds the artifact.



Actually the source is copied in from the host.  See "COPY .
/commons-crypto".



Agreed.  The Mac is the only build that can't be cross-compiled.  I think
it was Matt who noted on another thread that AWS offers MacVMs, which I
think is a promising route.

Thanks again for taking the time to provide feedback.

Alex


On Thu, Jun 16, 2022 at 2:48 PM sebb  wrote:

> On Thu, 16 Jun 2022 at 18:21, Alex Remily  wrote:
> >
> > Forwarding to the community dev list. Didn't realize it was dropped along
> > the way.
> >
> > Alex
> >
> > -- Forwarded message -
> > From: Alex Remily 
> > Date: Thu, Jun 16, 2022 at 1:01 PM
> > Subject: Re: [Crypto] What is it ?
> > To: Jochen Wiedmann 
> >
> >
> > Jochen,
> >
> > Please give my attempt at a docker build a try.  Copy the dockerfile and
> > the makefile.common file from the project directory at the link below
> into
> > your own project directory and try doing a "docker build . -t
> yourtagname"
> > from the project directory. The makefile.common is required because there
> > was a minor syntax error in the build args for the linux-arm build ("/"
> > omitted after JAVA_HOME) that caused the directory to resolve
> improperly).
> > Alternatively, you may be able to check out my fork and build it
> directly;
> > I'm not sure what the repo permissions allow.
> >
> > https://github.com/aremily/commons-crypto
> >
> > The dockerfile builds and tests the linux x86_64 build on Ubuntu 14.04
> and
> > cross compiles the remaining builds.  Note that I've omitted the Win32
> > build because I don't think anyone in the world uses 32 bit Windows
> > anymore, and the script itself can't do the Mac build (perhaps it's
> > possible to cross-compile for the Mac, but I lack the motivation to find
> > out at this point).  The workaround to perform a build that includes the
> > Mac is to perform Maven build on a Mac and then run the docker build.
> > Docker will copy the output of the Mac build into the container and
> bundle
> > it into the final artifact.
> >
> > Please provide feedback.  If it works, I'll update the build
> documentation
> > and submit a PR to close out CRYPTO-120
> > .
> >
>
> It works for me using Docker on macOS, though the output is in the
> container and it's not obvious how to extract it.
>
> I think it would be advisable to install Maven as a separate run step;
> if a new version is released (e.g. 3.6.4) the link will break.
> Ideally install the changeable items as separate steps, with the most
> volatile last to avoid rebuilds.
>
> Also I wonder if it would make sense to stop the build once all the
> required software has been installed, rather than continuing to build
> the code.
>
> This would make it easier to re-use the container with an updated
> crypto source; at present the source is built-in.
> This would require mapping the host source tree to the container; it
> would have the advantage that the output would end up on the host.
>
> If the host was macOS, I assume that could then be used to build the
> Mac object and generate the release.
> It's going to be easier to upload the release from the host rather
> than the container.
>
> > Alex
> >
> > On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > Hi, Alex,
> > >
> > > ideally, I would like to have a variant of the current Dockerfile,
> > > that builds a jar file with all the binaries included. If we would
> > > have that, then we could use it to build a release.
> > >
> > > Thanks,
> > >
> > > Jochen
> > >
> > > On Tue, Jun 14, 2022 at 11:22 PM Alex Remily 
> > > wrote:
> > > >
> > > > Sure.  Happy to help.  I'll try to get to it this week.  I haven't
> been
> > > in the code for more than a year, so please be patient as I come back
> up to
> > > speed.  What exactly do you need help with?  Building the jar via the
> > > docker file?
> > > >
> > > > Alex
> > > >
> > > > On Tue, Jun 14, 2022 at 3:15 PM Jochen Wiedmann <
> > > jochen.wiedm...@gmail.com> wrote:
> > > >>
> > > >> Hi, Alex,
> > > >>
> > > >> On Tue, Jun 14, 2022 at 4:38 PM Alex Remily 
> > > wrote:
> > > >> > appropriately.  There is a Docker file currently in the
> repository,
> > > used
> > > >> > for the 1.1 release, that manages the cross-compilation for the
> JNI
> > > >> > libraries and packages 

Re: [Crypto] What is it ?

[sebb]

On Thu, 16 Jun 2022 at 21:47, Alex Remily  wrote:
>
> I think that's a great idea, assuming as Gary pointed out that using a
> MacVM for the build is legal (and I can't imagine AWS offering that service
> if it wasn't).

But is it OK to build ASF releases on GH rather than developer systems?

> Use the MacVM as the host OS.  Run the Mac build locally,
> then run the dockerfile for the balance of the builds.  The Windows and
> Linux builds can be cross-compiled.

How about the opposite way round:
- start the Ubuntu container with a virtual mount of the host workspace
- (possibly also mount the Maven repo to save downloads)
- run the cross-compile builds; these will end up in the host workspace
- finish the release packaging on the Mac

If we ever find a way to cross-compile the Mac code under Ubuntu, then
the host could be any OS that runs Docker.

> On Thu, Jun 16, 2022 at 3:51 PM Matt Sicker  wrote:
>
> > AWS offers macOS VMs. GitHub Actions support macOS which presumably uses
> > something similar. I don’t think Apple offers an equivalent service, but
> > there are more companies that do offer macOS VMs in the cloud.
> >
> > —
> > Matt Sicker
> >
> > > On Jun 16, 2022, at 12:05, Jochen Wiedmann 
> > wrote:
> > >
> > > On Wed, Jun 15, 2022 at 6:33 PM Matt Sicker  wrote:
> > >>
> > >> We could always request a Windows VM from Infra if necessary for
> > building releases. Same for a Mac VM or Linux VM, though the Linux one can
> > be done fairly easily via Docker on any OS (even FreeBSD supports Linux
> > containers now).
> > >
> > > Didn't know, that MacOS VM's even exist. Seems like overkill, tohave
> > > one, or even, two VM's just for a minor component, like Crypto. But
> > > imagine such a VM, and a Jenkins agent/server running on it, which
> > > could be used by all projects?
> > >
> > > Jochen
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Crypto] What is it ?

[Alex Remily]

I think that's a great idea, assuming as Gary pointed out that using a
MacVM for the build is legal (and I can't imagine AWS offering that service
if it wasn't).  Use the MacVM as the host OS.  Run the Mac build locally,
then run the dockerfile for the balance of the builds.  The Windows and
Linux builds can be cross-compiled.

On Thu, Jun 16, 2022 at 3:51 PM Matt Sicker  wrote:

> AWS offers macOS VMs. GitHub Actions support macOS which presumably uses
> something similar. I don’t think Apple offers an equivalent service, but
> there are more companies that do offer macOS VMs in the cloud.
>
> —
> Matt Sicker
>
> > On Jun 16, 2022, at 12:05, Jochen Wiedmann 
> wrote:
> >
> > On Wed, Jun 15, 2022 at 6:33 PM Matt Sicker  wrote:
> >>
> >> We could always request a Windows VM from Infra if necessary for
> building releases. Same for a Mac VM or Linux VM, though the Linux one can
> be done fairly easily via Docker on any OS (even FreeBSD supports Linux
> containers now).
> >
> > Didn't know, that MacOS VM's even exist. Seems like overkill, tohave
> > one, or even, two VM's just for a minor component, like Crypto. But
> > imagine such a VM, and a Jenkins agent/server running on it, which
> > could be used by all projects?
> >
> > Jochen
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: [Crypto] What is it ?

[sebb]

Could the native bits be extracted from the various GH builds and used
to pre-populate the release build?

Would that be allowed, given that builds are normally done on developer systems?

Sebb
On Thu, 16 Jun 2022 at 21:25, Gary Gregory  wrote:
>
> Sure, but we are not quite set up for releasing from GH, soon maybe...
>
> On Thu, Jun 16, 2022, 15:51 Matt Sicker  wrote:
>
> > AWS offers macOS VMs. GitHub Actions support macOS which presumably uses
> > something similar. I don’t think Apple offers an equivalent service, but
> > there are more companies that do offer macOS VMs in the cloud.
> >
> > —
> > Matt Sicker
> >
> > > On Jun 16, 2022, at 12:05, Jochen Wiedmann 
> > wrote:
> > >
> > > On Wed, Jun 15, 2022 at 6:33 PM Matt Sicker  wrote:
> > >>
> > >> We could always request a Windows VM from Infra if necessary for
> > building releases. Same for a Mac VM or Linux VM, though the Linux one can
> > be done fairly easily via Docker on any OS (even FreeBSD supports Linux
> > containers now).
> > >
> > > Didn't know, that MacOS VM's even exist. Seems like overkill, tohave
> > > one, or even, two VM's just for a minor component, like Crypto. But
> > > imagine such a VM, and a Jenkins agent/server running on it, which
> > > could be used by all projects?
> > >
> > > Jochen
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Crypto] What is it ?

[Gary Gregory]

Sure, but we are not quite set up for releasing from GH, soon maybe...

On Thu, Jun 16, 2022, 15:51 Matt Sicker  wrote:

> AWS offers macOS VMs. GitHub Actions support macOS which presumably uses
> something similar. I don’t think Apple offers an equivalent service, but
> there are more companies that do offer macOS VMs in the cloud.
>
> —
> Matt Sicker
>
> > On Jun 16, 2022, at 12:05, Jochen Wiedmann 
> wrote:
> >
> > On Wed, Jun 15, 2022 at 6:33 PM Matt Sicker  wrote:
> >>
> >> We could always request a Windows VM from Infra if necessary for
> building releases. Same for a Mac VM or Linux VM, though the Linux one can
> be done fairly easily via Docker on any OS (even FreeBSD supports Linux
> containers now).
> >
> > Didn't know, that MacOS VM's even exist. Seems like overkill, tohave
> > one, or even, two VM's just for a minor component, like Crypto. But
> > imagine such a VM, and a Jenkins agent/server running on it, which
> > could be used by all projects?
> >
> > Jochen
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: [Crypto] What is it ?

[Matt Sicker]

AWS offers macOS VMs. GitHub Actions support macOS which presumably uses 
something similar. I don’t think Apple offers an equivalent service, but there 
are more companies that do offer macOS VMs in the cloud.

—
Matt Sicker

> On Jun 16, 2022, at 12:05, Jochen Wiedmann  wrote:
> 
> On Wed, Jun 15, 2022 at 6:33 PM Matt Sicker  wrote:
>> 
>> We could always request a Windows VM from Infra if necessary for building 
>> releases. Same for a Mac VM or Linux VM, though the Linux one can be done 
>> fairly easily via Docker on any OS (even FreeBSD supports Linux containers 
>> now).
> 
> Didn't know, that MacOS VM's even exist. Seems like overkill, tohave
> one, or even, two VM's just for a minor component, like Crypto. But
> imagine such a VM, and a Jenkins agent/server running on it, which
> could be used by all projects?
> 
> Jochen
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Gary Gregory]

I don't think you can do a "full" build with one Docker file. The premise I
had back when I did the release, IIRC, was that the macOS binaries had to
be built on real mac hardware to be legal. I think I built the Windows
binaries on a real Windows PC hardware too and then merged everything
together. It's been a while so I might not recall it perfectly...

Gary

On Thu, Jun 16, 2022, 13:18 Alex Remily  wrote:

> I just ran [2], and whatever it does, it doesn't appear to do a build of
> commons-crypto.  I'd appreciate it if any developers who have the time
> would take a look at the dockerfile here:
>
> https://github.com/aremily/commons-crypto
>
> If you're copying the dockerfile into your own fork, you'll need the
> makefile.common file as well.
>
> Alex
>
> On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann  >
> wrote:
>
> > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> >
> > > [1] src/docker/Dockerfile
> > > [2] src/conf/Docker/Dockerfile-luw
> >
> > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > incomplete, and can easily be removed. Was basically just an attempt
> > to reproduce the build instructions in the hope, that others would
> > verify, and fix my errors.
> >
> > Jochen
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [Crypto] What is it ?

[sebb]

On Thu, 16 Jun 2022 at 18:21, Alex Remily  wrote:
>
> Forwarding to the community dev list. Didn't realize it was dropped along
> the way.
>
> Alex
>
> -- Forwarded message -
> From: Alex Remily 
> Date: Thu, Jun 16, 2022 at 1:01 PM
> Subject: Re: [Crypto] What is it ?
> To: Jochen Wiedmann 
>
>
> Jochen,
>
> Please give my attempt at a docker build a try.  Copy the dockerfile and
> the makefile.common file from the project directory at the link below into
> your own project directory and try doing a "docker build . -t yourtagname"
> from the project directory. The makefile.common is required because there
> was a minor syntax error in the build args for the linux-arm build ("/"
> omitted after JAVA_HOME) that caused the directory to resolve improperly).
> Alternatively, you may be able to check out my fork and build it directly;
> I'm not sure what the repo permissions allow.
>
> https://github.com/aremily/commons-crypto
>
> The dockerfile builds and tests the linux x86_64 build on Ubuntu 14.04 and
> cross compiles the remaining builds.  Note that I've omitted the Win32
> build because I don't think anyone in the world uses 32 bit Windows
> anymore, and the script itself can't do the Mac build (perhaps it's
> possible to cross-compile for the Mac, but I lack the motivation to find
> out at this point).  The workaround to perform a build that includes the
> Mac is to perform Maven build on a Mac and then run the docker build.
> Docker will copy the output of the Mac build into the container and bundle
> it into the final artifact.
>
> Please provide feedback.  If it works, I'll update the build documentation
> and submit a PR to close out CRYPTO-120
> .
>

It works for me using Docker on macOS, though the output is in the
container and it's not obvious how to extract it.

I think it would be advisable to install Maven as a separate run step;
if a new version is released (e.g. 3.6.4) the link will break.
Ideally install the changeable items as separate steps, with the most
volatile last to avoid rebuilds.

Also I wonder if it would make sense to stop the build once all the
required software has been installed, rather than continuing to build
the code.

This would make it easier to re-use the container with an updated
crypto source; at present the source is built-in.
This would require mapping the host source tree to the container; it
would have the advantage that the output would end up on the host.

If the host was macOS, I assume that could then be used to build the
Mac object and generate the release.
It's going to be easier to upload the release from the host rather
than the container.

> Alex
>
> On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann 
> wrote:
>
> > Hi, Alex,
> >
> > ideally, I would like to have a variant of the current Dockerfile,
> > that builds a jar file with all the binaries included. If we would
> > have that, then we could use it to build a release.
> >
> > Thanks,
> >
> > Jochen
> >
> > On Tue, Jun 14, 2022 at 11:22 PM Alex Remily 
> > wrote:
> > >
> > > Sure.  Happy to help.  I'll try to get to it this week.  I haven't been
> > in the code for more than a year, so please be patient as I come back up to
> > speed.  What exactly do you need help with?  Building the jar via the
> > docker file?
> > >
> > > Alex
> > >
> > > On Tue, Jun 14, 2022 at 3:15 PM Jochen Wiedmann <
> > jochen.wiedm...@gmail.com> wrote:
> > >>
> > >> Hi, Alex,
> > >>
> > >> On Tue, Jun 14, 2022 at 4:38 PM Alex Remily 
> > wrote:
> > >> > appropriately.  There is a Docker file currently in the repository,
> > used
> > >> > for the 1.1 release, that manages the cross-compilation for the JNI
> > >> > libraries and packages them into the commons-crypto jar.
> > >>
> > >> Would you be able, and ready, to help me with that?
> > >>
> > >> Thanks,
> > >>
> > >> Jochen
> >
> >
> >
> > --
> > Philosophy is useless, theology is worse. (Industrial Disease, Dire
> > Straits)
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

Right.  Thanks for the pointer.

Ran a quick test on some of the build profiles, and dockerfile-luw is
missing dependencies for some of the linux builds, for example:

[exec] /bin/sh: 1: aarch64-linux-gnu-gcc: not found


That should be an easy fix that I'm happy to do, but to the larger question
of documenting the build process, I put the following to the community:


1.  Do we want a docker file like dockerfile-luw, which provides an
environment for the builds; or,

2.  do we want a docker file like the one at
https://github.com/aremily/commons-crypto that (nearly) completely
automates a full build; or,

3.  both; or

4.  something else?


I think there are benefits to 3, with the drawback being the potential
confusion of having two dockerfiles in one project.  I think, however, that
clear documentation could mitigate that drawback, while providing a fully
automated build capability as well as a flexible environment for targeted
builds.


Thoughts?

On Thu, Jun 16, 2022 at 1:58 PM sebb  wrote:

> On Thu, 16 Jun 2022 at 18:18, Alex Remily  wrote:
> >
> > I just ran [2], and whatever it does, it doesn't appear to do a build of
> > commons-crypto.
>
> That's correct; all it does is set up the environment.
> You have to then run Maven in the container.
>
> >  I'd appreciate it if any developers who have the time
> > would take a look at the dockerfile here:
> >
> > https://github.com/aremily/commons-crypto
> >
> > If you're copying the dockerfile into your own fork, you'll need the
> > makefile.common file as well.
> >
> > Alex
> >
> > On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> > >
> > > > [1] src/docker/Dockerfile
> > > > [2] src/conf/Docker/Dockerfile-luw
> > >
> > > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > > incomplete, and can easily be removed. Was basically just an attempt
> > > to reproduce the build instructions in the hope, that others would
> > > verify, and fix my errors.
> > >
> > > Jochen
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[sebb]

On Thu, 16 Jun 2022 at 18:18, Alex Remily  wrote:
>
> I just ran [2], and whatever it does, it doesn't appear to do a build of
> commons-crypto.

That's correct; all it does is set up the environment.
You have to then run Maven in the container.

>  I'd appreciate it if any developers who have the time
> would take a look at the dockerfile here:
>
> https://github.com/aremily/commons-crypto
>
> If you're copying the dockerfile into your own fork, you'll need the
> makefile.common file as well.
>
> Alex
>
> On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann 
> wrote:
>
> > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> >
> > > [1] src/docker/Dockerfile
> > > [2] src/conf/Docker/Dockerfile-luw
> >
> > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > incomplete, and can easily be removed. Was basically just an attempt
> > to reproduce the build instructions in the hope, that others would
> > verify, and fix my errors.
> >
> > Jochen
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

Do you think we could simply use CRYPTO-120
?

On Thu, Jun 16, 2022 at 1:31 PM Gilles Sadowski 
wrote:

> Hello.
>
> Since there is an issue to be solved, could you file a report on JIRA?
> [And post there patches or new files, and instructions.]
>
> Thanks,
> Gilles
>
> Le jeu. 16 juin 2022 à 19:18, Alex Remily  a écrit
> :
> >
> > I just ran [2], and whatever it does, it doesn't appear to do a build of
> > commons-crypto.  I'd appreciate it if any developers who have the time
> > would take a look at the dockerfile here:
> >
> > https://github.com/aremily/commons-crypto
> >
> > If you're copying the dockerfile into your own fork, you'll need the
> > makefile.common file as well.
> >
> > Alex
> >
> > On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > wrote:
> >
> > > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> > >
> > > > [1] src/docker/Dockerfile
> > > > [2] src/conf/Docker/Dockerfile-luw
> > >
> > > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > > incomplete, and can easily be removed. Was basically just an attempt
> > > to reproduce the build instructions in the hope, that others would
> > > verify, and fix my errors.
> > >
> > > Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Crypto] What is it ?

[Gary Gregory]

I created the docker file at the time I did the last release.

Gary

On Thu, Jun 16, 2022, 12:56 Jochen Wiedmann 
wrote:

> Hi,
>
> @Gary Gregory: Could you, please, take a look into this?
>
> Thanks,
>
> Jochen
>
>
>
> On Wed, Jun 15, 2022 at 4:51 PM Alex Remily  wrote:
> >
> > Jochen,
> >
> > I went in and had a look, and the current dockerfile doesn't appear to
> be the one we used to do the last release build.  Perhaps Gary can find it
> and check it in.  In the meantime, I'll see if I can build one and provide
> it for review.  I think it would address many of the frustrations that
> people have voiced here lately.  Thanks for bringing up the issue.
> >
> > Alex
> >
> > On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann <
> jochen.wiedm...@gmail.com> wrote:
> >>
> >> Hi, Alex,
> >>
> >> ideally, I would like to have a variant of the current Dockerfile,
> >> that builds a jar file with all the binaries included. If we would
> >> have that, then we could use it to build a release.
> >>
> >> Thanks,
> >>
> >> Jochen
> >>
> >> On Tue, Jun 14, 2022 at 11:22 PM Alex Remily 
> wrote:
> >> >
> >> > Sure.  Happy to help.  I'll try to get to it this week.  I haven't
> been in the code for more than a year, so please be patient as I come back
> up to speed.  What exactly do you need help with?  Building the jar via the
> docker file?
> >> >
> >> > Alex
> >> >
> >> > On Tue, Jun 14, 2022 at 3:15 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com> wrote:
> >> >>
> >> >> Hi, Alex,
> >> >>
> >> >> On Tue, Jun 14, 2022 at 4:38 PM Alex Remily 
> wrote:
> >> >> > appropriately.  There is a Docker file currently in the
> repository, used
> >> >> > for the 1.1 release, that manages the cross-compilation for the JNI
> >> >> > libraries and packages them into the commons-crypto jar.
> >> >>
> >> >> Would you be able, and ready, to help me with that?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Jochen
> >>
> >>
> >>
> >> --
> >> Philosophy is useless, theology is worse. (Industrial Disease, Dire
> Straits)
>
>
>
> --
> Philosophy is useless, theology is worse. (Industrial Disease, Dire
> Straits)
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Gilles Sadowski]

Hello.

Since there is an issue to be solved, could you file a report on JIRA?
[And post there patches or new files, and instructions.]

Thanks,
Gilles

Le jeu. 16 juin 2022 à 19:18, Alex Remily  a écrit :
>
> I just ran [2], and whatever it does, it doesn't appear to do a build of
> commons-crypto.  I'd appreciate it if any developers who have the time
> would take a look at the dockerfile here:
>
> https://github.com/aremily/commons-crypto
>
> If you're copying the dockerfile into your own fork, you'll need the
> makefile.common file as well.
>
> Alex
>
> On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann 
> wrote:
>
> > On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
> >
> > > [1] src/docker/Dockerfile
> > > [2] src/conf/Docker/Dockerfile-luw
> >
> > Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> > incomplete, and can easily be removed. Was basically just an attempt
> > to reproduce the build instructions in the hope, that others would
> > verify, and fix my errors.
> >
> > Jochen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Fwd: [Crypto] What is it ?

[Alex Remily]

Forwarding to the community dev list. Didn't realize it was dropped along
the way.

Alex

-- Forwarded message -
From: Alex Remily 
Date: Thu, Jun 16, 2022 at 1:01 PM
Subject: Re: [Crypto] What is it ?
To: Jochen Wiedmann 


Jochen,

Please give my attempt at a docker build a try.  Copy the dockerfile and
the makefile.common file from the project directory at the link below into
your own project directory and try doing a "docker build . -t yourtagname"
from the project directory. The makefile.common is required because there
was a minor syntax error in the build args for the linux-arm build ("/"
omitted after JAVA_HOME) that caused the directory to resolve improperly).
Alternatively, you may be able to check out my fork and build it directly;
I'm not sure what the repo permissions allow.

https://github.com/aremily/commons-crypto

The dockerfile builds and tests the linux x86_64 build on Ubuntu 14.04 and
cross compiles the remaining builds.  Note that I've omitted the Win32
build because I don't think anyone in the world uses 32 bit Windows
anymore, and the script itself can't do the Mac build (perhaps it's
possible to cross-compile for the Mac, but I lack the motivation to find
out at this point).  The workaround to perform a build that includes the
Mac is to perform Maven build on a Mac and then run the docker build.
Docker will copy the output of the Mac build into the container and bundle
it into the final artifact.

Please provide feedback.  If it works, I'll update the build documentation
and submit a PR to close out CRYPTO-120
.

Alex

On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann 
wrote:

> Hi, Alex,
>
> ideally, I would like to have a variant of the current Dockerfile,
> that builds a jar file with all the binaries included. If we would
> have that, then we could use it to build a release.
>
> Thanks,
>
> Jochen
>
> On Tue, Jun 14, 2022 at 11:22 PM Alex Remily 
> wrote:
> >
> > Sure.  Happy to help.  I'll try to get to it this week.  I haven't been
> in the code for more than a year, so please be patient as I come back up to
> speed.  What exactly do you need help with?  Building the jar via the
> docker file?
> >
> > Alex
> >
> > On Tue, Jun 14, 2022 at 3:15 PM Jochen Wiedmann <
> jochen.wiedm...@gmail.com> wrote:
> >>
> >> Hi, Alex,
> >>
> >> On Tue, Jun 14, 2022 at 4:38 PM Alex Remily 
> wrote:
> >> > appropriately.  There is a Docker file currently in the repository,
> used
> >> > for the 1.1 release, that manages the cross-compilation for the JNI
> >> > libraries and packages them into the commons-crypto jar.
> >>
> >> Would you be able, and ready, to help me with that?
> >>
> >> Thanks,
> >>
> >> Jochen
>
>
>
> --
> Philosophy is useless, theology is worse. (Industrial Disease, Dire
> Straits)
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

I just ran [2], and whatever it does, it doesn't appear to do a build of
commons-crypto.  I'd appreciate it if any developers who have the time
would take a look at the dockerfile here:

https://github.com/aremily/commons-crypto

If you're copying the dockerfile into your own fork, you'll need the
makefile.common file as well.

Alex

On Thu, Jun 16, 2022 at 1:07 PM Jochen Wiedmann 
wrote:

> On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:
>
> > [1] src/docker/Dockerfile
> > [2] src/conf/Docker/Dockerfile-luw
>
> Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
> incomplete, and can easily be removed. Was basically just an attempt
> to reproduce the build instructions in the hope, that others would
> verify, and fix my errors.
>
> Jochen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Alex Remily]

Interesting.  Since I just finished up writing yet a third dockerfile, I'll
try running both of them and see what happens.  Hopefully, one of them was
used to perform the last release and we can just update the build
documentation to reflect.

On Thu, Jun 16, 2022 at 1:00 PM sebb  wrote:

> As the subject says: are the following both needed?
>
> [1] src/docker/Dockerfile
> [2] src/conf/Docker/Dockerfile-luw
>
> [1] uses a more recent version of ubuntu, but every install runs as a
> separate step, which increases resource usage
> [2] uses quite an old Ubuntu, and has a non-standard file name
>
> Can we eliminate one of the files?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [CRYPTO] Multiple Docker files - are they both needed?

[Jochen Wiedmann]

On Thu, Jun 16, 2022 at 7:00 PM sebb  wrote:

> [1] src/docker/Dockerfile
> [2] src/conf/Docker/Dockerfile-luw

Have to admit, that I wasn't aware of [2], when I created [1]. Mine is
incomplete, and can easily be removed. Was basically just an attempt
to reproduce the build instructions in the hope, that others would
verify, and fix my errors.

Jochen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Crypto] What is it ?

[Jochen Wiedmann]

On Wed, Jun 15, 2022 at 6:33 PM Matt Sicker  wrote:
>
> We could always request a Windows VM from Infra if necessary for building 
> releases. Same for a Mac VM or Linux VM, though the Linux one can be done 
> fairly easily via Docker on any OS (even FreeBSD supports Linux containers 
> now).

Didn't know, that MacOS VM's even exist. Seems like overkill, tohave
one, or even, two VM's just for a minor component, like Crypto. But
imagine such a VM, and a Jenkins agent/server running on it, which
could be used by all projects?

Jochen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Crypto] What is it ?

[Jochen Wiedmann]

On Thu, Jun 16, 2022 at 1:03 AM sebb  wrote:

> But unless one can host macOS on Windows or vice-versa, AFAICT it will
> still require two hosts to generate a release.

Well, that's the advantage of your suggestion to release the binaries
separately.

Jochen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[CRYPTO] Multiple Docker files - are they both needed?

[sebb]

As the subject says: are the following both needed?

[1] src/docker/Dockerfile
[2] src/conf/Docker/Dockerfile-luw

[1] uses a more recent version of ubuntu, but every install runs as a
separate step, which increases resource usage
[2] uses quite an old Ubuntu, and has a non-standard file name

Can we eliminate one of the files?

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Crypto] What is it ?

[Jochen Wiedmann]

Hi,

@Gary Gregory: Could you, please, take a look into this?

Thanks,

Jochen



On Wed, Jun 15, 2022 at 4:51 PM Alex Remily  wrote:
>
> Jochen,
>
> I went in and had a look, and the current dockerfile doesn't appear to be the 
> one we used to do the last release build.  Perhaps Gary can find it and check 
> it in.  In the meantime, I'll see if I can build one and provide it for 
> review.  I think it would address many of the frustrations that people have 
> voiced here lately.  Thanks for bringing up the issue.
>
> Alex
>
> On Wed, Jun 15, 2022 at 2:41 AM Jochen Wiedmann  
> wrote:
>>
>> Hi, Alex,
>>
>> ideally, I would like to have a variant of the current Dockerfile,
>> that builds a jar file with all the binaries included. If we would
>> have that, then we could use it to build a release.
>>
>> Thanks,
>>
>> Jochen
>>
>> On Tue, Jun 14, 2022 at 11:22 PM Alex Remily  wrote:
>> >
>> > Sure.  Happy to help.  I'll try to get to it this week.  I haven't been in 
>> > the code for more than a year, so please be patient as I come back up to 
>> > speed.  What exactly do you need help with?  Building the jar via the 
>> > docker file?
>> >
>> > Alex
>> >
>> > On Tue, Jun 14, 2022 at 3:15 PM Jochen Wiedmann 
>> >  wrote:
>> >>
>> >> Hi, Alex,
>> >>
>> >> On Tue, Jun 14, 2022 at 4:38 PM Alex Remily  wrote:
>> >> > appropriately.  There is a Docker file currently in the repository, used
>> >> > for the 1.1 release, that manages the cross-compilation for the JNI
>> >> > libraries and packages them into the commons-crypto jar.
>> >>
>> >> Would you be able, and ready, to help me with that?
>> >>
>> >> Thanks,
>> >>
>> >> Jochen
>>
>>
>>
>> --
>> Philosophy is useless, theology is worse. (Industrial Disease, Dire Straits)



-- 
Philosophy is useless, theology is worse. (Industrial Disease, Dire Straits)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal

[Sumanth Rajkumar]

> EjML functional interface looks like this
>
>  void apply(ComplexDouble in, MutableComplexDouble out)
>
Similar to the mutable cursor idea we have been discussing. The Mutable
object could be an interface?

Ok

We may need to have more than one implementation of the underlying storage.
Using interleaved real and imaginary will be more efficient for computation
on a single number due to cache reads from memory. But the separate arrays
are going to be useful when writing code with the vector API that requires
extracting blocks of real or imaginary components.

 Ok


>
>
> I am still wondering how these functions can be composed. Here are a few
> ideas
>
> This may need more work..


> ComplexResultInterceptor class

It does require a lot of code that may have a far bigger overhead impact
than just creating a complex result.




I think the overhead of creating the Complex objects for the intermediates
may be lower than a solution that tries to avoid allocation overhead with
complexity of ThreadLocal. A performance benchmark would be able to
determine this so we can look at that in the future.


 Ok. Will extend java functions and create complex objects for intermediate
results


It may be useful here to create a branch in the numbers repository for all
the changes. To keep it simple perhaps a 'develop' branch can be used that
you can make your changes against.


Ok.
I can raise a PR to develop with the above changes. I will follow Alex's
latest update to the Developer Guide for pull requests.


Thanks,

Sumanth


On Wed, 15 Jun 2022 at 13:58, Alex Herbert  wrote:

> On Wed, 15 Jun 2022 at 17:38, Sumanth Rajkumar  >
> wrote:
>
> > Hi Alex,
> >
> > What do you intend to support as a "Matrix"? Is it for 2D or ND? What
> > functionality already exists for complex matrix operations such as add
> and
> > multiply in for example EJML?
> >
> > This may require some expansion.
> >
> > a) I reviewed EJML data naming conventions, this is what they follow:
> >
> >
> >
> https://github.com/lessthanoptimal/ejml#procedural-api-matrix-and-class-names
> > Should we follow this approach as well?
> >I wasn't thinking about implementing ND right now, maybe I can during
> > Phase 2?
> >
>
> OK.
>
>
> >
> > b) EJML only supports 2D matrices with vector (1XN) being a special case,
> > should I do that too?
> >
>
> OK.
>
>
> >
> > c) EJML uses a mutable ComplexResult, they use a single mutable class for
> > both input and output and return void
> >
> > Here is the link to their implementation:
> >
> >
> >
> https://github.com/lessthanoptimal/ejml/blob/SNAPSHOT/main/ejml-core/src/org/ejml/ops/ComplexMath_F64.java
> >
> > Their functional interface looks like this
> >
> >  void apply(ComplexDouble in, MutableComplexDouble out)
> >
>
> Similar to the mutable cursor idea we have been discussing. The Mutable
> object could be an interface?
>
>
> >
> > d) For dense Matrix internal storage, I'm planning on using separate
> arrays
> > (or a single array where the first half of the array will be real and the
> > second half will be imaginary) instead of alternating real and imaginary
> > because it allows us to optimize space for pure imaginary or real
> matrices.
> >
> > Is that ok?
> >
>
> We may need to have more than one implementation of the underlying storage.
> Using interleaved real and imaginary will be more efficient for computation
> on a single number due to cache reads from memory. But the separate arrays
> are going to be useful when writing code with the vector API that requires
> extracting blocks of real or imaginary components.
>
>
> >
> >
> > I am still wondering how these functions can be composed. Here are a few
> > ideas
> >
> >
> > This may need more work..
> >
> >
> > I have provided an approach below using an intermediate
> > ComplexResultInterceptor class that is thread-safe and minimizes object
> > creation using thread local and stacks. It also doesn't require
> > ComplexDouble constraint for the generic R result type.
> >
>
> It does require a lot of code that may have a far bigger overhead impact
> than just creating a complex result.
>
> Since thread safety requires an intermediate be stored then it may make
> more sense to expand the API to allow operations on a list using a unary
> operator of complex:
>
> UnaryOperator op;
>
> You can then create your function to work on a complex number and chain
> them together using the standard java 8 functions. This could be supported
> for the ISO c99 functions by just using Complex. Unfortunately this does
> not work as the UnaryOperator has not overridden andThen and compose for
> the single argument. This is valid:
>
> UnaryOperator op = Complex::sqrt;
> // These compose to Function
> Function op2 = op.andThen(Complex::conj);
> Function op3 = op.compose(Complex::conj);
>
> // Invalid to assign back to UnaryOperator
> op = op.andThen(Complex::conj);
> // OK with a cast
> op = (UnaryOperator) op.andThen(Complex::conj);
>
> // In use:
>