are there src git repositories for javase (was: core-libs-dev Digest, Vol 138, Issue 30)

Mon Oct 8 17:37:40 UTC 2018

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 at 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-request at openjdk.java.net>
wrote:

> Send core-libs-dev mailing list submissions to
>         core-libs-dev at 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-request at openjdk.java.net
>
> You can reach the person managing the list at
>         core-libs-dev-owner at 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.voitylov at bell-sw.com>
> To: Kim Barrett <kim.barrett at oracle.com>
> Cc: build-dev <build-dev at openjdk.java.net>, hotspot-dev developers
>         <hotspot-dev at openjdk.java.net>, core-libs-dev at openjdk.java.net
> Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
> Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52fdc6 at 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.voitylov at 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.stuefe at gmail.com>
> To: Kim Barrett <kim.barrett at oracle.com>
> Cc: build-dev <build-dev at openjdk.java.net>, HotSpot Open Source
>         Developers <hotspot-dev at openjdk.java.net>, Java Core Libs
>         <core-libs-dev at openjdk.java.net>
> Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features
> Message-ID:
>         <CAA-vtUyYKdzB88xxzwk3fE=
> Go62SyPqo9X1aW9eZeU3gxcBujA at 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.barrett at 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
> **********************************************
>