Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

Gary,

I don't have access to the page at the link.  Can you add me?
Sorry, you can't view this page
This page is only available to Jira Software users. If you think you should
be a Jira Software user, you should ask your administrator to give you
application access to Jira Software.

On Fri, Apr 10, 2020 at 8:20 PM Gary Gregory  wrote:

> On Fri, Apr 10, 2020 at 8:02 PM Gary Gregory 
> wrote:
>
> > I'll see what I can do over the weekend.
> >
> > Gary
> >
>
> Alex,
>
> Here is how you can help now:
>
> Please review the tickets for 1.1.0 here:
> https://issues.apache.org/jira/projects/CRYPTO/versions/12335578
>
> These are all marked as resolved. Can you confirm that these indeed all
> are?
>
> TY,
> Gary
>
>
> >
> > On Thu, Apr 9, 2020 at 8:45 PM Alex Remily 
> wrote:
> >
> >> Commons Crypto Team,
> >>
> >> It's been four years since the last release of commons crypto.  There
> have
> >> been many updates to the repository since then, notably the integration
> of
> >> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I
> have
> >> been advocating for a new release, and we need assistance from someone
> who
> >> knows the release process and has the necessary accesses.  If any of you
> >> are willing to assist with this effort, please come up on the apache
> >> commons dev list (also copied) and announce yourself.
> >>
> >> Looking forward to hearing from you.
> >>
> >> Alex
> >>
> >
>

Re: [crypto] Help Releasing new Commons Crypto

[Marcelo Vanzin]

(-CCs)

Hi Gary, thanks for volunteering to help. If needed I can try helping with
the release process (e.g. uploading artifacts), but I don't really have the
ability to build anything but the linux64 native lib (maybe the linux32 one
if I can find the right packages or docker image).

I looked at the 1.0 release and it seems to include linux32/64, win32/64
and macos64.

src/changes/changes.xml probably needs some love too.


On Fri, Apr 10, 2020 at 5:02 PM Gary Gregory  wrote:

> I'll see what I can do over the weekend.
>
> Gary
>
>
> On Thu, Apr 9, 2020 at 8:45 PM Alex Remily  wrote:
>
>> Commons Crypto Team,
>>
>> It's been four years since the last release of commons crypto.  There have
>> been many updates to the repository since then, notably the integration of
>> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I have
>> been advocating for a new release, and we need assistance from someone who
>> knows the release process and has the necessary accesses.  If any of you
>> are willing to assist with this effort, please come up on the apache
>> commons dev list (also copied) and announce yourself.
>>
>> Looking forward to hearing from you.
>>
>> Alex
>>
>

Re: [crypto] Help Releasing new Commons Crypto

[Gary Gregory]

On Fri, Apr 10, 2020 at 8:02 PM Gary Gregory  wrote:

> I'll see what I can do over the weekend.
>
> Gary
>

Alex,

Here is how you can help now:

Please review the tickets for 1.1.0 here:
https://issues.apache.org/jira/projects/CRYPTO/versions/12335578

These are all marked as resolved. Can you confirm that these indeed all are?

TY,
Gary


>
> On Thu, Apr 9, 2020 at 8:45 PM Alex Remily  wrote:
>
>> Commons Crypto Team,
>>
>> It's been four years since the last release of commons crypto.  There have
>> been many updates to the repository since then, notably the integration of
>> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I have
>> been advocating for a new release, and we need assistance from someone who
>> knows the release process and has the necessary accesses.  If any of you
>> are willing to assist with this effort, please come up on the apache
>> commons dev list (also copied) and announce yourself.
>>
>> Looking forward to hearing from you.
>>
>> Alex
>>
>

Re: [crypto] Help Releasing new Commons Crypto

[Gary Gregory]

I'll see what I can do over the weekend.

Gary


On Thu, Apr 9, 2020 at 8:45 PM Alex Remily  wrote:

> Commons Crypto Team,
>
> It's been four years since the last release of commons crypto.  There have
> been many updates to the repository since then, notably the integration of
> OpenSSL 1.1.1, and native arm64 support.  Geoff Blake (copied) and I have
> been advocating for a new release, and we need assistance from someone who
> knows the release process and has the necessary accesses.  If any of you
> are willing to assist with this effort, please come up on the apache
> commons dev list (also copied) and announce yourself.
>
> Looking forward to hearing from you.
>
> Alex
>

Re: [numbers] Fraction

[Eric Barnhill]

Great +1

On Thu, Apr 9, 2020 at 3:59 PM Gilles Sadowski  wrote:

> Le jeu. 9 avr. 2020 à 23:20, Alex Herbert  a
> écrit :
> >
> >
> >
> > > On 9 Apr 2020, at 21:36, Gilles Sadowski  wrote:
> > >
> > > Le jeu. 9 avr. 2020 à 22:20, Alex Herbert 
> a écrit :
> > >>
> > >>
> > >>
> > >>> On 9 Apr 2020, at 16:32, Gilles Sadowski 
> wrote:
> > >>>
> > >>>
> > >>>
> >  Given this I am thinking that using ZERO when possible is a better
> >  option and avoid 0 / -1.
> > >>>
> > >>> Hmm, then I'm both +0 and -0 (which is the same, right?)
> > >>> on this issue. ;-)
> > >>
> > >> Ironically the conversion to a double is a minor bug:
> > >>
> > >> Fraction.of(0, 1).doubleValue() == 0.0
> > >> Fraction.of(0, -01).doubleValue() == -0.0
> > >>
> > >> IEEE754 arithmetic for 0.0 / -1.0 creates a -0.0.
> > >>
> > >> Do we want to support -0.0?
> > >
> > > Why prevent it since it looks expected from the above call?
> >
> > Well, in the against argument -0.0 is an artefact of the IEEE floating
> point format. It is not a real number.
> >
> > If we allow 0 / -1 as a fraction to mean something then we should really
> support it fully which means carrying the sign of the denominator through
> arithmetic as would be done for -0.0 (from the top of my head):
> >
> > -0.0 + -0.0 = -0.0
> > -0.0 + 0.0 = 0.0
> > 0.0 - -0.0 = 0.0
> > 0.0 - 0.0 = 0.0
> > 0.0 * 42 = 0.0
> > -0.0 * 42 = -0.0
> >
> > And so on...
> >
> > It is easier to exclude this representation from ever existing by
> changing the factory constructor to not allow it.
> >
> > Note that Fraction.of(-0.0) creates 0 / 1. So the support for 0 / 1 is
> inconsistent with conversion to and from double:
> >
> > Fraction.of(-0.0).doubleValue() == 0.0
> > Fraction.of(0, -1).doubleValue() == -0.0
> >
> > I have checked and Fraction.of(0, 1).compareTo(Fraction.of(0, -1)) is 0.
> They evaluate to equal and have the same hash code. So this behaviour is
> different from Double.compareTo, Double.equals and Double.hashCode which
> distinguishes the two values.
> >
> > If fraction represented a signed number using the signed numerator and
> an unsigned denominator, reduced to smallest form, then the representation
> of zero is fixed. It would be 0 / 1 as you cannot have -0 as an integer.
>
> This seems to be the winning argument to transform all zero to
> canonical form.
>
> > This issue has been created by the support for the sign in either part
> so that Integer.MIN_VALUE can be used as a denominator. This is a nice
> change to allow support for fractions up to 2^-31. But creates this signed
> zero issue.
> >
> > It leads me to think we should have a canonical representation of zero
> as 0 / 1 and prevent creation of 0 / -1 by careful management of class
> creation.
>
> +1
>
> Best,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

OpenJDK 15 EA build 18 is now available

[Rory O'Donnell]

Hi Benedikt,

OpenJDK 15 EA build 18 is now available at http://jdk.java.net/15 *
*

 * These early access, open source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Schedule for JDK 15
 o 2020/06/11 Rampdown Phase One
 o 2020/07/16 Rampdown Phase Two
 o 2020/08/06 Initial Release Candidate
 o 2020/08/20 Final Release Candidate
 o 2020/09/15 General Availability
 * Features
 o Proposed to target JDK 15
 + JEP 371:   Hidden Classes
 o JEPs targeted to JDK 15
 + JEP 372 : Remove the
   Nashorn JavaScript Engine
 + JEP 377 : ZGC: A Scalable
   Low-Latency Garbage Collector
 + JEP 378 : Text Blocks
 + JEP 379 : Shenandoah: A
   Low-Pause-Time Garbage Collector
 * Changes in recent builds that maybe of interest:
 o build 18
 + JDK-8240169
   : javadoc
   fails to link to non-modular api docs
 # Reported by JUnit5
 + JDK-8241670
   : Enhance
   heap region size ergonomics to improve OOTB performance
 + JDK-8240745
   :
   Implementation: JEP 377: ZGC: A Scalable Low-Latency Garbage
   Collector (Production)
 + JDK-8225319
   : Remove
   rmic from the set of supported tools
 + JDK-8237490
   : Add
   support notarizing jpackage app-image and dmg
 o build 17
 + JDK-8240676
    - Meet
   not symmetric failure when running lucene on jdk8
 # Reported by Apache Lucene
 o Build 16
 + JDK-8241039
    - Retire
   the deprecated SSLSession.getPeerCertificateChain() method
 + JDK-8219989
    - Retire
   the com.sun.net.ssl.internal.ssl.Provider name
 + JDK-8237859
    - C2:
   Crash when loads float above range check
 # Reported by Apache Lucene
 + JDK-8202469
    - (ann)
   Type annotations on type variable bounds that are also type
   variables are lost
 # Reported by ByteBuddy
 o Build 15
 + JDK-8214245
    - Case
   insensitive matching doesn't work correctly for some
   character classes ()

 * Quality Report for March 2020 was published here [1]
 o Thanks again for all the bug reports and feeback!

Does your Project support JDK 14 - #AllTestsGreenOnJDK14 



Rgds,Rory

[1] 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2020 



--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland