Hello, there is no official/canonical one as far as I know, but there are a few (externally maintained) Repos which are produced by mirroring the HG trees.
I cannot endores any of them, but in GitHub you find: Older versions: https://github.com/openjdk-mirror SAP maintained: https://github.com/SAP/SapMachine/tree/jdk/jdk Ojdkbuild: https://github.com/ojdkbuild/upstream_jdk AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-jdk11 Gruss Bernd BTW: ist not a good idea to respond to Digest mails, it messes up the threading and the subject -- http://bernd.eckenfels.net Von: Prakhar Makhija Gesendet: Montag, 8. Oktober 2018 18:44 An: core-libs-dev@openjdk.java.net Betreff: Re: core-libs-dev Digest, Vol 138, Issue 30 Guys are there src git repositories for javase? Please share the links I found git repos for javaee only On Mon 8 Oct, 2018, 5:30 PM , <core-libs-dev-requ...@openjdk.java.net> wrote: > Send core-libs-dev mailing list submissions to > core-libs-dev@openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-requ...@openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-ow...@openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Aleksei Voitylov) > 2. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Thomas St?fe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 6 Oct 2018 18:07:52 +0300 > From: Aleksei Voitylov <aleksei.voity...@bell-sw.com> > To: Kim Barrett <kim.barr...@oracle.com> > Cc: build-dev <build-...@openjdk.java.net>, hotspot-dev developers > <hotspot-...@openjdk.java.net>, core-libs-dev@openjdk.java.net > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52f...@bell-sw.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Kim, > > from an ARM port perspective, the stable GCC version is 4.9. The port > compiles with stock GCC 7.3 but a lot of testing is required before > moving to GCC 7.3. I agree on the overall direction and we'll commit > resources to testing it further, but from an ARM port perspective it may > happen JDK 12 is a little too optimistic. > > GCC x86 is a lot more stable than for ARM32 and AARCH64. > > -Aleksei > > On 05/10/2018 00:09, Kim Barrett wrote: > >> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov < > aleksei.voity...@bell-sw.com> wrote: > >> > >> Kim, > >> > >> Thank you for posting this. It's an important step to make. I wanted to > clarify a couple of points: > >> > >> 1. Since this is infrastructure JEP, is the version of JDK which will > undergo such changes going to be some future version or does it apply to > past versions as well? I'm concerned with how we can simplify security > backports to 8u which (I currently assume) is not subject to this change. > > Future version (perhaps as soon as JDK 12). I don't think there is > > any desire to backport this change. And yes, introducing the use of > > new language features will make backports even more interesting than > > they already are. That seems unavoidable if we're going to pursue > > this direction. > > > >> 2. Which versions of GCC do you tentatively consider at this point? > Non-x86 ports may have a problem upgrading to a specific version of GCC > which the shared code will use and may need additional lead time to adjust. > > I think our (ad hoc) testing has been limited to gcc 7.x. But looking > > at the gcc language conformance tables and release notes, gcc 5.x > > might be good enough, and gcc 6.x seems fairly likely sufficient. Of > > course, older versions are more likely to have bugs in some of these > > new features. Updating the minimum supported versions for gcc and > > clang are noted as TBD in the JEP. > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 8 Oct 2018 12:48:57 +0200 > From: Thomas St?fe <thomas.stu...@gmail.com> > To: Kim Barrett <kim.barr...@oracle.com> > Cc: build-dev <build-...@openjdk.java.net>, HotSpot Open Source > Developers <hotspot-...@openjdk.java.net>, Java Core Libs > <core-libs-dev@openjdk.java.net> > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: > <CAA-vtUyYKdzB88xxzwk3fE= > go62sypqo9x1aw9ezeu3gxcb...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. > > <quote>HotSpot makes very limited use of namespaces.</quote> > > Not really true, we already use them. E.g. in metaspace coding, I used > them to keep the global name space clean and to keep internals > internal. This was met with positive reviews, and it works on all > toolchains, so compiler support should not be a problem. Using > namespaces, we could get slowly replace the "AllStatic" classes, which > are namespaces in all but name. In contrast to classes, namespaces can > be spread over multiple files and compilation units, and allow for > cleaner separation of internal and external coding. > > It also would allow us to get rid the middle-of-header-platform-inclusions: > > For example, today we have: > > [os.hpp] > class os: AllStatic { > .... > (platform independent, outward facing os:: functions) > #include "os_linux.hpp" > >> (Inner class "Linux" with platform specific os functions) > ... > } > > Not only is the inclusion in the middle of a class terrifying, it also > means the shared, outward facing os:: namespace contains class Linux > and lots of platform specific internals. > > With namespaces one could: > > [os.hpp] > namespace os { > .... > (platform independent, outward facing os:: functions) > .... > } > > [os_linux.hpp] > namespace os { > namespace Linux { > (linux specific os functions) > } > } > > I think this is way cleaner, and keeps platform specifics from > including files which only care for the shared os interface. > > -- > > Note that I would prefer forbidding the "using" directive for callers > of namespace functions, but rather force them to spell out the > namespace: > > So, instead of this: > > using os; > jlong m = available_memory(); > > I would prefer this, which is our current practice with AllStatic childs: > > jlong m = os::available_memory(); > > The latter form would keep the code grepable. > > Best Regards, Thomas > On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett <kim.barr...@oracle.com> wrote: > > > > I've submitted a JEP for > > > > (1) enabling the use of C++14 Language Features when building the JDK, > > > > (2) define a process for deciding and documenting which new features > > can be used or are forbidden in HotSpot code, > > > > (3) provide an initial list of permitted and forbidden new features. > > > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > > > > End of core-libs-dev Digest, Vol 138, Issue 30 > ********************************************** >
