From jcbeyler at google.com  Thu Jul  4 00:40:52 2019
From: jcbeyler at google.com (Jean Christophe Beyler)
Date: Wed, 3 Jul 2019 17:40:52 -0700
Subject: Question: Where are JEPs discussed?
In-Reply-To: <5CDD82DF.2030202@oracle.com>
References: <OF0D601429.FC2DEA67-ON002583FC.00340B60-802583FC.003441BB@notes.na.collabserv.com>
 <5CDD82DF.2030202@oracle.com>
Message-ID: <CAF9BGBzxEja2Ae2hzE0_wPdM0gEBq_i2QXbN=ThE4mkNpL30-w@mail.gmail.com>

FWIW, I had done a while ago this dashboard to follow JEPs across the
various process-steps they need to do:
https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=17928

Thanks,
Jc

On Thu, May 16, 2019 at 8:34 AM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Thanks Adam, you're welcome. The science of JEPs is not terribly
> difficult, but it's not widely examined either, so it's good to discuss.
>
> Alex
>
> On 5/16/2019 2:30 AM, Adam Farley8 wrote:
> > Thanks for your insight too Alex. :)
> >
> > Sorry for the delay. I didn't get emails for any of your replies, and
> > had to read the archives.
> >
> > Best Regards
> >
> > Adam Farley
> > IBM Runtimes
> >
> > On 5/9/2019 4:55 AM, Andrew Haley wrote:
> >> > On 5/8/19  2:37 PM, Adam Farley8 wrote:
> >> >>  Adam Farley8/UK/IBM wrote on 08/05/2019 14:35:59:
> >> >>
> >> >>>  Does anyone know the answer to this question, raised on
> jep-changes:
> >> >>>
> >> >>>  "What's a good way to stay informed about new JEPs and changes to
> >> >>>  existing JEPs?"
> >> >
> >> > I'm  not sure there is a single place, really. There are OpenJDK
> >> > projects,  and occasionally one will turn into a JEP. JEPs are
> >> > announced  on the jdk-dev list. Detailed discussion is on the project
> >> > list.
> >>
> >> "JEPs  are announced on the jdk-dev list." is misleading. There are
> >> announcements  about JEPs on jdk-dev, sure, but the announcements are
> not
> >> about the  creation of new JEPs [*]. The announcements are about the
> >> readiness  of pre-existing candidate JEPs for a specific JDK release.
> >>
> >> I suppose  that a candidate JEP which has been kicked around on a
> Project
> >> or Group  list for years, and is now being announced on jdk-dev for
> >> targeting,  might be considered "new" in the sense of "new to the JDK
> >> Project".  But it's also easy to imagine that a JEP which has been
> kicked
> >> around on  a Project or Group list for months is "new" when, on reaching
> >> candidate  status, it receives a number -- after all, the announcement
> on
> >> the Project  or Group list is the only one which actually labels a JEP
> as
> >> "new"  (e.g. "New candidate JEP: 341: Default CDS Archives").
> >>
> >> All in all,  it's best to be clear about the stage a JEP is in -- draft,
> >> candidate,  and targeted are the main ones -- so that people don't
> assume
> >> that JDK  N will have feature X just because a JEP issue exists in JBS.
> >>
> >> Alex
> >>
> >> [*] Very  occasionally, there genuinely is an announcement on jdk-dev
> >> about the  creation of a new JEP (e.g. JEPs 335 and 336 in June 2018)
> >> because the  JEP will interest many Projects and Groups. And, very
> >> occasionally,  JEP owners advertise their draft JEPs on jdk-dev, because
> >> of the wide  readership. But it's the exception, not the rule, to see
> >> JEPs mentioned  on jdk-dev before they're ready to target a release.
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>


-- 

Thanks,
Jc

From amnojeeuw at gmail.com  Fri Jul  5 15:45:23 2019
From: amnojeeuw at gmail.com (AmnoJeeuw)
Date: Fri, 5 Jul 2019 11:45:23 -0400
Subject: Scene - bug ???
Message-ID: <85c5d5d5-b6e7-eca4-2ff6-956d913db10c@gmail.com>

Windows 8.1 - 64Bit
Java --version
Openjdk 12.0.1 2019-04-06
OpenJDK Runtime Environment (build 12.0.1+12)
OpenJDK 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)

OpenJFX = javafx-sdk-12.0.1

<code>

public void start(Stage primaryStage) throws Exception {

MainWindow = primaryStage;

// DataIntegrityVerification is a wrapper of StringBuffer
// chispa.GlobalSettings.acquireIconListDirectoryName() returns a 
directory name - String
var IconLoc = new 
DataIntegrityVerification(chispa.GlobalSettings.acquireIconListDirectoryName());

// The file name
IconLoc.append("Icon16x16.png");

var myIconFile = new File(IconLoc.toString());
System.out.println("False = Exist : "+String.valueOf(myIconFile.exists()));

// both of these string work
var appIcon = new Image( 
/*myIconFile.toURI().toString()*/"file://"+IconLoc.toString() );

// Displays the right folder name - complete path
System.out.println("Image URL is? "+this.appIcon.getUrl());

MainWindow.getIcons().add(appIcon);
</code>

No errors, but the icon does not display on the top-left corner of the 
window.

Is this a bug?
Is anyone else experiencing the same issue?
Or is it just me who is not smart enough?


---
This email has been checked for viruses by AVG.
https://www.avg.com


From volker.simonis at gmail.com  Tue Jul  9 21:56:29 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 9 Jul 2019 23:56:29 +0200
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <CA+3eh11O9QAwFaxwy3VmNsVk7kFCfJxJEObwX2mi99RwX+B8ig@mail.gmail.com>

Vote: yes


Phil Race <philip.race at oracle.com> schrieb am Di. 9. Juli 2019 um 23:51:

> I hereby propose the creation of the Lanai Project to implement a new
> graphics rendering pipeline for macOS, with Phil Race as the Lead and
> the 2D Group as the sponsoring Group.
>
> Background and Motivation:
> Apple Inc. have created the Metal [1] graphics API designed to be their
> long term replacement for OpenGL as the rendering pipeline on Apple
> platforms, including macOS. It promises better performance than OpenGL
> and simpler GPU designs by being a simpler API without the legacies of
> OpenGL.
>
> The JDK, and OpenJFX today both use OpenGL as the rendering pipeline on
> macOS, but Apple have deprecated OpenGL as of MacOS 10.14 [2], and
> recommend to transition to Metal.
> If OpenGL is not present on a macOS system, the JDK desktop APIs cannot
> function and will fail to start. OpenJFX is in a very similar position.
>
> For some months, engineers from Oracle and JetBrains [3], have been
> exploring the Metal APIs and working on some proofs of concept, starting
> with the existing OpenGL pipeline as a base and doing prototyping work
> in the JDK sandbox [4] in the metal-prototype-branch and in the case of
> JetBrains, separately on github.
> We have also discussed specific issues on the 2d-dev mailing list and
> have a wiki page [5].
>
> However to further collaboration and advance the goals we would like to
> move this work to a location where we can work together and more
> engineers can contribute, and therefore propose this project.
>
> Note: the rendering pipelines in the JDK are internal implementation
> details, so this project will not create, or otherwise be exposed as,
> Java APIs
>
> Phil Race is the lead of the Java 2D group and has worked on the Java 2D
> APIs for many years as well. He has also made significant contributions
> to the OpenJFX project and to the Swing and AWT APIs
>
> Goals of the Project:
> This project will create a Java 2D rendering pipeline for macOS using
> the Apple Metal APIs which aims to be at least as capable, robust and
> performant, as the current OpenGL pipeline.
> This project will also be the basis of a similar Metal pipeline for the
> OpenJFX project [6].
>
> Initial committers will include
> Phil Race (prr)
> Ajit Ghaisas (aghaisas)
> Jay DV (jdv)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Alexey Ushakov (avu)
>
> A complete list will be provided to the registrar at the successful
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Tuesday July 23rd 2019.
>
> Only current OpenJDK Members [7] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.
> Replying to this message is sufficient if your mail program honors the
> Reply-To header.
>
> For Lazy Consensus voting instructions, see [8].
>
> -Phil Race.
>
> [1] https://developer.apple.com/metal/
> [2]
>
> https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes
>
> [3] https://www.jetbrains.com/
> [4] http://hg.openjdk.java.net/jdk/sandbox/
> [5]
> https://wiki.openjdk.java.net/display/2d/Metal+Graphics+Pipeline+for+MacOS
> [6] http://openjdk.java.net/projects/openjfx/
> [7] http://openjdk.java.net/census#members
> [8] http://openjdk.java.net/projects/#new-project-vote
>

From jonathan.gibbons at oracle.com  Tue Jul  9 22:15:53 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 9 Jul 2019 15:15:53 -0700
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <8a857e06-3a83-68df-735e-bb1932070a9e@oracle.com>

Vote: yes


On 07/09/2019 12:13 PM, Phil Race wrote:
> I hereby propose the creation of the Lanai Project to implement a new 
> graphics rendering pipeline for macOS, with Phil Race as the Lead and 
> the 2D Group as the sponsoring Group.
>
> Background and Motivation:
> Apple Inc. have created the Metal [1] graphics API designed to be 
> their long term replacement for OpenGL as the rendering pipeline on 
> Apple platforms, including macOS. It promises better performance than 
> OpenGL and simpler GPU designs by being a simpler API without the 
> legacies of OpenGL.
>
> The JDK, and OpenJFX today both use OpenGL as the rendering pipeline 
> on macOS, but Apple have deprecated OpenGL as of MacOS 10.14 [2], and 
> recommend to transition to Metal.
> If OpenGL is not present on a macOS system, the JDK desktop APIs 
> cannot function and will fail to start. OpenJFX is in a very similar 
> position.
>
> For some months, engineers from Oracle and JetBrains [3], have been 
> exploring the Metal APIs and working on some proofs of concept, 
> starting with the existing OpenGL pipeline as a base and doing 
> prototyping work in the JDK sandbox [4] in the metal-prototype-branch 
> and in the case of JetBrains, separately on github.
> We have also discussed specific issues on the 2d-dev mailing list and 
> have a wiki page [5].
>
> However to further collaboration and advance the goals we would like 
> to move this work to a location where we can work together and more 
> engineers can contribute, and therefore propose this project.
>
> Note: the rendering pipelines in the JDK are internal implementation 
> details, so this project will not create, or otherwise be exposed as, 
> Java APIs
>
> Phil Race is the lead of the Java 2D group and has worked on the Java 
> 2D APIs for many years as well. He has also made significant 
> contributions to the OpenJFX project and to the Swing and AWT APIs
>
> Goals of the Project:
> This project will create a Java 2D rendering pipeline for macOS using 
> the Apple Metal APIs which aims to be at least as capable, robust and 
> performant, as the current OpenGL pipeline.
> This project will also be the basis of a similar Metal pipeline for 
> the OpenJFX project [6].
>
> Initial committers will include
> Phil Race (prr)
> Ajit Ghaisas (aghaisas)
> Jay DV (jdv)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Alexey Ushakov (avu)
>
> A complete list will be provided to the registrar at the successful 
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Tuesday July 23rd 2019.
>
> Only current OpenJDK Members [7] are eligible to vote on this motion.? 
> Votes must be cast in the open on the discuss list.
> Replying to this message is sufficient if your mail program honors the 
> Reply-To header.
>
> For Lazy Consensus voting instructions, see [8].
>
> -Phil Race.
>
> [1] https://developer.apple.com/metal/
> [2] 
> https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes 
>
> [3] https://www.jetbrains.com/
> [4] http://hg.openjdk.java.net/jdk/sandbox/
> [5] 
> https://wiki.openjdk.java.net/display/2d/Metal+Graphics+Pipeline+for+MacOS
> [6] http://openjdk.java.net/projects/openjfx/
> [7] http://openjdk.java.net/census#members
> [8] http://openjdk.java.net/projects/#new-project-vote


From joe.darcy at oracle.com  Tue Jul  9 22:53:59 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 9 Jul 2019 15:53:59 -0700
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <3a17ed07-53ba-1e66-5743-92af0bf4c348@oracle.com>

Vote: yes

-Joe

On 7/9/2019 12:13 PM, Phil Race wrote:
> I hereby propose the creation of the Lanai Project to implement a new 
> graphics rendering pipeline for macOS, with Phil Race as the Lead and 
> the 2D Group as the sponsoring Group.
>
> Background and Motivation:
> Apple Inc. have created the Metal [1] graphics API designed to be 
> their long term replacement for OpenGL as the rendering pipeline on 
> Apple platforms, including macOS. It promises better performance than 
> OpenGL and simpler GPU designs by being a simpler API without the 
> legacies of OpenGL.
>
> The JDK, and OpenJFX today both use OpenGL as the rendering pipeline 
> on macOS, but Apple have deprecated OpenGL as of MacOS 10.14 [2], and 
> recommend to transition to Metal.
> If OpenGL is not present on a macOS system, the JDK desktop APIs 
> cannot function and will fail to start. OpenJFX is in a very similar 
> position.
>
> For some months, engineers from Oracle and JetBrains [3], have been 
> exploring the Metal APIs and working on some proofs of concept, 
> starting with the existing OpenGL pipeline as a base and doing 
> prototyping work in the JDK sandbox [4] in the metal-prototype-branch 
> and in the case of JetBrains, separately on github.
> We have also discussed specific issues on the 2d-dev mailing list and 
> have a wiki page [5].
>
> However to further collaboration and advance the goals we would like 
> to move this work to a location where we can work together and more 
> engineers can contribute, and therefore propose this project.
>
> Note: the rendering pipelines in the JDK are internal implementation 
> details, so this project will not create, or otherwise be exposed as, 
> Java APIs
>
> Phil Race is the lead of the Java 2D group and has worked on the Java 
> 2D APIs for many years as well. He has also made significant 
> contributions to the OpenJFX project and to the Swing and AWT APIs
>
> Goals of the Project:
> This project will create a Java 2D rendering pipeline for macOS using 
> the Apple Metal APIs which aims to be at least as capable, robust and 
> performant, as the current OpenGL pipeline.
> This project will also be the basis of a similar Metal pipeline for 
> the OpenJFX project [6].
>
> Initial committers will include
> Phil Race (prr)
> Ajit Ghaisas (aghaisas)
> Jay DV (jdv)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Alexey Ushakov (avu)
>
> A complete list will be provided to the registrar at the successful 
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Tuesday July 23rd 2019.
>
> Only current OpenJDK Members [7] are eligible to vote on this motion.? 
> Votes must be cast in the open on the discuss list.
> Replying to this message is sufficient if your mail program honors the 
> Reply-To header.
>
> For Lazy Consensus voting instructions, see [8].
>
> -Phil Race.
>
> [1] https://developer.apple.com/metal/
> [2] 
> https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes 
>
> [3] https://www.jetbrains.com/
> [4] http://hg.openjdk.java.net/jdk/sandbox/
> [5] 
> https://wiki.openjdk.java.net/display/2d/Metal+Graphics+Pipeline+for+MacOS
> [6] http://openjdk.java.net/projects/openjfx/
> [7] http://openjdk.java.net/census#members
> [8] http://openjdk.java.net/projects/#new-project-vote

From philip.race at oracle.com  Wed Jul 10 00:01:05 2019
From: philip.race at oracle.com (Philip Race)
Date: Tue, 09 Jul 2019 17:01:05 -0700
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <5D252AC1.60209@oracle.com>

Vote: yes

-phil.


From Sergey.Bylokhov at oracle.com  Wed Jul 10 03:07:09 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 9 Jul 2019 20:07:09 -0700
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <7760f405-1dee-d85e-78f5-2db6cc586bab@oracle.com>

Vote: yes
-- 
Best regards, Sergey.

From daniel.fuchs at oracle.com  Wed Jul 10 09:17:46 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 10 Jul 2019 11:17:46 +0200
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <a9f9e344-0b8d-972c-3a0c-a093196d88b8@oracle.com>

Vote: yes

best regards,

-- daniel

On 09/07/2019 21:13, Phil Race wrote:
> I hereby propose the creation of the Lanai Project to implement a new 
> graphics rendering pipeline for macOS, with Phil Race as the Lead and 
> the 2D Group as the sponsoring Group.

From amnojeeuw at gmail.com  Wed Jul 10 11:18:36 2019
From: amnojeeuw at gmail.com (AmnoJeeuw)
Date: Wed, 10 Jul 2019 07:18:36 -0400
Subject: CFV: New Project: Lanai
In-Reply-To: <7760f405-1dee-d85e-78f5-2db6cc586bab@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
 <7760f405-1dee-d85e-78f5-2db6cc586bab@oracle.com>
Message-ID: <4b9d0f2c-307d-b278-d4d9-815ad8068b9a@gmail.com>

I vote Amn, who seconds my vote?

On 2019-07-09 11:07 p.m., Sergey Bylokhov wrote:
> Vote: yes

---
This email has been checked for viruses by AVG.
https://www.avg.com


From neugens.limasoftware at gmail.com  Wed Jul 10 11:22:40 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 10 Jul 2019 13:22:40 +0200
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <CAGUMyaSp6Pfzi5MgU8NC77suOMbqpb0=vOZ_F-5zo6obBObCdg@mail.gmail.com>

Vote: Yes.

Cheers,
Mario

On Tue 9. Jul 2019 at 23:51, Phil Race <philip.race at oracle.com> wrote:

> I hereby propose the creation of the Lanai Project to implement a new
> graphics rendering pipeline for macOS, with Phil Race as the Lead and
> the 2D Group as the sponsoring Group.
>
> Background and Motivation:
> Apple Inc. have created the Metal [1] graphics API designed to be their
> long term replacement for OpenGL as the rendering pipeline on Apple
> platforms, including macOS. It promises better performance than OpenGL
> and simpler GPU designs by being a simpler API without the legacies of
> OpenGL.
>
> The JDK, and OpenJFX today both use OpenGL as the rendering pipeline on
> macOS, but Apple have deprecated OpenGL as of MacOS 10.14 [2], and
> recommend to transition to Metal.
> If OpenGL is not present on a macOS system, the JDK desktop APIs cannot
> function and will fail to start. OpenJFX is in a very similar position.
>
> For some months, engineers from Oracle and JetBrains [3], have been
> exploring the Metal APIs and working on some proofs of concept, starting
> with the existing OpenGL pipeline as a base and doing prototyping work
> in the JDK sandbox [4] in the metal-prototype-branch and in the case of
> JetBrains, separately on github.
> We have also discussed specific issues on the 2d-dev mailing list and
> have a wiki page [5].
>
> However to further collaboration and advance the goals we would like to
> move this work to a location where we can work together and more
> engineers can contribute, and therefore propose this project.
>
> Note: the rendering pipelines in the JDK are internal implementation
> details, so this project will not create, or otherwise be exposed as,
> Java APIs
>
> Phil Race is the lead of the Java 2D group and has worked on the Java 2D
> APIs for many years as well. He has also made significant contributions
> to the OpenJFX project and to the Swing and AWT APIs
>
> Goals of the Project:
> This project will create a Java 2D rendering pipeline for macOS using
> the Apple Metal APIs which aims to be at least as capable, robust and
> performant, as the current OpenGL pipeline.
> This project will also be the basis of a similar Metal pipeline for the
> OpenJFX project [6].
>
> Initial committers will include
> Phil Race (prr)
> Ajit Ghaisas (aghaisas)
> Jay DV (jdv)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Alexey Ushakov (avu)
>
> A complete list will be provided to the registrar at the successful
> conclusion of this CFV.
>
> Votes are due by 5pm PDT on Tuesday July 23rd 2019.
>
> Only current OpenJDK Members [7] are eligible to vote on this motion.
> Votes must be cast in the open on the discuss list.
> Replying to this message is sufficient if your mail program honors the
> Reply-To header.
>
> For Lazy Consensus voting instructions, see [8].
>
> -Phil Race.
>
> [1] https://developer.apple.com/metal/
> [2]
>
> https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes
>
> [3] https://www.jetbrains.com/
> [4] http://hg.openjdk.java.net/jdk/sandbox/
> [5]
> https://wiki.openjdk.java.net/display/2d/Metal+Graphics+Pipeline+for+MacOS
> [6] http://openjdk.java.net/projects/openjfx/
> [7] http://openjdk.java.net/census#members
> [8] http://openjdk.java.net/projects/#new-project-vote
>
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From Roger.Riggs at oracle.com  Wed Jul 10 13:09:45 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 10 Jul 2019 09:09:45 -0400
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <882af4d7-1cd3-ecd4-d168-a4234d3b4749@oracle.com>

Vote: Yes

On 7/9/19 3:13 PM, Phil Race wrote:
> I hereby propose the creation of the Lanai Project to implement a new 
> graphics rendering pipeline for macOS, with Phil Race as the Lead and 
> the 2D Group as the sponsoring Group. 


From naoto.sato at oracle.com  Wed Jul 10 15:52:35 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 10 Jul 2019 08:52:35 -0700
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <b7008f62-2427-4c39-2b2d-a803d3095923@oracle.com>

Vote: yes

Naoto

On 7/9/19 12:13 PM, Phil Race wrote:
> I hereby propose the creation of the Lanai Project to implement a new 
> graphics rendering pipeline for macOS, with Phil Race as the Lead and 
> the 2D Group as the sponsoring Group.
> 
> Background and Motivation:
> Apple Inc. have created the Metal [1] graphics API designed to be their 
> long term replacement for OpenGL as the rendering pipeline on Apple 
> platforms, including macOS. It promises better performance than OpenGL 
> and simpler GPU designs by being a simpler API without the legacies of 
> OpenGL.
> 
> The JDK, and OpenJFX today both use OpenGL as the rendering pipeline on 
> macOS, but Apple have deprecated OpenGL as of MacOS 10.14 [2], and 
> recommend to transition to Metal.
> If OpenGL is not present on a macOS system, the JDK desktop APIs cannot 
> function and will fail to start. OpenJFX is in a very similar position.
> 
> For some months, engineers from Oracle and JetBrains [3], have been 
> exploring the Metal APIs and working on some proofs of concept, starting 
> with the existing OpenGL pipeline as a base and doing prototyping work 
> in the JDK sandbox [4] in the metal-prototype-branch and in the case of 
> JetBrains, separately on github.
> We have also discussed specific issues on the 2d-dev mailing list and 
> have a wiki page [5].
> 
> However to further collaboration and advance the goals we would like to 
> move this work to a location where we can work together and more 
> engineers can contribute, and therefore propose this project.
> 
> Note: the rendering pipelines in the JDK are internal implementation 
> details, so this project will not create, or otherwise be exposed as, 
> Java APIs
> 
> Phil Race is the lead of the Java 2D group and has worked on the Java 2D 
> APIs for many years as well. He has also made significant contributions 
> to the OpenJFX project and to the Swing and AWT APIs
> 
> Goals of the Project:
> This project will create a Java 2D rendering pipeline for macOS using 
> the Apple Metal APIs which aims to be at least as capable, robust and 
> performant, as the current OpenGL pipeline.
> This project will also be the basis of a similar Metal pipeline for the 
> OpenJFX project [6].
> 
> Initial committers will include
> Phil Race (prr)
> Ajit Ghaisas (aghaisas)
> Jay DV (jdv)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Alexey Ushakov (avu)
> 
> A complete list will be provided to the registrar at the successful 
> conclusion of this CFV.
> 
> Votes are due by 5pm PDT on Tuesday July 23rd 2019.
> 
> Only current OpenJDK Members [7] are eligible to vote on this motion. 
> Votes must be cast in the open on the discuss list.
> Replying to this message is sufficient if your mail program honors the 
> Reply-To header.
> 
> For Lazy Consensus voting instructions, see [8].
> 
> -Phil Race.
> 
> [1] https://developer.apple.com/metal/
> [2] 
> https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes 
> 
> [3] https://www.jetbrains.com/
> [4] http://hg.openjdk.java.net/jdk/sandbox/
> [5] 
> https://wiki.openjdk.java.net/display/2d/Metal+Graphics+Pipeline+for+MacOS
> [6] http://openjdk.java.net/projects/openjfx/
> [7] http://openjdk.java.net/census#members
> [8] http://openjdk.java.net/projects/#new-project-vote

From brent.christian at oracle.com  Wed Jul 10 16:50:36 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 10 Jul 2019 09:50:36 -0700
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <5086ebf9-64ab-0af0-3f21-8acdcceaa645@oracle.com>

Vote: yes
On 7/9/19 12:13 PM, Phil Race wrote:
> I hereby propose the creation of the Lanai Project to implement a new 
> graphics rendering pipeline for macOS, with Phil Race as the Lead and 
> the 2D Group as the sponsoring Group.


From stuart.marks at oracle.com  Wed Jul 10 22:24:16 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 10 Jul 2019 15:24:16 -0700
Subject: CFV: New Project: Lanai
In-Reply-To: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
References: <1a39b659-ae1d-096c-e64f-58049dcd84ca@oracle.com>
Message-ID: <6c35abcb-168e-f239-7de3-d0db95ea933d@oracle.com>

Vote: yes

On 7/9/19 12:13 PM, Phil Race wrote:
> I hereby propose the creation of the Lanai Project to implement a new graphics 
> rendering pipeline for macOS, with Phil Race as the Lead and the 2D Group as the 
> sponsoring Group.
> 
> Background and Motivation:
> Apple Inc. have created the Metal [1] graphics API designed to be their long 
> term replacement for OpenGL as the rendering pipeline on Apple platforms, 
> including macOS. It promises better performance than OpenGL and simpler GPU 
> designs by being a simpler API without the legacies of OpenGL.
> 
> The JDK, and OpenJFX today both use OpenGL as the rendering pipeline on macOS, 
> but Apple have deprecated OpenGL as of MacOS 10.14 [2], and recommend to 
> transition to Metal.
> If OpenGL is not present on a macOS system, the JDK desktop APIs cannot function 
> and will fail to start. OpenJFX is in a very similar position.
> 
> For some months, engineers from Oracle and JetBrains [3], have been exploring 
> the Metal APIs and working on some proofs of concept, starting with the existing 
> OpenGL pipeline as a base and doing prototyping work in the JDK sandbox [4] in 
> the metal-prototype-branch and in the case of JetBrains, separately on github.
> We have also discussed specific issues on the 2d-dev mailing list and have a 
> wiki page [5].
> 
> However to further collaboration and advance the goals we would like to move 
> this work to a location where we can work together and more engineers can 
> contribute, and therefore propose this project.
> 
> Note: the rendering pipelines in the JDK are internal implementation details, so 
> this project will not create, or otherwise be exposed as, Java APIs
> 
> Phil Race is the lead of the Java 2D group and has worked on the Java 2D APIs 
> for many years as well. He has also made significant contributions to the 
> OpenJFX project and to the Swing and AWT APIs
> 
> Goals of the Project:
> This project will create a Java 2D rendering pipeline for macOS using the Apple 
> Metal APIs which aims to be at least as capable, robust and performant, as the 
> current OpenGL pipeline.
> This project will also be the basis of a similar Metal pipeline for the OpenJFX 
> project [6].
> 
> Initial committers will include
> Phil Race (prr)
> Ajit Ghaisas (aghaisas)
> Jay DV (jdv)
> Sergey Bylokhov (serb)
> Kevin Rushforth (kcr)
> Alexey Ushakov (avu)
> 
> A complete list will be provided to the registrar at the successful conclusion 
> of this CFV.
> 
> Votes are due by 5pm PDT on Tuesday July 23rd 2019.
> 
> Only current OpenJDK Members [7] are eligible to vote on this motion. Votes must 
> be cast in the open on the discuss list.
> Replying to this message is sufficient if your mail program honors the Reply-To 
> header.
> 
> For Lazy Consensus voting instructions, see [8].
> 
> -Phil Race.
> 
> [1] https://developer.apple.com/metal/
> [2] 
> https://developer.apple.com/documentation/macos_release_notes/macos_mojave_10_14_release_notes 
> 
> [3] https://www.jetbrains.com/
> [4] http://hg.openjdk.java.net/jdk/sandbox/
> [5] https://wiki.openjdk.java.net/display/2d/Metal+Graphics+Pipeline+for+MacOS
> [6] http://openjdk.java.net/projects/openjfx/
> [7] http://openjdk.java.net/census#members
> [8] http://openjdk.java.net/projects/#new-project-vote

From mark.reinhold at oracle.com  Mon Jul 15 17:54:30 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 15 Jul 2019 10:54:30 -0700 (PDT)
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
Message-ID: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/357

- Mark

From roman at kennke.org  Mon Jul 15 18:17:20 2019
From: roman at kennke.org (Roman Kennke)
Date: Mon, 15 Jul 2019 20:17:20 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
Message-ID: <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>

Nice.

I find this strange:

""
We will not address the question of whether OpenJDK Git repositories
will be self-hosted or hosted by an external provider. That issue will
be the topic of a future JEP.
""

While I somehow can understand the motivation to break this out, it
leaves me wondering where will the new repos be hosted after all. Or is
that other unnamed JEP intended to become a prerequisite for JEP 357?
This seems impossible too.

In other words: how do you intend to achieve goal#1 "Migrate all
single-repository OpenJDK Projects from Mercurial to Git" without
deciding where to host it? Or else, how/where do you want to host it,
without completing this new JEP 357 first?

Thanks,
Roman

> https://openjdk.java.net/jeps/357
> 
> - Mark
> 

From shade at redhat.com  Mon Jul 15 18:52:02 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Jul 2019 20:52:02 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
Message-ID: <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>

On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
> https://openjdk.java.net/jeps/357

Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
performing this move.

The disadvantages, off the top of my head:
 *) Conversion takes time and effort for all projects, including those developed outside of
mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
 *) Developers who are already quite constrained to deliver things with 6 months pace would have to
re-adjust their workflows, some would need re-training to Git, many would have to accept the
temporary productivity losses, and/or modify their delivery schedules;
 *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
them;

Additionally, not addressed:
 *) Existing hgupdater links in JBS would have to be updated, or they would break;
 *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
with lots of wishful thinking involved -- would break;
 *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
at OpenJDK Committers Workshop in February 2019) is still not enabled:
https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
Mercurial" (sic!).
 *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.

AFAIU, JEPs are supposed to capture the pros and cons, and provide extended background for
discussion for the changes that have wide area of effect. Alas, the JEP 357 does not look to be in
that state at the moment.

-- 
Thanks,
-Aleksey


From neugens at redhat.com  Mon Jul 15 19:04:15 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 15 Jul 2019 21:04:15 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
Message-ID: <CAJwKKmYKj73UqMCuwyQrcQuo4vdk_QMe=pZpLvWBb9XSuvq31g@mail.gmail.com>

I think it should written in the "goals" that one goal is that the
workflow changes will be minimal and non disruptive of the current
workflow, this has been promised multiple times as part of project
Skara, so we should really write it down.

Cheers,
Mario

On Mon, Jul 15, 2019 at 8:53 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
> > https://openjdk.java.net/jeps/357
>
> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
> performing this move.
>
> The disadvantages, off the top of my head:
>  *) Conversion takes time and effort for all projects, including those developed outside of
> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
>  *) Developers who are already quite constrained to deliver things with 6 months pace would have to
> re-adjust their workflows, some would need re-training to Git, many would have to accept the
> temporary productivity losses, and/or modify their delivery schedules;
>  *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
> them;
>
> Additionally, not addressed:
>  *) Existing hgupdater links in JBS would have to be updated, or they would break;
>  *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
> with lots of wishful thinking involved -- would break;
>  *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
> example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
> at OpenJDK Committers Workshop in February 2019) is still not enabled:
> https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
> Mercurial" (sic!).
>  *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
> For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.
>
> AFAIU, JEPs are supposed to capture the pros and cons, and provide extended background for
> discussion for the changes that have wide area of effect. Alas, the JEP 357 does not look to be in
> that state at the moment.
>
> --
> Thanks,
> -Aleksey
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From joe.darcy at oracle.com  Mon Jul 15 19:33:30 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Jul 2019 12:33:30 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>
Message-ID: <f10f4734-f48a-dd47-b48b-3fbd9f01da8a@oracle.com>

Hello,

The intention is to separate the decision of whether not to migrate to 
git from the decision of how to host the git repos, assuming the 
migration occurs.

So there is an implicit dependency between delivering 357 and on a 
yet-to-be- created JEP to discussion git hosting options.

HTH; cheers,

-Joe

On 7/15/2019 11:17 AM, Roman Kennke wrote:
> Nice.
>
> I find this strange:
>
> ""
> We will not address the question of whether OpenJDK Git repositories
> will be self-hosted or hosted by an external provider. That issue will
> be the topic of a future JEP.
> ""
>
> While I somehow can understand the motivation to break this out, it
> leaves me wondering where will the new repos be hosted after all. Or is
> that other unnamed JEP intended to become a prerequisite for JEP 357?
> This seems impossible too.
>
> In other words: how do you intend to achieve goal#1 "Migrate all
> single-repository OpenJDK Projects from Mercurial to Git" without
> deciding where to host it? Or else, how/where do you want to host it,
> without completing this new JEP 357 first?
>
> Thanks,
> Roman
>
>> https://openjdk.java.net/jeps/357
>>
>> - Mark
>>

From roman at kennke.org  Mon Jul 15 19:50:29 2019
From: roman at kennke.org (Roman Kennke)
Date: Mon, 15 Jul 2019 21:50:29 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
Message-ID: <399585f4-afd0-9665-bd5d-19b2e6144802@kennke.org>

>> https://openjdk.java.net/jeps/357
> 
> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
> performing this move.
> 
> The disadvantages, off the top of my head:
>  *) Conversion takes time and effort for all projects, including those developed outside of
> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
>  *) Developers who are already quite constrained to deliver things with 6 months pace would have to
> re-adjust their workflows, some would need re-training to Git, many would have to accept the
> temporary productivity losses, and/or modify their delivery schedules;
>  *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
> them;
> 
> Additionally, not addressed:
>  *) Existing hgupdater links in JBS would have to be updated, or they would break;
>  *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
> with lots of wishful thinking involved -- would break;
>  *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
> example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
> at OpenJDK Committers Workshop in February 2019) is still not enabled:
> https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
> Mercurial" (sic!).
>  *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
> For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.
> 
> AFAIU, JEPs are supposed to capture the pros and cons, and provide extended background for
> discussion for the changes that have wide area of effect. Alas, the JEP 357 does not look to be in
> that state at the moment.

Agreed.

It seems that the very minimum requirement to reach the goals while not
disrupting workflow too much (as promised earlier elsewhere), and let
people adopt to the new git world (if it happens), would be a read-only
one-way bridge that mirrors whatever happens in new git develepment
repos to mercurial. I for one certainly wouldn't like to be forced to
juggle my workflow at a pace that I have no control over, having my own
projects, deadlines, customers, etc to meet.

But more generally, maybe we should discuss the 'if' and 'why' first,
and not the 'how'?

Roman

From joe.darcy at oracle.com  Mon Jul 15 20:10:21 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Jul 2019 13:10:21 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
Message-ID: <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>

Hello,

On 7/15/2019 11:52 AM, Aleksey Shipilev wrote:
> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
>> https://openjdk.java.net/jeps/357
> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
> performing this move.
>
> The disadvantages, off the top of my head:
>   *) Conversion takes time and effort for all projects, including those developed outside of
> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;


Clearly the development processes of the projects in question would have 
to be updated at least slightly if the SCM used for the code is changed. 
Just on an administrative front, several months back as part of Skara 
mirrors of git conversions of Amber, Loom, Panama, etc. were put up on 
github:

 ??? https://github.com/openjdk/amber
 ??? https://github.com/openjdk/loom
 ??? https://github.com/openjdk/panama
 ??? https://github.com/openjdk/portola
 ??? https://github.com/openjdk/shenandoah
 ??? https://github.com/openjdk/valhalla

These are live mirror updated within a few minutes after a push occurs 
to the corresponding hg repo.

>   *) Developers who are already quite constrained to deliver things with 6 months pace would have to
> re-adjust their workflows, some would need re-training to Git, many would have to accept the
> temporary productivity losses, and/or modify their delivery schedules;


Yes; it is true, switching SCMs would involve a nonzero amount of time 
and effort to learn the new tool. This is true independent of the length 
of the release cycle. Since the proposal is to change to the most widely 
used distributed SCM, one that has extensive tooling support, there are 
plenty of learning materials available. Additionally, if there is 
interest, the Skara team could do a "git for recalcitrant hg users" 
online talk.


>   *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
> them;

In September 2018 the JDK build was updated to work with either git or 
hg as the SCM, JDK-8210283.

If there was interest, build pipelines could be created based on the 
existing git mirrors today.

>
> Additionally, not addressed:
>   *) Existing hgupdater links in JBS would have to be updated, or they would break;


There is nothing in the JEP that requires or implies the old hg repos 
need to be destroyed. I would recommend leaving them in place as 
read-only archives. Barring that, I recommend a proxy to rewrite the hg 
links into equivalent git ones. The Skara conversion process includes a 
map of corresponding hashes between the hg and git repos.


>   *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
> with lots of wishful thinking involved -- would break;


Breaking the links could be added as a non-goal of JEP. (I frequently 
use those links myself.)

Cheers,

-Joe


From jonathan.gibbons at oracle.com  Mon Jul 15 21:55:14 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 15 Jul 2019 14:55:14 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
Message-ID: <5a791408-59d9-237e-dda4-0c2e00537796@oracle.com>


On 7/15/19 1:10 PM, Joe Darcy wrote:
> Additionally, if there is interest, the Skara team could do a "git for 
> recalcitrant hg users" online talk. 

Joe,

How about just a basic OpenJDK-oriented cheatsheet ... for the common 
operations that OpenJDK folk are used to doing in Mercurial, show the 
equivalent for Git.

-- Jon


From david.lloyd at redhat.com  Mon Jul 15 22:31:41 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 15 Jul 2019 17:31:41 -0500
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
Message-ID: <CANghgrRcoPfbjri+_6fQrc3MexDh_n+GJEis9ztC-KXiQ_eODQ@mail.gmail.com>

Maybe it would be helpful to categorize the pros and cons as one-time
cost/benefit versus recurring cost/benefit?

On Mon, Jul 15, 2019 at 1:53 PM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
> > https://openjdk.java.net/jeps/357
>
> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
> performing this move.
>
> The disadvantages, off the top of my head:
>  *) Conversion takes time and effort for all projects, including those developed outside of
> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
>  *) Developers who are already quite constrained to deliver things with 6 months pace would have to
> re-adjust their workflows, some would need re-training to Git, many would have to accept the
> temporary productivity losses, and/or modify their delivery schedules;
>  *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
> them;
>
> Additionally, not addressed:
>  *) Existing hgupdater links in JBS would have to be updated, or they would break;
>  *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
> with lots of wishful thinking involved -- would break;
>  *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
> example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
> at OpenJDK Committers Workshop in February 2019) is still not enabled:
> https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
> Mercurial" (sic!).
>  *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
> For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.
>
> AFAIU, JEPs are supposed to capture the pros and cons, and provide extended background for
> discussion for the changes that have wide area of effect. Alas, the JEP 357 does not look to be in
> that state at the moment.
>
> --
> Thanks,
> -Aleksey
>


-- 
- DML

From stuart.marks at oracle.com  Mon Jul 15 23:10:40 2019
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 15 Jul 2019 16:10:40 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
Message-ID: <61feac01-8698-1460-1875-b4e28d58a777@oracle.com>

On 7/15/19 1:10 PM, Joe Darcy wrote:
>> Additionally, not addressed:
>> ? *) Existing hgupdater links in JBS would have to be updated, or they would 
>> break;
> 
> There is nothing in the JEP that requires or implies the old hg repos need to be 
> destroyed. I would recommend leaving them in place as read-only archives. 
> Barring that, I recommend a proxy to rewrite the hg links into equivalent git 
> ones. The Skara conversion process includes a map of corresponding hashes 
> between the hg and git repos.
> 
>> ? *) External links to hg.o.j.n -- that were deemed to be permalinks to the 
>> JDK source code, perhaps
>> with lots of wishful thinking involved -- would break;
> 
> Breaking the links could be added as a non-goal of JEP. (I frequently use those 
> links myself.)

I think it's sensible to address this. Instead of a double negative (breaking 
the links is a non-goal) perhaps it should be added as a positive goal to 
preserve existing links where possible. Note that this doesn't imply that all 
the old hg repos need to be kept around. They could be; or perhaps some kind of 
smart proxy/redirector as mentioned above would be sufficient.

s'marks

From joe.darcy at oracle.com  Tue Jul 16 00:02:52 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Jul 2019 17:02:52 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <5a791408-59d9-237e-dda4-0c2e00537796@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
 <5a791408-59d9-237e-dda4-0c2e00537796@oracle.com>
Message-ID: <25e8600e-24ed-5531-d97d-af6afae3e249@oracle.com>

Hi Jon,

On 7/15/2019 2:55 PM, Jonathan Gibbons wrote:
>
> On 7/15/19 1:10 PM, Joe Darcy wrote:
>> Additionally, if there is interest, the Skara team could do a "git 
>> for recalcitrant hg users" online talk. 
>
> Joe,
>
> How about just a basic OpenJDK-oriented cheatsheet ... for the common 
> operations that OpenJDK folk are used to doing in Mercurial, show the 
> equivalent for Git.
>

Sure; we can produce a cheat sheet for simple cases at least.

Cheers,

-Joe


From weijun.wang at oracle.com  Tue Jul 16 05:48:16 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 16 Jul 2019 13:48:16 +0800
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
Message-ID: <5F94324D-5A3E-4669-9669-FE33C2AD8FE2@oracle.com>



> On Jul 16, 2019, at 4:10 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
> There is nothing in the JEP that requires or implies the old hg repos need to be destroyed. I would recommend leaving them in place as read-only archives.

Is it possible to make it a mirror of the new git repo?

--Max


From shade at redhat.com  Tue Jul 16 07:38:25 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jul 2019 09:38:25 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
Message-ID: <3cd7a898-e897-3b59-5769-a3084cc62d99@redhat.com>

On 7/15/19 10:10 PM, Joe Darcy wrote:
> On 7/15/2019 11:52 AM, Aleksey Shipilev wrote:
>> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
>>> https://openjdk.java.net/jeps/357
>> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
>> performing this move.

This comment of mine still stands very firmly.

>> The disadvantages, off the top of my head:
>> ? *) Conversion takes time and effort for all projects, including those developed outside of
>> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
> 
> Clearly the development processes of the projects in question would have to be updated at least
> slightly if the SCM used for the code is changed. Just on an administrative front, several months
> back as part of Skara mirrors of git conversions of Amber, Loom, Panama, etc. were put up on github:
> 
> ??? ...>
> These are live mirror updated within a few minutes after a push occurs to the corresponding hg repo.

You see, this is the other way around. These are read-only Git mirrors of active Mercurial repos, of
course there is no impact, we can just ignore Git mirrors exist. What JEP proposes is to switch work
to Git mirrors (and maybe have read-only Mercurial repos _tracking_ them? not clear from JEP text),
this would be non-ignorable thing. If you look carefully, your comment does not address my concern
at all.

>> ? *) Developers who are already quite constrained to deliver things with 6 months pace would have to
>> re-adjust their workflows, some would need re-training to Git, many would have to accept the
>> temporary productivity losses, and/or modify their delivery schedules;
> 
> Yes; it is true, switching SCMs would involve a nonzero amount of time and effort to learn the new
> tool. This is true independent of the length of the release cycle. Since the proposal is to change
> to the most widely used distributed SCM, one that has extensive tooling support, there are plenty of
> learning materials available. Additionally, if there is interest, the Skara team could do a "git for
> recalcitrant hg users" online talk.

This should be in JEP text listed as the disadvantage, and it should be discussed, the migration
aids should be listed as JEP deliverables. After that, the JEP should get the buy in from the actual
people who would have to accept this change to their workflow, based on what JEP submitters agreed
to deliver.


>> ? *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
>> them;
> 
> In September 2018 the JDK build was updated to work with either git or hg as the SCM, JDK-8210283.
> If there was interest, build pipelines could be created based on the existing git mirrors today.

This comment does not address my concern. Have Skara team talked to the community builders that use
hg.o.j.n as the source for their builds? Is there a buy in from them? Are the concerns of those
builders heard and mitigations planned for? This is all not clear from the JEP.


>> Additionally, not addressed:
>> ? *) Existing hgupdater links in JBS would have to be updated, or they would break;
> 
> There is nothing in the JEP that requires or implies the  old hg repos need to be destroyed. I would
> recommend leaving them in place as read-only archives. Barring that, I recommend a proxy to rewrite
> the hg links into equivalent git ones. The Skara conversion process includes a map of corresponding
> hashes between the hg and git repos.

So, which one would it be? Mercural repos permanently archived, or rewrite proxy set up, or
something else? It is time to decide now: the JEP should clearly say what would be the deliverable.

>> ? *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
>> with lots of wishful thinking involved -- would break;
> 
> Breaking the links could be added as a non-goal of JEP. (I frequently use those links myself.)

It should be the *goal* to *not* break those links today, or set us up for breakage in future.

----

These two concerns from my original note were not mentioned in the reply at all:

 *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
at OpenJDK Committers Workshop in February 2019) is still not enabled:
https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
Mercurial" (sic!).

 *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Tue Jul 16 08:55:16 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 16 Jul 2019 10:55:16 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
Message-ID: <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>

On Mon, 2019-07-15 at 10:54 -0700, mark.reinhold at oracle.com wrote:
> https://openjdk.java.net/jeps/357

Very cool! Thanks for all the hard work and moving this forward. I, for
one, would very much welcome such a move[*].

Thanks,
Severin

[*] Yes, I'm biased ;-)


From claes.redestad at oracle.com  Tue Jul 16 09:15:36 2019
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 16 Jul 2019 11:15:36 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
Message-ID: <b962d5a9-6cf7-148b-c99b-0576b8f3c363@oracle.com>

On 2019-07-16 10:55, Severin Gehwolf wrote:
> On Mon, 2019-07-15 at 10:54 -0700,mark.reinhold at oracle.com  wrote:
>> https://openjdk.java.net/jeps/357
> Very cool! Thanks for all the hard work and moving this forward. I, for
> one, would very much welcome such a move[*].

+1

> 
> Thanks,
> Severin
> 
> [*] Yes, I'm biased;-)


+1 ;-)

/Claes

From aph at redhat.com  Tue Jul 16 09:27:02 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 16 Jul 2019 10:27:02 +0100
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <3cd7a898-e897-3b59-5769-a3084cc62d99@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
 <3cd7a898-e897-3b59-5769-a3084cc62d99@redhat.com>
Message-ID: <96a9309d-072c-0737-c4c4-60f16517077e@redhat.com>

On 7/16/19 8:38 AM, Aleksey Shipilev wrote:
> On 7/15/19 10:10 PM, Joe Darcy wrote:
>> On 7/15/2019 11:52 AM, Aleksey Shipilev wrote:
>>> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
>>>> https://openjdk.java.net/jeps/357
>>> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
>>> performing this move.
> 
> This comment of mine still stands very firmly.

This is a bit of a "me too", but I have to agree with Aleksey. JEPs
are not just for advocacy: they should be a Fair and Balanced
description of a proposal.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From neugens at redhat.com  Tue Jul 16 09:39:03 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 16 Jul 2019 11:39:03 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
Message-ID: <CAJwKKmbY-4pEgN7BGUH7f7gxi04F0H9cnG-SpC5ELGokE_B3dQ@mail.gmail.com>

There commit message format may be interesting to implement despite
the move to Git, and I would recommend moving this into a separate JEP
and/or implement a mercurial hook perhaps (since a full JEP maybe
overkill, but this should be documented and users should be somehow
assisted).

This address a longer standing issue, especially for backports and
rework of existing patches, but it seems to me only incidental that
the new commit message format is part of this JEP. Also, what is a
"trailer"?

Cheers,
Mario

On Mon, Jul 15, 2019 at 7:55 PM <mark.reinhold at oracle.com> wrote:
>
> https://openjdk.java.net/jeps/357
>
> - Mark



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From neugens at redhat.com  Tue Jul 16 09:49:31 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 16 Jul 2019 11:49:31 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
Message-ID: <CAJwKKmYDnjX6amYecVT4MdkRd0E5V1N5-p08P3ZMyDZSbiM1xQ@mail.gmail.com>

You are doing a lot more work on OpenJDK than I am at the moment, so
it wouldn't feel proper to object to something that makes your life
easier as opposed to being conservative, however there are indeed
issues that the JEP needs to address and the current text doesn't, for
example we already know that there's a viable alternative in using
clonebundles as Alexey mentioned multiple times, however the JEP
doesn't acknowledge this, let alone presenting facts regarding the
benefit of git over mercurial related to tooling support, and from
what I see tooling support and size of the download are the two only
reason to use git (I don't buy the one about hosting, that one doesn't
seem to make much sense for me).

Cheers,
Mario

On Tue, Jul 16, 2019 at 10:56 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> On Mon, 2019-07-15 at 10:54 -0700, mark.reinhold at oracle.com wrote:
> > https://openjdk.java.net/jeps/357
>
> Very cool! Thanks for all the hard work and moving this forward. I, for
> one, would very much welcome such a move[*].
>
> Thanks,
> Severin
>
> [*] Yes, I'm biased ;-)
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From ebourg at apache.org  Tue Jul 16 10:22:39 2019
From: ebourg at apache.org (Emmanuel Bourg)
Date: Tue, 16 Jul 2019 12:22:39 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <CAJwKKmYDnjX6amYecVT4MdkRd0E5V1N5-p08P3ZMyDZSbiM1xQ@mail.gmail.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
 <CAJwKKmYDnjX6amYecVT4MdkRd0E5V1N5-p08P3ZMyDZSbiM1xQ@mail.gmail.com>
Message-ID: <9135c351-f5f4-cd09-bcc0-5a4dc288a376@apache.org>

Le 16/07/2019 ? 11:49, Mario Torre a ?crit?:

> and from what I see tooling support and size 
> of the download are the two only reason to use git
One obvious benefit that is worth mentioning in the JEP I think is that
Git is significantly more popular than Mercurial, and using what becomes
a standard tool lowers the barrier of entry for new contributors. A mere
read-only Git mirror doesn't help unifying the community around a common
set of tools and workflows.

Emmanuel Bourg

From adinn at redhat.com  Tue Jul 16 10:29:02 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 16 Jul 2019 11:29:02 +0100
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
Message-ID: <385bca88-c3e4-3268-fe2f-a18a108bf42e@redhat.com>

Personally, I am quite happy with this change to a different SCM
implementation. Nevertheless, I agree with Aleksey's criticism that the
JEP does not adequately assess potential negative effects of this change.

Anyway, I'm not replying with the intention of hammering on that point,
rather to flag what looks like a grammatical error (sic ;-) in the
Description section. It says:

  . . .
  Trailers : BlankLine Co-authors? Reviewers
  Co-authors : (BlankLine Co-author )+
  Co-author : "Co-authored-by: " Real-name <Email>
  Reviewers : "Reviewed-by: " Username (", " Username)* "\n"
  BlankLine = "\n"

This appears to require that all (optional) co-author attributions
precede all reviewer attributions? If so then the example text that
follows is at odds with this requirement:

  . . .
  Fixed a tricky race condition when the JVM is starting up by using a
Mutex.

  Reviewed-by: darcy
  Co-authored-by: Robin Westberg <rwestberg at openjdk.org>

Of course, the error may be in the grammar itself not the example . . .

regards,


Andrew Dinn
-----------


From vusonlam at t-online.de  Tue Jul 16 10:30:19 2019
From: vusonlam at t-online.de (vusonlam at t-online.de)
Date: Tue, 16 Jul 2019 12:30:19 +0200 (CEST)
Subject: Remove my email from this distributor list
Message-ID: <1563273019370.2769319.531151b7565ae4484c3f9697f6a487c1a0699064@spica.telekom.de>

Hello,
Could you please remove me (vusonlam at t-online.de) from this distributor list.
Thanks.
Regards




-----Original-Nachricht-----
Betreff: Re: New candidate JEP: 357: Migrate from Mercurial to Git
Datum: 2019-07-16T12:26:12+0200
Von: "Emmanuel Bourg" <ebourg at apache.org>
Cc: "discuss at openjdk.java.net" <discuss at openjdk.java.net>

Le 16/07/2019 ? 11:49, Mario Torre a ?crit?:

> and from what I see tooling support and size 
> of the download are the two only reason to use git
One obvious benefit that is worth mentioning in the JEP I think is that
Git is significantly more popular than Mercurial, and using what becomes
a standard tool lowers the barrier of entry for new contributors. A mere
read-only Git mirror doesn't help unifying the community around a common
set of tools and workflows.

Emmanuel Bourg
?

From vijay.pandit.ext at siemens.com  Tue Jul 16 10:31:32 2019
From: vijay.pandit.ext at siemens.com (Pandit (EXT), Vijay)
Date: Tue, 16 Jul 2019 10:31:32 +0000
Subject: JVM heap size issue in openjdk 8.
Message-ID: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>

Hello Team,

Currently my application is compiling using Oracle JDK 7 version and ANT 1.9.5 is used as build tool.

I need to migrate it to openjdk 8. I had set path to openjdk 8 and when try to build it is giving me error as below :

     [java] Error: Could not create the Java Virtual Machine.
     [java] Error: A fatal exception has occurred. Program will exit.
     [java] Invalid maximum heap size: -Xmx4096M
     [java] The specified size exceeds the maximum representable size.

In my ant script I am using as below:

<jvmarg value="-Xmx4096M" />


Please help me to fix this issue.

Thanks
Vijay Pandit

From neugens at redhat.com  Tue Jul 16 10:41:24 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 16 Jul 2019 12:41:24 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <9135c351-f5f4-cd09-bcc0-5a4dc288a376@apache.org>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
 <CAJwKKmYDnjX6amYecVT4MdkRd0E5V1N5-p08P3ZMyDZSbiM1xQ@mail.gmail.com>
 <9135c351-f5f4-cd09-bcc0-5a4dc288a376@apache.org>
Message-ID: <CAJwKKmZnodN0A-vbjibHG39fDSLeJGR2vLzgC3dOVVyf=Mp92g@mail.gmail.com>

On Tue, Jul 16, 2019 at 12:23 PM Emmanuel Bourg <ebourg at apache.org> wrote:
>
> Le 16/07/2019 ? 11:49, Mario Torre a ?crit :
>
> > and from what I see tooling support and size
> > of the download are the two only reason to use git
> One obvious benefit that is worth mentioning in the JEP I think is that
> Git is significantly more popular than Mercurial, and using what becomes
> a standard tool lowers the barrier of entry for new contributors. A mere
> read-only Git mirror doesn't help unifying the community around a common
> set of tools and workflows.

Maybe, but I don't think this is a real problem. The entry barrier to
contribution is high not because of git vs mercurial, but because of
the process itself, even if we were to move to GitHub I doubt that
would change. For example, we still don't allow anyone to file a bug
report on the project bug database unless they are at least Authors
and a bug id is required for any push to take place. Can you see this
changing to allow random push request over GitHub?

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From martijnverburg at gmail.com  Tue Jul 16 12:17:26 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 16 Jul 2019 13:17:26 +0100
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
Message-ID: <CAP7YuARigzJT78+Sr5AcMqrnWEAkZ7ekda2xK=39JrmdADYW4Q@mail.gmail.com>

Hi Vijay,

This mailing list is for meta-discussion about OpenJDK itself. I'd
recommend posting your issue to StackOverflow with the full details of your
configuration files/setup.

Cheers,
Martijn


On Tue, 16 Jul 2019 at 11:32, Pandit (EXT), Vijay <
vijay.pandit.ext at siemens.com> wrote:

> Hello Team,
>
> Currently my application is compiling using Oracle JDK 7 version and ANT
> 1.9.5 is used as build tool.
>
> I need to migrate it to openjdk 8. I had set path to openjdk 8 and when
> try to build it is giving me error as below :
>
>      [java] Error: Could not create the Java Virtual Machine.
>      [java] Error: A fatal exception has occurred. Program will exit.
>      [java] Invalid maximum heap size: -Xmx4096M
>      [java] The specified size exceeds the maximum representable size.
>
> In my ant script I am using as below:
>
> <jvmarg value="-Xmx4096M" />
>
>
> Please help me to fix this issue.
>
> Thanks
> Vijay Pandit
>

From sgehwolf at redhat.com  Tue Jul 16 12:19:10 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 16 Jul 2019 14:19:10 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
Message-ID: <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>

Hi Aleksey,

Source control discussions tend to be very opinionated. I'm not sure
all arguments can be objectively answered let alone quantified. Please
keep that in mind when reading my comments below. Again, as said
elsewhere, I'm biased towards Git.

On Mon, 2019-07-15 at 20:52 +0200, Aleksey Shipilev wrote:
> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
> > https://openjdk.java.net/jeps/357
> 
> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
> performing this move.

Should this JEP go into the details of advantages/disadvantages of HG
vs. Git itself? I wouldn't think so, but your mileage may vary.

> The disadvantages, off the top of my head:
>  *) Conversion takes time and effort for all projects, including those developed outside of
> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;

I think many of those have been converted already for somebody to take
a look:

Amber: https://github.com/openjdk/amber
Shenandoah: https://github.com/openjdk/shenandoah
Panama: https://github.com/openjdk/panama
Portola: https://github.com/openjdk/portola
Valhalla: https://github.com/openjdk/valhalla
Loom: https://github.com/openjdk/loom

Perhaps it would be reasonable to provide some info on how those
repositories got converted and how much time it to to convert them.
This would allow involved parties to ball-park estimate their up-front
conversion work.

>  *) Developers who are already quite constrained to deliver things with 6 months pace would have to
> re-adjust their workflows, some would need re-training to Git, many would have to accept the
> temporary productivity losses, and/or modify their delivery schedules;

Right. As David Lloyd said, this seems to be a one-time investment.
Consider 3 years down the line after a conversion, would you still have
a productivity loss?

>  *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
> them;

Could you perhaps in more detail explain what bearing source control
has on the actual building of projects? I understand that source code
has to get fetched somewhere, but once local, the build pipeline would
work in a similar fashion beyond that point, right?

FWIW, for Fedora fresh source tarball clones (package updates) would be
significantly faster via git shallow clones (we don't need the history
at all, just the source code).

> Additionally, not addressed:
>  *) Existing hgupdater links in JBS would have to be updated, or they would break;

Only if current mercurial repositories cease to exist entirely, I'd
think, no?

>  *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
> with lots of wishful thinking involved -- would break;

Consider preserving old HG repositories at hg.o.j.n. If they'd be read-
only, old links would still work.

>  *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
> example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
> at OpenJDK Committers Workshop in February 2019) is still not enabled:
> https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
> Mercurial" (sic!).

That's a valid alternative measure. It would not address the *local*
storage requirements though, would it? The JEP says:

"""
For example, the .git directory of
the jdk/jdk repository is approximately 300 MB with Git and the .hg directory
is around 1.2 GB with Mercurial, depending on the Mercurial version being used.
"""

>  *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
> For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.

I wonder how the "builtin" vs. "available via extensions" compare for
those. Does somebody know?

Looking at the 3 primary reasons for migrating to Git:

 * Size of version control system metadata

Local metadata storage: That is, size of local metadata in .git/.hg
where Git seems to win.
Fresh clone times: Git has fewer metadata to transfer (above). JDK-
8211383 could help for Mercurial how does it compare? Is there a
"shallow" clone option for mercurial? The JEP seems to allude it's not
present in HG[1].

 * Available tooling

Git:       https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
Mercurial: https://www.mercurial-scm.org/wiki/OtherTools

 * Available hosting

Mercurial: https://www.mercurial-scm.org/wiki/MercurialHosting
Git:       https://git.wiki.kernel.org/index.php/GitHosting

Thanks,
Severin

[1] https://www.mercurial-scm.org/wiki/ShallowClonePlan
> 


From scolebourne at joda.org  Tue Jul 16 12:41:11 2019
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 16 Jul 2019 13:41:11 +0100
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
Message-ID: <CACzrW9DzLUoDfz4o55Hfw2X2e-LNdJQ6b=N2YQDc==chZUWzpw@mail.gmail.com>

Thanks for progressing this. I view git as essential to the future of
OpenJDK, so I'm a strong supporter of the move.
Stephen


On Mon, 15 Jul 2019 at 18:55, <mark.reinhold at oracle.com> wrote:
>
> https://openjdk.java.net/jeps/357
>
> - Mark

From kevin.rushforth at oracle.com  Tue Jul 16 12:57:31 2019
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 16 Jul 2019 05:57:31 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <CAJwKKmZnodN0A-vbjibHG39fDSLeJGR2vLzgC3dOVVyf=Mp92g@mail.gmail.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
 <CAJwKKmYDnjX6amYecVT4MdkRd0E5V1N5-p08P3ZMyDZSbiM1xQ@mail.gmail.com>
 <9135c351-f5f4-cd09-bcc0-5a4dc288a376@apache.org>
 <CAJwKKmZnodN0A-vbjibHG39fDSLeJGR2vLzgC3dOVVyf=Mp92g@mail.gmail.com>
Message-ID: <bb9fa79c-548f-579a-3df8-d7eeb5b74e78@oracle.com>

We setup a developer "sandbox" mirror repo on GitHub [1] for the OpenJFX 
project a while ago to see if that would encourage more community 
participation. We configured it so that only OpenJFX Project Committers 
can merge pull requests, and the CONTRIBUTING guidelines [2] are such 
that we follow all OpenJDK processes: we require an OCA from all 
Contributors, a JBS bug ID, an RFR email to the openjfx-dev mailing 
list, etc., and the final changeset is still pushed to 
hg.openjdk.java.net as usual. This GitHub sandbox is effectively an 
alternative to posting webrevs on cr.openjdk.java.net.

I was initially a little skeptical that this would increase community 
participation, but it has done so significantly, by lowering the barrier 
to entry (although obviously not so low that we accept random pull 
requests). I am very much looking forward to the switch to git, and 
seeing project Skara move forward.

-- Kevin

[1] https://github.com/javafxports/openjdk-jfx
[2] 
https://github.com/javafxports/openjdk-jfx/blob/develop/.github/CONTRIBUTING.md


On 7/16/2019 3:41 AM, Mario Torre wrote:
> On Tue, Jul 16, 2019 at 12:23 PM Emmanuel Bourg <ebourg at apache.org> wrote:
>> Le 16/07/2019 ? 11:49, Mario Torre a ?crit :
>>
>>> and from what I see tooling support and size
>>> of the download are the two only reason to use git
>> One obvious benefit that is worth mentioning in the JEP I think is that
>> Git is significantly more popular than Mercurial, and using what becomes
>> a standard tool lowers the barrier of entry for new contributors. A mere
>> read-only Git mirror doesn't help unifying the community around a common
>> set of tools and workflows.
> Maybe, but I don't think this is a real problem. The entry barrier to
> contribution is high not because of git vs mercurial, but because of
> the process itself, even if we were to move to GitHub I doubt that
> would change. For example, we still don't allow anyone to file a bug
> report on the project bug database unless they are at least Authors
> and a bug id is required for any push to take place. Can you see this
> changing to allow random push request over GitHub?
>
> Cheers,
> Mario
>
>


From aph at redhat.com  Tue Jul 16 13:21:22 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 16 Jul 2019 14:21:22 +0100
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
Message-ID: <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>

On 7/16/19 11:31 AM, Pandit (EXT), Vijay wrote:

> Currently my application is compiling using Oracle JDK 7 version and ANT 1.9.5 is used as build tool.
> 
> I need to migrate it to openjdk 8. I had set path to openjdk 8 and when try to build it is giving me error as below :
> 
>      [java] Error: Could not create the Java Virtual Machine.
>      [java] Error: A fatal exception has occurred. Program will exit.
>      [java] Invalid maximum heap size: -Xmx4096M
>      [java] The specified size exceeds the maximum representable size.
> 
> In my ant script I am using as below:
> 
> <jvmarg value="-Xmx4096M" />

Are you sure you're not running a 32-bit JVM? What does java -version say?

It should say this:

openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)

not this:

openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK Server VM (build 25.212-b04, mixed mode)

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From vijay.pandit.ext at siemens.com  Tue Jul 16 13:28:24 2019
From: vijay.pandit.ext at siemens.com (Pandit (EXT), Vijay)
Date: Tue, 16 Jul 2019 13:28:24 +0000
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
 <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
Message-ID: <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>

Thanks Andrew for you response.


 Below is the command:

D:\UDU\scf\openJDK\rfx>java -version
openjdk version "1.8.0_40"
OpenJDK Runtime Environment (build 1.8.0_40-b25)
OpenJDK Client VM (build 25.40-b25, mixed mode)

Is this 32 bit or 64 bit JVM ?

Thanks
Vijay


-----Original Message-----
From: Andrew Haley <aph at redhat.com> 
Sent: Tuesday, July 16, 2019 6:51 PM
To: Pandit (EXT), Vijay (DI SW LCS APPS SA&S) <vijay.pandit.ext at siemens.com>; discuss at openjdk.java.net
Subject: Re: JVM heap size issue in openjdk 8.

On 7/16/19 11:31 AM, Pandit (EXT), Vijay wrote:

> Currently my application is compiling using Oracle JDK 7 version and ANT 1.9.5 is used as build tool.
> 
> I need to migrate it to openjdk 8. I had set path to openjdk 8 and when try to build it is giving me error as below :
> 
>      [java] Error: Could not create the Java Virtual Machine.
>      [java] Error: A fatal exception has occurred. Program will exit.
>      [java] Invalid maximum heap size: -Xmx4096M
>      [java] The specified size exceeds the maximum representable size.
> 
> In my ant script I am using as below:
> 
> <jvmarg value="-Xmx4096M" />

Are you sure you're not running a 32-bit JVM? What does java -version say?

It should say this:

openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04) OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)

not this:

openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04) OpenJDK Server VM (build 25.212-b04, mixed mode)

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From thomas.schatzl at oracle.com  Tue Jul 16 14:01:10 2019
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 16 Jul 2019 16:01:10 +0200
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
 <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
 <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>
Message-ID: <ddf75a72124bde6ab8a1218e5d098529bd2570b5.camel@oracle.com>

Hi,

On Tue, 2019-07-16 at 13:28 +0000, Pandit (EXT), Vijay wrote:
> Thanks Andrew for you response.
> 
> 
>  Below is the command:
> 
> D:\UDU\scf\openJDK\rfx>java -version
> openjdk version "1.8.0_40"
> OpenJDK Runtime Environment (build 1.8.0_40-b25)
> OpenJDK Client VM (build 25.40-b25, mixed mode)
> 
> Is this 32 bit or 64 bit JVM ?

  32 bit.

Thomas



From shade at redhat.com  Tue Jul 16 14:23:43 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jul 2019 16:23:43 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
Message-ID: <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>

On 7/16/19 2:19 PM, Severin Gehwolf wrote:
>> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
>> performing this move.
> 
> Should this JEP go into the details of advantages/disadvantages of HG
> vs. Git itself? I wouldn't think so, but your mileage may vary.

No, but it should discuss both positive and negative impacts on the OpenJDK project. I don't mind
switching to Git in principle, *BUT* for the project of OpenJDK scale, we should do it based on
accurate cost/benefit assessment, and the complete list of mitigations to minimize the cost. I
believe this move is a heavily disruptive change, and should be treated with the utmost caution. The
JEP text does not leave the impression it is the case.


>>  *) Developers who are already quite constrained to deliver things with 6 months pace would have to
>> re-adjust their workflows, some would need re-training to Git, many would have to accept the
>> temporary productivity losses, and/or modify their delivery schedules;
> 
> Right. As David Lloyd said, this seems to be a one-time investment.
> Consider 3 years down the line after a conversion, would you still have
> a productivity loss?

Look at it this way: I routinely deal with multiple JDK release trains.

They are:
 * 8u: Mercurial forest
 * 9u+: Mercurial forest with major Jigsaw-inspired reshuffling
 * 10u+: Mercurial monorepo with yet another major reshuffling
 * 14+: Git monorepo (?)

The cost of moving the changes between these differently shaped repos is significant. Here, 8u is
way over "3 years down the line", and we are still paying the cost. I cannot honestly say
introducing another repo shape would simplify this story in foreseeable future. This is the cost
maintainers would pay for quite a long time, and it should be acknowledged and agreed upon.

>>  *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
>> them;
> 
> Could you perhaps in more detail explain what bearing source control
> has on the actual building of projects? I understand that source code
> has to get fetched somewhere, but once local, the build pipeline would
> work in a similar fashion beyond that point, right?
> 
> FWIW, for Fedora fresh source tarball clones (package updates) would be
> significantly faster via git shallow clones (we don't need the history
> at all, just the source code).

I am much more concerned about builders who have to retarget their build pipelines, and not
accidentally building from the old/archived read-only Mercurial mirror. Recent debacles about tags
even within one repo point to the possibility of this. Perhaps there is a way to reject connections
to hgserver from the clients (thus breaking automatic scripts), but still allow connections to
hg-web (thus retaining the web links)?

But all of this speculates on how the transition is handled, because it is not really covered in
current JEP text.

>> Additionally, not addressed:
>>  *) Existing hgupdater links in JBS would have to be updated, or they would break;
> 
> Only if current mercurial repositories cease to exist entirely, I'd
> think, no?

Yes. And we know they did disappear before. Try to follow the hgupdater comment that points to
jdk/hs-comp, for example. I don't see the agreement anywhere that Mercurial repos would stay put for
links to work after the conversion. It should be explicitly written down and agreed upon.


>>  *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
>> example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
>> at OpenJDK Committers Workshop in February 2019) is still not enabled:
>> https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
>> Mercurial" (sic!).
> 
> That's a valid alternative measure. It would not address the *local*
> storage requirements though, would it? The JEP says:
> 
> """
> For example, the .git directory of
> the jdk/jdk repository is approximately 300 MB with Git and the .hg directory
> is around 1.2 GB with Mercurial, depending on the Mercurial version being used.
> """

Yes. Most of those 1.2 GB is self-inflicted damage due to major moves in 9 and 10. Still, I wonder
how bad that actually is, considering the non-transparent alternative conversion. I have 20 separate
JDK trees on my work machine, so I pay about 15..20 GB extra disk space for the benefit of not
breaking my workflow -- would gladly pay twice as much.

Also, we are checking out workspaces to actually build them. And if you do, you would need
additional 6 GB per build, and that would be the major disk space hog during development.

> Fresh clone times: Git has fewer metadata to transfer (above). JDK-
> 8211383 could help for Mercurial how does it compare? 

Last I checked, jdk-jdk zstd bundle is about 260 MB. This is roughly how much data transfer would
happen with clonebundles.

> Is there a "shallow" clone option for mercurial? The JEP seems to allude it's not
> present in HG[1].

Facebook solved it with remotefilelog:
  https://bitbucket.org/facebook/hg-experimental/src/default/remotefilelog/


-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jul 16 15:36:51 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jul 2019 17:36:51 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
Message-ID: <4e56ad25-6098-3cb1-619a-6178ff9c2191@redhat.com>

On 7/16/19 4:23 PM, Aleksey Shipilev wrote:
> On 7/16/19 2:19 PM, Severin Gehwolf wrote:
>> Fresh clone times: Git has fewer metadata to transfer (above). JDK-
>> 8211383 could help for Mercurial how does it compare? 
> 
> Last I checked, jdk-jdk zstd bundle is about 260 MB. This is roughly how much data transfer would
> happen with clonebundles.

For fun, redid the cloning experiment with clonebundles vs current Git mirror here:
  https://bugs.openjdk.java.net/browse/JDK-8211383?focusedCommentId=14278459#comment-14278459

Amusingly, Mercurial with clonebundles gets me less total bandwidth than Git checkout, even after
Mercurial client did two transfers: the bundle itself, and several months of changesets on top. So
if we do care about transfer overhead, then migrating from (improved) Mercurial to Git is the
pessimisation, especially for slow links.

See how "Alternatives" section gets curiouser and curiouser.

-- 
Thanks,
-Aleksey


From david.lloyd at redhat.com  Tue Jul 16 15:41:38 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 16 Jul 2019 10:41:38 -0500
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <4e56ad25-6098-3cb1-619a-6178ff9c2191@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
 <4e56ad25-6098-3cb1-619a-6178ff9c2191@redhat.com>
Message-ID: <CANghgrRV6_=EyhhjXzwGTYUDDo=_OS6-nrxGV+AsRUVZ9Qj6CQ@mail.gmail.com>

FWIW you can "seed" your clone if you have another one handy by
cloning the local directory e.g. "git clone -o local ../other-checkout
new-checkout".  Then fetching the upstream will only fetch objects
that weren't in "other-checkout".  I do this frequently for large
repositories, which is especially useful in laptop-in-coffee-shop
kinds of situations.

On Tue, Jul 16, 2019 at 10:37 AM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 7/16/19 4:23 PM, Aleksey Shipilev wrote:
> > On 7/16/19 2:19 PM, Severin Gehwolf wrote:
> >> Fresh clone times: Git has fewer metadata to transfer (above). JDK-
> >> 8211383 could help for Mercurial how does it compare?
> >
> > Last I checked, jdk-jdk zstd bundle is about 260 MB. This is roughly how much data transfer would
> > happen with clonebundles.
>
> For fun, redid the cloning experiment with clonebundles vs current Git mirror here:
>   https://bugs.openjdk.java.net/browse/JDK-8211383?focusedCommentId=14278459#comment-14278459
>
> Amusingly, Mercurial with clonebundles gets me less total bandwidth than Git checkout, even after
> Mercurial client did two transfers: the bundle itself, and several months of changesets on top. So
> if we do care about transfer overhead, then migrating from (improved) Mercurial to Git is the
> pessimisation, especially for slow links.
>
> See how "Alternatives" section gets curiouser and curiouser.
>
> --
> Thanks,
> -Aleksey
>


-- 
- DML

From david.lloyd at redhat.com  Tue Jul 16 15:44:45 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 16 Jul 2019 10:44:45 -0500
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <CANghgrRV6_=EyhhjXzwGTYUDDo=_OS6-nrxGV+AsRUVZ9Qj6CQ@mail.gmail.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
 <4e56ad25-6098-3cb1-619a-6178ff9c2191@redhat.com>
 <CANghgrRV6_=EyhhjXzwGTYUDDo=_OS6-nrxGV+AsRUVZ9Qj6CQ@mail.gmail.com>
Message-ID: <CANghgrSRQOHFSM1pg-Mky07=WQ3-MyZ+GWr1uLkAvbkk=J0F9Q@mail.gmail.com>

Similarly if you have another system nearby with a checkout, the
native SSH support of Git lets you easily clone it:

$ git clone -o workstation workstation:src/openjdk

And, having the remote created like this means that whenever you're
proximate to that system, you can push and pull directly to/from it,
which is very handy when you're working on something on your laptop
and want to push it over to a bigger system for testing.

On Tue, Jul 16, 2019 at 10:41 AM David Lloyd <david.lloyd at redhat.com> wrote:
>
> FWIW you can "seed" your clone if you have another one handy by
> cloning the local directory e.g. "git clone -o local ../other-checkout
> new-checkout".  Then fetching the upstream will only fetch objects
> that weren't in "other-checkout".  I do this frequently for large
> repositories, which is especially useful in laptop-in-coffee-shop
> kinds of situations.
>
> On Tue, Jul 16, 2019 at 10:37 AM Aleksey Shipilev <shade at redhat.com> wrote:
> >
> > On 7/16/19 4:23 PM, Aleksey Shipilev wrote:
> > > On 7/16/19 2:19 PM, Severin Gehwolf wrote:
> > >> Fresh clone times: Git has fewer metadata to transfer (above). JDK-
> > >> 8211383 could help for Mercurial how does it compare?
> > >
> > > Last I checked, jdk-jdk zstd bundle is about 260 MB. This is roughly how much data transfer would
> > > happen with clonebundles.
> >
> > For fun, redid the cloning experiment with clonebundles vs current Git mirror here:
> >   https://bugs.openjdk.java.net/browse/JDK-8211383?focusedCommentId=14278459#comment-14278459
> >
> > Amusingly, Mercurial with clonebundles gets me less total bandwidth than Git checkout, even after
> > Mercurial client did two transfers: the bundle itself, and several months of changesets on top. So
> > if we do care about transfer overhead, then migrating from (improved) Mercurial to Git is the
> > pessimisation, especially for slow links.
> >
> > See how "Alternatives" section gets curiouser and curiouser.
> >
> > --
> > Thanks,
> > -Aleksey
> >
>
>
> --
> - DML



-- 
- DML

From shade at redhat.com  Tue Jul 16 15:48:36 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jul 2019 17:48:36 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <CANghgrRV6_=EyhhjXzwGTYUDDo=_OS6-nrxGV+AsRUVZ9Qj6CQ@mail.gmail.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
 <4e56ad25-6098-3cb1-619a-6178ff9c2191@redhat.com>
 <CANghgrRV6_=EyhhjXzwGTYUDDo=_OS6-nrxGV+AsRUVZ9Qj6CQ@mail.gmail.com>
Message-ID: <9f2b0300-c4af-715f-83da-afc7b25e9eaf@redhat.com>

On 7/16/19 5:41 PM, David Lloyd wrote:
> FWIW you can "seed" your clone if you have another one handy by
> cloning the local directory e.g. "git clone -o local ../other-checkout
> new-checkout".  Then fetching the upstream will only fetch objects
> that weren't in "other-checkout".  I do this frequently for large
> repositories, which is especially useful in laptop-in-coffee-shop
> kinds of situations.

Yes, but we are comparing "fresh clone from master server" use case here. I carry around tarballs of
Mercurial workspaces from https://builds.shipilev.net/workspaces/, and it is also blazingly fast.
But that misses the point I want to make.

-- 
Thanks,
-Aleksey


From david.lloyd at redhat.com  Tue Jul 16 15:58:42 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 16 Jul 2019 10:58:42 -0500
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <9f2b0300-c4af-715f-83da-afc7b25e9eaf@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
 <4e56ad25-6098-3cb1-619a-6178ff9c2191@redhat.com>
 <CANghgrRV6_=EyhhjXzwGTYUDDo=_OS6-nrxGV+AsRUVZ9Qj6CQ@mail.gmail.com>
 <9f2b0300-c4af-715f-83da-afc7b25e9eaf@redhat.com>
Message-ID: <CANghgrQ+QxhF_taU6oqo_Ot-9WbCnsfoLnqF0f6FXEscq7apRw@mail.gmail.com>

On Tue, Jul 16, 2019 at 10:48 AM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 7/16/19 5:41 PM, David Lloyd wrote:
> > FWIW you can "seed" your clone if you have another one handy by
> > cloning the local directory e.g. "git clone -o local ../other-checkout
> > new-checkout".  Then fetching the upstream will only fetch objects
> > that weren't in "other-checkout".  I do this frequently for large
> > repositories, which is especially useful in laptop-in-coffee-shop
> > kinds of situations.
>
> Yes, but we are comparing "fresh clone from master server" use case here. I carry around tarballs of
> Mercurial workspaces from https://builds.shipilev.net/workspaces/, and it is also blazingly fast.
> But that misses the point I want to make.

Generally with Git there is no value in a fresh clone from master
unless you well and truly have no other checkouts anywhere (or the
project is small, which is not the case here).  It would be very
unusual for a developer to be *required* to clone from upstream more
than one time unless they were developing from a new, empty system and
didn't have reasonable access to any other system that had a clone.  I
am trying to recall a time when that was the case for me and failing:
the first thing I do before I travel is to re-fetch everything I'm
likely to be working on.  I don't think this use case is particularly
impactful unless we're talking orders-of-magnitude difference, and
even in that case it would be pretty mitigable without straying from
completely normal and idiomatic Git practices.  Normally for a large
project, you would clone something local, then fetch upstream to get
the most recent commits (which would be a tiny fraction of the overall
bandwidth).

Having tarballs of workspaces is not something a Git user would
normally need do for any reason, regardless of the size of the
project.

-- 
- DML

From shade at redhat.com  Tue Jul 16 16:13:36 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jul 2019 18:13:36 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <CANghgrQ+QxhF_taU6oqo_Ot-9WbCnsfoLnqF0f6FXEscq7apRw@mail.gmail.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
 <4e56ad25-6098-3cb1-619a-6178ff9c2191@redhat.com>
 <CANghgrRV6_=EyhhjXzwGTYUDDo=_OS6-nrxGV+AsRUVZ9Qj6CQ@mail.gmail.com>
 <9f2b0300-c4af-715f-83da-afc7b25e9eaf@redhat.com>
 <CANghgrQ+QxhF_taU6oqo_Ot-9WbCnsfoLnqF0f6FXEscq7apRw@mail.gmail.com>
Message-ID: <7adc60f7-ec3a-e140-9c0d-afcf69bac400@redhat.com>

On 7/16/19 5:58 PM, David Lloyd wrote:
> On Tue, Jul 16, 2019 at 10:48 AM Aleksey Shipilev <shade at redhat.com> wrote:
>> Yes, but we are comparing "fresh clone from master server" use case here. I carry around tarballs of
>> Mercurial workspaces from https://builds.shipilev.net/workspaces/, and it is also blazingly fast.
>> But that misses the point I want to make.
> 
> Generally with Git there is no value in a fresh clone from master
> unless you well and truly have no other checkouts anywhere (or the
> project is small, which is not the case here).  It would be very
> unusual for a developer to be *required* to clone from upstream more
> than one time unless they were developing from a new, empty system and
> didn't have reasonable access to any other system that had a clone. 

Neither does Mercurial for local development. But here we are, comparing clone performance. I find
myself doing fresh JDK clones very often across multiple systems -- this is why I maintain my stash
of Mercurial workspace tarballs.

See what JEP says here: "The reduction in metadata preserves local disk space and ***reduces clone
times, since fewer bits have to go over the wire.***". It seems to conflate on-the-wire size and
on-the-disk size. My experiment shows that claim is problematic: the amount of bits going over the
wire is lower for fresh clones with clonebundles. I suspect that additive pulls into the local repo
produce much less on-the-wire traffic to really care.

Don't you agree with that point?

-- 
Thanks,
-Aleksey


From joe.darcy at oracle.com  Tue Jul 16 16:26:07 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 16 Jul 2019 09:26:07 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <3cd7a898-e897-3b59-5769-a3084cc62d99@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
 <3cd7a898-e897-3b59-5769-a3084cc62d99@redhat.com>
Message-ID: <8758f78f-8ae0-b028-1531-b7dd71d8adf7@oracle.com>

On 7/16/2019 12:38 AM, Aleksey Shipilev wrote:
> On 7/15/19 10:10 PM, Joe Darcy wrote:
>> On 7/15/2019 11:52 AM, Aleksey Shipilev wrote:
>>> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
>>>> https://openjdk.java.net/jeps/357
>>> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
>>> performing this move.
> This comment of mine still stands very firmly.
>
>>> The disadvantages, off the top of my head:
>>>  ? *) Conversion takes time and effort for all projects, including those developed outside of
>>> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
>> Clearly the development processes of the projects in question would have to be updated at least
>> slightly if the SCM used for the code is changed. Just on an administrative front, several months
>> back as part of Skara mirrors of git conversions of Amber, Loom, Panama, etc. were put up on github:
>>
>>  ??? ...>
>> These are live mirror updated within a few minutes after a push occurs to the corresponding hg repo.
> You see, this is the other way around. These are read-only Git mirrors of active Mercurial repos, of
> course there is no impact, we can just ignore Git mirrors exist. What JEP proposes is to switch work
> to Git mirrors (and maybe have read-only Mercurial repos _tracking_ them? not clear from JEP text),
> this would be non-ignorable thing. If you look carefully, your comment does not address my concern
> at all.


Yes, I understand the difference between a git mirror of an hg master 
and a hg mirror of a git master.


>>>  ? *) Developers who are already quite constrained to deliver things with 6 months pace would have to
>>> re-adjust their workflows, some would need re-training to Git, many would have to accept the
>>> temporary productivity losses, and/or modify their delivery schedules;


[snip]


>>>  ? *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
>>> them;


To be more explicit, the potential crunch associated with an SCM 
migration can be lessened if the tasks associated with the migration are 
spread out over time and, if downstream builders were interested in 
doing experiments to see what refitting their pipelines would involve, 
that work can occur today since there are live git mirrors to work from.

-Joe


From joe.darcy at oracle.com  Tue Jul 16 22:33:07 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 16 Jul 2019 15:33:07 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
Message-ID: <c346cdb6-9d3d-19d4-4822-e2357f1f751e@oracle.com>


On 7/16/2019 7:23 AM, Aleksey Shipilev wrote:
> On 7/16/19 2:19 PM, Severin Gehwolf wrote:

[snip]


>>> Additionally, not addressed:
>>>   *) Existing hgupdater links in JBS would have to be updated, or they would break;
>> Only if current mercurial repositories cease to exist entirely, I'd
>> think, no?
> Yes. And we know they did disappear before. Try to follow the hgupdater comment that points to
> jdk/hs-comp, for example. I don't see the agreement anywhere that Mercurial repos would stay put for
> links to work after the conversion. It should be explicitly written down and agreed upon.

Some of the integration repos were deleted (e.g. jdk/hs-comp, tl), but 
the master repos for a release remain. Consequently, the last hgupdater 
link should still be valid. Under old model (and still today for client 
fix), there is a first hgupdater comment when a fix is pushed to an 
integration repo (marker fixed in build value "team") and a final 
hgupdate comment when the fix goes into the master repo (marker fixed in 
build value "master").

-Joe



From joe.darcy at oracle.com  Wed Jul 17 00:11:43 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 16 Jul 2019 17:11:43 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <ecec58d8-4b18-7755-ff8c-5946f79d9b8f@redhat.com>
Message-ID: <24bbfcbe-c040-7a7c-e287-0c00b3b12273@oracle.com>

Hello,

On 7/16/2019 7:23 AM, Aleksey Shipilev wrote:
> On 7/16/19 2:19 PM, Severin Gehwolf wrote:
>
[snip]

>>>   *) Developers who are already quite constrained to deliver things with 6 months pace would have to
>>> re-adjust their workflows, some would need re-training to Git, many would have to accept the
>>> temporary productivity losses, and/or modify their delivery schedules;
>> Right. As David Lloyd said, this seems to be a one-time investment.
>> Consider 3 years down the line after a conversion, would you still have
>> a productivity loss?
> Look at it this way: I routinely deal with multiple JDK release trains.
>
> They are:
>   * 8u: Mercurial forest
>   * 9u+: Mercurial forest with major Jigsaw-inspired reshuffling
>   * 10u+: Mercurial monorepo with yet another major reshuffling
>   * 14+: Git monorepo (?)
>
> The cost of moving the changes between these differently shaped repos is significant. Here, 8u is
> way over "3 years down the line", and we are still paying the cost. I cannot honestly say
> introducing another repo shape would simplify this story in foreseeable future. This is the cost
> maintainers would pay for quite a long time, and it should be acknowledged and agreed upon.

There is a saying along the lines of "the best time to plant a tree is 
twenty years ago; the second best now time now."

Slides 10 through 27 of [1], given at the August OCW last year, 
summarize the changes in SCM usage from JDK 8 (graph of integration hg 
forests) to JDK 12 (most developers push directly to a single hg master 
repo).

Assuming you agree the shared monorepo is structurally preferable to the 
collection of team forests (modulo cloning issues), what other sort of 
path do you suggest to get from one arrangement to another? I can easily 
imagine a criticism of "trying to do too much at once" if coalescing 
some of the intermediate steps was proposed instead.

Or do you think the overheads associated with those changes are too high?

These kinds of changes are never especially convenient to make, but if 
they are never made, we can never get the benefits of them either.

(The maintenance costs would be reduced if the older release trains 
weren't maintained as long, but people want to use the older releases 
too of course.)

Cheers,

-Joe

[1] "Call for Discussion: Project Skara
Investigating source code management options for the JDK sources"

http://cr.openjdk.java.net/~darcy/Presentations/ocw-2018-08-01-skara.pdf


From joe.darcy at oracle.com  Wed Jul 17 00:34:26 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 16 Jul 2019 17:34:26 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <385bca88-c3e4-3268-fe2f-a18a108bf42e@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <385bca88-c3e4-3268-fe2f-a18a108bf42e@redhat.com>
Message-ID: <5349a811-9007-6bfd-368f-2921119131aa@oracle.com>

Hi Andrew,

Ah yes, typo in the example; the Reviewers line should be last after any 
co-authors. This is the format used in the repo imports like 
https://github.com/openjdk/jdk.

Corrected the JEP text; thanks,

-Joe

On 7/16/2019 3:29 AM, Andrew Dinn wrote:
> Personally, I am quite happy with this change to a different SCM
> implementation. Nevertheless, I agree with Aleksey's criticism that the
> JEP does not adequately assess potential negative effects of this change.
>
> Anyway, I'm not replying with the intention of hammering on that point,
> rather to flag what looks like a grammatical error (sic ;-) in the
> Description section. It says:
>
>    . . .
>    Trailers : BlankLine Co-authors? Reviewers
>    Co-authors : (BlankLine Co-author )+
>    Co-author : "Co-authored-by: " Real-name <Email>
>    Reviewers : "Reviewed-by: " Username (", " Username)* "\n"
>    BlankLine = "\n"
>
> This appears to require that all (optional) co-author attributions
> precede all reviewer attributions? If so then the example text that
> follows is at odds with this requirement:
>
>    . . .
>    Fixed a tricky race condition when the JVM is starting up by using a
> Mutex.
>
>    Reviewed-by: darcy
>    Co-authored-by: Robin Westberg <rwestberg at openjdk.org>
>
> Of course, the error may be in the grammar itself not the example . . .
>
> regards,
>
>
> Andrew Dinn
> -----------
>

From vijay.pandit.ext at siemens.com  Wed Jul 17 07:06:20 2019
From: vijay.pandit.ext at siemens.com (Pandit (EXT), Vijay)
Date: Wed, 17 Jul 2019 07:06:20 +0000
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <ddf75a72124bde6ab8a1218e5d098529bd2570b5.camel@oracle.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
 <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
 <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>
 <ddf75a72124bde6ab8a1218e5d098529bd2570b5.camel@oracle.com>
Message-ID: <204039729B95B74D83C33FD9FC95170B017680F9@INPNMMBX002.net.plm.eds.com>

Can I download "RI Source Code" from https://jdk.java.net/java-se-ri/8 for openjdk8 64 bit?

Thanks
Vijay


-----Original Message-----
From: Thomas Schatzl <thomas.schatzl at oracle.com> 
Sent: Tuesday, July 16, 2019 7:31 PM
To: Pandit (EXT), Vijay (DI SW LCS APPS SA&S) <vijay.pandit.ext at siemens.com>; Andrew Haley <aph at redhat.com>; discuss at openjdk.java.net
Subject: Re: JVM heap size issue in openjdk 8.

Hi,

On Tue, 2019-07-16 at 13:28 +0000, Pandit (EXT), Vijay wrote:
> Thanks Andrew for you response.
> 
> 
>  Below is the command:
> 
> D:\UDU\scf\openJDK\rfx>java -version
> openjdk version "1.8.0_40"
> OpenJDK Runtime Environment (build 1.8.0_40-b25) OpenJDK Client VM 
> (build 25.40-b25, mixed mode)
> 
> Is this 32 bit or 64 bit JVM ?

  32 bit.

Thomas



From aph at redhat.com  Wed Jul 17 09:40:52 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Jul 2019 10:40:52 +0100
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <204039729B95B74D83C33FD9FC95170B017680F9@INPNMMBX002.net.plm.eds.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
 <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
 <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>
 <ddf75a72124bde6ab8a1218e5d098529bd2570b5.camel@oracle.com>
 <204039729B95B74D83C33FD9FC95170B017680F9@INPNMMBX002.net.plm.eds.com>
Message-ID: <bb6c86e2-7eae-9670-96f0-d2082925df5f@redhat.com>

On 7/17/19 8:06 AM, Pandit (EXT), Vijay wrote:
> Can I download "RI Source Code" from https://jdk.java.net/java-se-ri/8 for openjdk8 64 bit?

You can download the binaries from many places, but my personal recommendation is
https://adoptopenjdk.net/upstream.html

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From vijay.pandit.ext at siemens.com  Wed Jul 17 09:41:28 2019
From: vijay.pandit.ext at siemens.com (Pandit (EXT), Vijay)
Date: Wed, 17 Jul 2019 09:41:28 +0000
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <204039729B95B74D83C33FD9FC95170B017680F9@INPNMMBX002.net.plm.eds.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
 <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
 <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>
 <ddf75a72124bde6ab8a1218e5d098529bd2570b5.camel@oracle.com>
 <204039729B95B74D83C33FD9FC95170B017680F9@INPNMMBX002.net.plm.eds.com>
Message-ID: <204039729B95B74D83C33FD9FC95170B01768116@INPNMMBX002.net.plm.eds.com>

Could you please provide me url from  where I can download openjdk8 for Windows 64 bit.
I tried to search for it but I am not getting it .

Thanks
Vijay
-----Original Message-----
From: discuss <discuss-bounces at openjdk.java.net> On Behalf Of [ext] Pandit (EXT), Vijay
Sent: Wednesday, July 17, 2019 12:36 PM
To: Thomas Schatzl <thomas.schatzl at oracle.com>; Andrew Haley <aph at redhat.com>; discuss at openjdk.java.net
Subject: RE: JVM heap size issue in openjdk 8.

Can I download "RI Source Code" from https://jdk.java.net/java-se-ri/8 for openjdk8 64 bit?

Thanks
Vijay


-----Original Message-----
From: Thomas Schatzl <thomas.schatzl at oracle.com>
Sent: Tuesday, July 16, 2019 7:31 PM
To: Pandit (EXT), Vijay (DI SW LCS APPS SA&S) <vijay.pandit.ext at siemens.com>; Andrew Haley <aph at redhat.com>; discuss at openjdk.java.net
Subject: Re: JVM heap size issue in openjdk 8.

Hi,

On Tue, 2019-07-16 at 13:28 +0000, Pandit (EXT), Vijay wrote:
> Thanks Andrew for you response.
> 
> 
>  Below is the command:
> 
> D:\UDU\scf\openJDK\rfx>java -version
> openjdk version "1.8.0_40"
> OpenJDK Runtime Environment (build 1.8.0_40-b25) OpenJDK Client VM 
> (build 25.40-b25, mixed mode)
> 
> Is this 32 bit or 64 bit JVM ?

  32 bit.

Thomas



From martijnverburg at gmail.com  Wed Jul 17 10:02:27 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 17 Jul 2019 11:02:27 +0100
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <204039729B95B74D83C33FD9FC95170B01768116@INPNMMBX002.net.plm.eds.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
 <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
 <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>
 <ddf75a72124bde6ab8a1218e5d098529bd2570b5.camel@oracle.com>
 <204039729B95B74D83C33FD9FC95170B017680F9@INPNMMBX002.net.plm.eds.com>
 <204039729B95B74D83C33FD9FC95170B01768116@INPNMMBX002.net.plm.eds.com>
Message-ID: <CAP7YuASQ2NBFZtGE9D7j+u5Jngbf+LwMFYtfzaqczHSiNtDpbA@mail.gmail.com>

https://adoptopenjdk.net/upstream.html

Cheers,
Martijn


On Wed, 17 Jul 2019 at 10:44, Pandit (EXT), Vijay <
vijay.pandit.ext at siemens.com> wrote:

> Could you please provide me url from  where I can download openjdk8 for
> Windows 64 bit.
> I tried to search for it but I am not getting it .
>
> Thanks
> Vijay
> -----Original Message-----
> From: discuss <discuss-bounces at openjdk.java.net> On Behalf Of [ext]
> Pandit (EXT), Vijay
> Sent: Wednesday, July 17, 2019 12:36 PM
> To: Thomas Schatzl <thomas.schatzl at oracle.com>; Andrew Haley <
> aph at redhat.com>; discuss at openjdk.java.net
> Subject: RE: JVM heap size issue in openjdk 8.
>
> Can I download "RI Source Code" from https://jdk.java.net/java-se-ri/8
> for openjdk8 64 bit?
>
> Thanks
> Vijay
>
>
> -----Original Message-----
> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> Sent: Tuesday, July 16, 2019 7:31 PM
> To: Pandit (EXT), Vijay (DI SW LCS APPS SA&S) <
> vijay.pandit.ext at siemens.com>; Andrew Haley <aph at redhat.com>;
> discuss at openjdk.java.net
> Subject: Re: JVM heap size issue in openjdk 8.
>
> Hi,
>
> On Tue, 2019-07-16 at 13:28 +0000, Pandit (EXT), Vijay wrote:
> > Thanks Andrew for you response.
> >
> >
> >  Below is the command:
> >
> > D:\UDU\scf\openJDK\rfx>java -version
> > openjdk version "1.8.0_40"
> > OpenJDK Runtime Environment (build 1.8.0_40-b25) OpenJDK Client VM
> > (build 25.40-b25, mixed mode)
> >
> > Is this 32 bit or 64 bit JVM ?
>
>   32 bit.
>
> Thomas
>
>
>

From vijay.pandit.ext at siemens.com  Thu Jul 18 09:46:13 2019
From: vijay.pandit.ext at siemens.com (Pandit (EXT), Vijay)
Date: Thu, 18 Jul 2019 09:46:13 +0000
Subject: JVM heap size issue in openjdk 8.
In-Reply-To: <CAP7YuASQ2NBFZtGE9D7j+u5Jngbf+LwMFYtfzaqczHSiNtDpbA@mail.gmail.com>
References: <204039729B95B74D83C33FD9FC95170B01767CDB@INPNMMBX002.net.plm.eds.com>
 <b3078bd2-0e0d-3fb3-a77b-e49dc89a3108@redhat.com>
 <204039729B95B74D83C33FD9FC95170B01767F85@INPNMMBX002.net.plm.eds.com>
 <ddf75a72124bde6ab8a1218e5d098529bd2570b5.camel@oracle.com>
 <204039729B95B74D83C33FD9FC95170B017680F9@INPNMMBX002.net.plm.eds.com>
 <204039729B95B74D83C33FD9FC95170B01768116@INPNMMBX002.net.plm.eds.com>
 <CAP7YuASQ2NBFZtGE9D7j+u5Jngbf+LwMFYtfzaqczHSiNtDpbA@mail.gmail.com>
Message-ID: <204039729B95B74D83C33FD9FC95170B01768239@INPNMMBX002.net.plm.eds.com>

Thanks Team. That was really helpful.

Thanks
Vijay

From: Martijn Verburg <martijnverburg at gmail.com>
Sent: Wednesday, July 17, 2019 3:32 PM
To: Pandit (EXT), Vijay (DI SW LCS APPS SA&S) <vijay.pandit.ext at siemens.com>
Cc: Thomas Schatzl <thomas.schatzl at oracle.com>; Andrew Haley <aph at redhat.com>; discuss at openjdk.java.net
Subject: Re: JVM heap size issue in openjdk 8.

https://adoptopenjdk.net/upstream.html

Cheers,
Martijn


On Wed, 17 Jul 2019 at 10:44, Pandit (EXT), Vijay <vijay.pandit.ext at siemens.com<mailto:vijay.pandit.ext at siemens.com>> wrote:
Could you please provide me url from  where I can download openjdk8 for Windows 64 bit.
I tried to search for it but I am not getting it .

Thanks
Vijay
-----Original Message-----
From: discuss <discuss-bounces at openjdk.java.net<mailto:discuss-bounces at openjdk.java.net>> On Behalf Of [ext] Pandit (EXT), Vijay
Sent: Wednesday, July 17, 2019 12:36 PM
To: Thomas Schatzl <thomas.schatzl at oracle.com<mailto:thomas.schatzl at oracle.com>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; discuss at openjdk.java.net<mailto:discuss at openjdk.java.net>
Subject: RE: JVM heap size issue in openjdk 8.

Can I download "RI Source Code" from https://jdk.java.net/java-se-ri/8 for openjdk8 64 bit?

Thanks
Vijay


-----Original Message-----
From: Thomas Schatzl <thomas.schatzl at oracle.com<mailto:thomas.schatzl at oracle.com>>
Sent: Tuesday, July 16, 2019 7:31 PM
To: Pandit (EXT), Vijay (DI SW LCS APPS SA&S) <vijay.pandit.ext at siemens.com<mailto:vijay.pandit.ext at siemens.com>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>; discuss at openjdk.java.net<mailto:discuss at openjdk.java.net>
Subject: Re: JVM heap size issue in openjdk 8.

Hi,

On Tue, 2019-07-16 at 13:28 +0000, Pandit (EXT), Vijay wrote:
> Thanks Andrew for you response.
>
>
>  Below is the command:
>
> D:\UDU\scf\openJDK\rfx>java -version
> openjdk version "1.8.0_40"
> OpenJDK Runtime Environment (build 1.8.0_40-b25) OpenJDK Client VM
> (build 25.40-b25, mixed mode)
>
> Is this 32 bit or 64 bit JVM ?

  32 bit.

Thomas


From joe.darcy at oracle.com  Tue Jul 23 05:11:39 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Jul 2019 22:11:39 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
Message-ID: <6828ef8f-d30d-fb5b-c462-bbea73d111f5@oracle.com>

Hello,

Responding to a few points below,

On 7/16/2019 5:19 AM, Severin Gehwolf wrote:
> Hi Aleksey,
>
> Source control discussions tend to be very opinionated. I'm not sure
> all arguments can be objectively answered let alone quantified. Please
> keep that in mind when reading my comments below. Again, as said
> elsewhere, I'm biased towards Git.
>
> On Mon, 2019-07-15 at 20:52 +0200, Aleksey Shipilev wrote:
>> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
>>> https://openjdk.java.net/jeps/357
>> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
>> performing this move.
> Should this JEP go into the details of advantages/disadvantages of HG
> vs. Git itself? I wouldn't think so, but your mileage may vary.
>
>> The disadvantages, off the top of my head:
>>   *) Conversion takes time and effort for all projects, including those developed outside of
>> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;
> I think many of those have been converted already for somebody to take
> a look:
>
> Amber: https://github.com/openjdk/amber
> Shenandoah: https://github.com/openjdk/shenandoah
> Panama: https://github.com/openjdk/panama
> Portola: https://github.com/openjdk/portola
> Valhalla: https://github.com/openjdk/valhalla
> Loom: https://github.com/openjdk/loom
>
> Perhaps it would be reasonable to provide some info on how those
> repositories got converted and how much time it to to convert them.
> This would allow involved parties to ball-park estimate their up-front
> conversion work.


I didn't run the conversions myself, but I believe each one took on the 
order of a few hours. FYI, the code that did the conversion is part of 
the published Skara tooling:

 ??? https://github.com/openjdk/skara

As this conversion is mostly a one-time process, I don't regard the 
conversion time as a major factor. It would likely be quicker for down 
stream users to clone fresh from git as opposed to running the 
conversion process independently.

The intention of the converted repos listed above, and the other ones 
under https://github.com/openjdk, is to let developers using the 
Mercurial versions of the OpenJDK repos in question have a low-friction 
way to kick the tires on a git version of a project of interest.

HTH,

-Joe

From joe.darcy at oracle.com  Tue Jul 23 20:50:47 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 23 Jul 2019 13:50:47 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <9135c351-f5f4-cd09-bcc0-5a4dc288a376@apache.org>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <40b8b8bd6b81a5ddea1ce242c8309dd66e6be4a9.camel@redhat.com>
 <CAJwKKmYDnjX6amYecVT4MdkRd0E5V1N5-p08P3ZMyDZSbiM1xQ@mail.gmail.com>
 <9135c351-f5f4-cd09-bcc0-5a4dc288a376@apache.org>
Message-ID: <0a2a55c8-5aad-8c16-ee3e-43afcd2ee773@oracle.com>

Catching up on email...

On 7/16/2019 3:22 AM, Emmanuel Bourg wrote:
> Le 16/07/2019 ? 11:49, Mario Torre a ?crit?:
>
>> and from what I see tooling support and size
>> of the download are the two only reason to use git
> One obvious benefit that is worth mentioning in the JEP I think is that
> Git is significantly more popular than Mercurial, and using what becomes
> a standard tool lowers the barrier of entry for new contributors. A mere
> read-only Git mirror doesn't help unifying the community around a common
> set of tools and workflows.

 From one set of data points, the 2015 and 2018 stackoverflow surveys 
about version control, a table showing the reported usage of git, 
Mercurial, and no version control (other options omitted):



	2015
	2018
git
	69.3%
	87.2%
Mercurial
	7.9%
	3.6%
no version control
	9.3%
	4.8%

Good to see fewer respondents not using version control in 2018 compared 
to 2015, but in both cases not using version control was more common 
than using Mercurial. Between 2015 and 2018 all of Mercurial, 
Subversion, and Team Foundation saw lower usage in this survey in 
contrast with Git's gains. (The 2019 survey does not cover version 
control systems.)

As time goes on, I don't think it is advantageous for OpenJDK to be one 
of the diminishing number of open source projects using Mercurial. 
Within the last few years, another long-time Mercurial-using project, 
Python, moved from Mercurial to git 
(https://www.python.org/dev/peps/pep-0512/).

There are many aspects of working on OpenJDK that are challenging or 
different compared to most other projects (strict code review, long 
lifetime of the sources, etc.) and using what is becoming more and more 
a niche tool for foundational infrastructure becomes less compelling 
unless it offers fundamental architectural advantages. However, there 
isn't that kind of distinction between Mercurial and Git in Mercurial's 
favor. There are technical differences between Git and Mercurial of 
course, as discussed elsewhere on this thread, but none of the magnitude 
of, for example, centralized vs distributed SCM. The existence of 
converters between Git and Mercurial demonstrates a kind of rough 
equivalence, even with significant differences in encoding size, etc.

While I myself have worked on OpenJDK for my years, I would understand 
if someone coming to the project new would find its choice of Mercurial 
unfamiliar and off-putting. I don't think use of Mercurial should be an 
intrinsic or distinguishing part of OpenJDK development, as opposed to, 
say, code review practices.

A goal of the Skara tooling is to allow existing JDK development 
practices to continue while also offering a more contemporary 
alternative. The Skara tooling is now used to develop the Skara code 
itself on github, https://github.com/openjdk/skara/. A developer can 
view the text of a proposed change in either github/gitlab or a webrev 
and also follow the review discussion on github/gitlab or on a mailing 
list. One particular example, a github PR (pull request)

 ??? https://github.com/openjdk/skara/pull/12

triggers a bot to generate a webrev

 ??? https://openjdk.github.io/cr/skara/12/webrev.00

and initiate a corresponding thread on the skara-dev mailing list:

https://mail.openjdk.java.net/pipermail/skara-dev/2019-June/000119.html

Cheers,

-Joe

[1] https://insights.stackoverflow.com/survey/2015#tech-sourcecontrol

[2] https://insights.stackoverflow.com/survey/2018/#work-_-version-control


From joe.darcy at oracle.com  Fri Jul 26 00:47:53 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 25 Jul 2019 17:47:53 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <25e8600e-24ed-5531-d97d-af6afae3e249@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <57b30c9a-a086-a9da-5aad-f0b303d0a6e1@oracle.com>
 <5a791408-59d9-237e-dda4-0c2e00537796@oracle.com>
 <25e8600e-24ed-5531-d97d-af6afae3e249@oracle.com>
Message-ID: <68131833-70e3-dc37-543c-10a105e761c1@oracle.com>

On 7/15/2019 5:02 PM, Joe Darcy wrote:
> Hi Jon,
>
> On 7/15/2019 2:55 PM, Jonathan Gibbons wrote:
>>
>> On 7/15/19 1:10 PM, Joe Darcy wrote:
>>> Additionally, if there is interest, the Skara team could do a "git 
>>> for recalcitrant hg users" online talk. 
>>
>> Joe,
>>
>> How about just a basic OpenJDK-oriented cheatsheet ... for the common 
>> operations that OpenJDK folk are used to doing in Mercurial, show the 
>> equivalent for Git.
>>
>
> Sure; we can produce a cheat sheet for simple cases at least.
>
PS Start of a cheat sheet below; see 
https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone for more 
information.

HTH,

-Joe

Hg

	

Git

hg clone HgURL

	

git clone GitURL

hg help command

	

git help command

hg status

	

git status

hg add

	

git add

hg rm

	

git rm

hg pull -u

	

git pull

hg export

	

git format-patch

hg push

	

git push

~/.hgrc

	

~/.gitconfig


From maurizio.cimadamore at oracle.com  Fri Jul 26 09:31:46 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 26 Jul 2019 10:31:46 +0100
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <f10f4734-f48a-dd47-b48b-3fbd9f01da8a@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>
 <f10f4734-f48a-dd47-b48b-3fbd9f01da8a@oracle.com>
Message-ID: <897f399b-8103-44f9-54de-5b6e0623d799@oracle.com>


On 15/07/2019 20:33, Joe Darcy wrote:
> Hello,
>
> The intention is to separate the decision of whether not to migrate to 
> git from the decision of how to host the git repos, assuming the 
> migration occurs.
>
> So there is an implicit dependency between delivering 357 and on a 
> yet-to-be- created JEP to discussion git hosting options.

Picking up this slightly old thread.

Joe, does that mean (I hope) that we won't witness _two_ separate 
transitions (e.g. hg to self-hosted git, then self-hosted git to hosted 
git) ? Or is that still on the card somehow?

Every time we change repository (as has happened twice already with the 
consolidation effort first, and the creation of the jdk/jdk repo later), 
there is a lot of cost for all the infrastructure that surrounds the 
JDK. Being the maintainer of several automated build and test and merge 
systems for the various Amber, Valhalla and Panama projects make me feel 
this pain acutely :-) (and I know I'm not alone in this)

So, while I'm not opposed to a move from hg to git (I find the two to be 
close enough in terms of user experience, perhaps with a slight question 
mark over git's extensibility - as I had fun a couple of times writing 
python plugins for mercurial), I'll just plead for? attempting to 
minimize disruption (and hence number of moves) as much as possible.

Cheers
Maurizio

>
> HTH; cheers,
>
> -Joe
>
> On 7/15/2019 11:17 AM, Roman Kennke wrote:
>> Nice.
>>
>> I find this strange:
>>
>> ""
>> We will not address the question of whether OpenJDK Git repositories
>> will be self-hosted or hosted by an external provider. That issue will
>> be the topic of a future JEP.
>> ""
>>
>> While I somehow can understand the motivation to break this out, it
>> leaves me wondering where will the new repos be hosted after all. Or is
>> that other unnamed JEP intended to become a prerequisite for JEP 357?
>> This seems impossible too.
>>
>> In other words: how do you intend to achieve goal#1 "Migrate all
>> single-repository OpenJDK Projects from Mercurial to Git" without
>> deciding where to host it? Or else, how/where do you want to host it,
>> without completing this new JEP 357 first?
>>
>> Thanks,
>> Roman
>>
>>> https://openjdk.java.net/jeps/357
>>>
>>> - Mark
>>>

From ebourg at apache.org  Fri Jul 26 10:22:01 2019
From: ebourg at apache.org (Emmanuel Bourg)
Date: Fri, 26 Jul 2019 12:22:01 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <897f399b-8103-44f9-54de-5b6e0623d799@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>
 <f10f4734-f48a-dd47-b48b-3fbd9f01da8a@oracle.com>
 <897f399b-8103-44f9-54de-5b6e0623d799@oracle.com>
Message-ID: <40306dcc-91b8-3657-3942-1985d571d998@apache.org>

Le 26/07/2019 ? 11:31, Maurizio Cimadamore a ?crit?:

> Joe, does that mean (I hope) that we won't witness _two_ separate
> transitions (e.g. hg to self-hosted git, then self-hosted git to hosted
> git) ? Or is that still on the card somehow?
> 
> Every time we change repository (as has happened twice already with the
> consolidation effort first, and the creation of the jdk/jdk repo later),
> there is a lot of cost for all the infrastructure that surrounds the
> JDK. Being the maintainer of several automated build and test and merge
> systems for the various Amber, Valhalla and Panama projects make me feel
> this pain acutely :-) (and I know I'm not alone in this)

Assuming the OpenJDK Git repository is first self hosted, a later move
to GitHub could be done without disrupting the infrastructure. Both
repositories could be kept in sync. That's how the Apache Software
Foundation operates with GitHub: the repositories are self hosted *and*
mirrored to GitHub, and commits are accepted on both ends.

Emmanuel Bourg

From franta-java at frantovo.cz  Fri Jul 26 11:35:26 2019
From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=)
Date: Fri, 26 Jul 2019 13:35:26 +0200
Subject: New candidate JEP: 357: Migrate from Mercurial to Git - have
 Mercurial developers been contacted?
In-Reply-To: <6828ef8f-d30d-fb5b-c462-bbea73d111f5@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <7dbe8b3f-ab02-89ea-b153-9272afda5dd0@redhat.com>
 <35c6dc72bc04d0885695bdca0719d3db1fc54d05.camel@redhat.com>
 <6828ef8f-d30d-fb5b-c462-bbea73d111f5@oracle.com>
Message-ID: <a930c575-7e03-b27e-1dfd-afbabf56c9ef@frantovo.cz>

 > https://openjdk.java.net/jeps/357

Hello,

have anyone contacted the Mercurial developers and tried to solved the 
issues in terms of the current VCS first? Have anyone submited any bugs 
to them?

Regardless whether OpenJDK will change the VCS or not, they should know 
about the issues ? if there is anything wrong with Mercurial, they shoul 
have it reported in their Bugzilla and should have a chance to face such 
issues and improve their software. Just leaving the software that served 
you for many years without any word, is IMHO not a good habit.

Franta


From franta-java at frantovo.cz  Fri Jul 26 12:08:47 2019
From: franta-java at frantovo.cz (=?UTF-8?B?RnJhbnRpxaFlayBLdcSNZXJh?=)
Date: Fri, 26 Jul 2019 14:08:47 +0200
Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_357=3a_Migrate_from_Mercurial_?=
 =?UTF-8?Q?to_Git_=e2=80=93_GitHub_issues_and_the_Network_effect?=
In-Reply-To: <40306dcc-91b8-3657-3942-1985d571d998@apache.org>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>
 <f10f4734-f48a-dd47-b48b-3fbd9f01da8a@oracle.com>
 <897f399b-8103-44f9-54de-5b6e0623d799@oracle.com>
 <40306dcc-91b8-3657-3942-1985d571d998@apache.org>
Message-ID: <8a37ff26-a09f-96b8-3505-54ba06405017@frantovo.cz>

Dne 26. 07. 19 v 12:22 Emmanuel Bourg napsal(a):
> Assuming the OpenJDK Git repository is first self hosted, a later move
> to GitHub

However there are many developers with GitHub account for whom it might 
be comfortable to clone the repository on GitHub and then use the ?pull 
request? feature there ? using such a proprietary service like GitHub 
might be also a barrier for contributors. The Network effect 
<https://en.wikipedia.org/wiki/Network_effect> endangers the healthy 
competitive environment where particular providers offer their service, 
and leads to monopoly and eventually harms the users/customers.

Having a project exclusively on GitHub and accept contribution as pull 
requests there, is not a good way to do free software or open-source, 
because it forces contributors to sign a contract (agree with Terms and 
conditions) with a third party (GitHub).

For many people it might be a commonplace to have signed such contract 
(resp. they usually have not read it) and have such account and they 
have not thought about that decision ? they just ?registered themselves 
on a webpage? because they needed that for something at the moment. But 
sum of such unintentional decisions across the individual members of the 
society leads to significant changes on the market and it subsequently 
affects the society and all its members.

Franta


From adinn at redhat.com  Fri Jul 26 13:42:26 2019
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 26 Jul 2019 14:42:26 +0100
Subject: =?UTF-8?Q?Re=3a_New_candidate_JEP=3a_357=3a_Migrate_from_Mercurial_?=
 =?UTF-8?Q?to_Git_=e2=80=93_GitHub_issues_and_the_Network_effect?=
In-Reply-To: <8a37ff26-a09f-96b8-3505-54ba06405017@frantovo.cz>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>
 <f10f4734-f48a-dd47-b48b-3fbd9f01da8a@oracle.com>
 <897f399b-8103-44f9-54de-5b6e0623d799@oracle.com>
 <40306dcc-91b8-3657-3942-1985d571d998@apache.org>
 <8a37ff26-a09f-96b8-3505-54ba06405017@frantovo.cz>
Message-ID: <3656563b-7409-f5de-0aab-c901e2f3d9b1@redhat.com>

On 26/07/2019 13:08, Franti?ek Ku?era wrote:
> Dne 26. 07. 19 v 12:22 Emmanuel Bourg napsal(a):
>> Assuming the OpenJDK Git repository is first self hosted, a later move
>> to GitHub
> 
> However there are many developers with GitHub account for whom it might
> be comfortable to clone the repository on GitHub and then use the ?pull
> request? feature there ? using such a proprietary service like GitHub
> might be also a barrier for contributors.  . . .
Can we please hold off this discussion about Github hosting and use of
PRs for a later date. The assumption that we might blithely switch over
to using them (or even incorporate them into our current practice) is
questionable on a variety of grounds and is certainly not going to be
agreed without a great deal of (probably somewhat heated) discussion.
However, that is a separate step from what is being discussed at
present. I think it would be best just to concentrate on the current
proposed change.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From joe.darcy at oracle.com  Sat Jul 27 21:49:38 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 27 Jul 2019 14:49:38 -0700
Subject: New candidate JEP: 357: Migrate from Mercurial to Git
In-Reply-To: <897f399b-8103-44f9-54de-5b6e0623d799@oracle.com>
References: <20190715175430.BF9052B6FE3@eggemoggin.niobe.net>
 <49e37e1f-743d-2b36-ccb8-df154b7d06c9@kennke.org>
 <f10f4734-f48a-dd47-b48b-3fbd9f01da8a@oracle.com>
 <897f399b-8103-44f9-54de-5b6e0623d799@oracle.com>
Message-ID: <d67069f3-7253-ae2f-ee6d-bc2d22adaf20@oracle.com>

Hi Maurizio,

On 7/26/2019 2:31 AM, Maurizio Cimadamore wrote:
>
> On 15/07/2019 20:33, Joe Darcy wrote:
>> Hello,
>>
>> The intention is to separate the decision of whether not to migrate 
>> to git from the decision of how to host the git repos, assuming the 
>> migration occurs.
>>
>> So there is an implicit dependency between delivering 357 and on a 
>> yet-to-be- created JEP to discussion git hosting options.
>
> Picking up this slightly old thread.
>
> Joe, does that mean (I hope) that we won't witness _two_ separate 
> transitions (e.g. hg to self-hosted git, then self-hosted git to 
> hosted git) ? Or is that still on the card somehow?


No; there would be one hg -> git transition to the to-be-determined git 
hosting arrangement, self-hosting or 3rd party hosting.


>
> Every time we change repository (as has happened twice already with 
> the consolidation effort first, and the creation of the jdk/jdk repo 
> later), there is a lot of cost for all the infrastructure that 
> surrounds the JDK. Being the maintainer of several automated build and 
> test and merge systems for the various Amber, Valhalla and Panama 
> projects make me feel this pain acutely :-) (and I know I'm not alone 
> in this)


 From the first OCW last year, slides 8 through 29 of

http://cr.openjdk.java.net/~darcy/Presentations/ocw-2018-08-01-skara.pdf

discuss the backstory of how the JDK has used its SCM in JDK 8 through 
12. The way the SCM was used in 8 was also the same as was used in JDK 7 
after the JDK was open sourced and moved to hg from the early 
distributed SCM Teamware, which in turn was built on top of SCCS. 
Additionally, the way the SCM was used in JDK 7, before or after hg, was 
isomorphic to how it was used in JDK 6 and JDK 5.0 and probably earlier 
too, but I wasn't around for all that much of the pre-JDK 5.0 work :-)

The SCM model from JDK 5.0 to JDK 8, a twelve year period 2002 to 2014, 
was very stable, I would argue to the point of being stagnant. During 
those years, there was a graph of integration forests and one master 
forest where a forest was a collection of repos in the base SCM. I did 
benefit from this structure at times; it let me relatively easily update 
the jaxp, jax-ws, and corba portions of OpenJDK 6 to match the 
corresponding components of 6u10 independently of the other parts of the 
parts of the JDK (hotspot, langtools, core-libs, etc.). However, there 
were significant drawbacks to the graph of forests model, including lack 
of atomicity of semantically a single change if it happened to cross 
repo boundaries and long propagation delays of fixes across the graph of 
forests. In contrast, for the last few releases the "make JDK N into JDK 
(N+1)" changes have been pushed as single changeset to master that spans 
hotspot, core libs, and javac components. Making the same sort of 
changes under the JDK 8 model would take a least three pushes and would 
take a month or more for all the fixes to propagate to all the repos in 
the graph, a long time if a six-month release schedule was desired!

The changes since JDK 9 (graph of forests => tree of forests, repo 
consolidation, combining lines of development, etc.) have been working 
toward a simpler and I would argue generally better model: a single 
master forest for a feature release where all developers work and where 
sufficient testing catches problems quickly. We aren't quite there yet, 
the client team still uses a separate repo, and improving testing is an 
unending task, but other than some implementation issues like long clone 
times, I think the current development model is much more sound than it 
was a few years ago. These SCM changes have been made possible by 
significant supporting work to improve testing, the build, 
infrastructure, and other areas.

The changes above where done in phases for several reasons, including to 
minimize disruption at a given point in time, and also to allow the 
necessarily supporting work to be but in place, such as more reliable 
testing.


> So, while I'm not opposed to a move from hg to git (I find the two to 
> be close enough in terms of user experience, perhaps with a slight 
> question mark over git's extensibility - as I had fun a couple of 
> times writing python plugins for mercurial), I'll just plead for 
> attempting to minimize disruption (and hence number of moves) as much 
> as possible.

The git tool also has a plugin mechanism; Skara has a number of commands 
using it.

I agree it is prudent to avoid unnecessary churn in the JDK's SCM usage; 
I don't know of any additional plans for bulk moves of files within the 
repo and a move to git would be the last item on my SCM changes list :-)

If you have interest and some spare cycles, the git mirrors of the projects

 ??? https://github.com/openjdk/panama
 ??? https://github.com/openjdk/amber
 ??? https://github.com/openjdk/valhalla

(among others) are available for infra experiments and prototypes.

Cheers,

-Joe