RFC: JEP JDK-8208089: Implement C++14 Language Features
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
2018/10/3 12:13:15 -0700, kim.barrett@oracle.com:
...
Or, more readably: https://openjdk.java.net/jeps/8208089 - Mark
Hi, I appreciate this is handled in a JEP and well communicated! XLc, the compiler we use for AIX, might be a bottleneck here. But we currently have no compiler-constraints by products on our aix port of jdk12 (for jdk11 we must stay with the current compiler xlc 12 which does not support C++11, and jdk11 even should be compilable with aCC by HP for which we won't get new versions!) We will update our compiler for jdk/jdk to the most recent Xlc as soon as possible. To my current knowledge, Xlc 14 was dropped, and xlc 16 is to be released early 2019. It is supposed to support C++ 11, and also some C++ 14 features. Best regards, Goetz.
-----Original Message----- From: core-libs-dev <core-libs-dev-bounces@openjdk.java.net> On Behalf Of Kim Barrett Sent: Mittwoch, 3. Oktober 2018 21:13 To: hotspot-dev developers <hotspot-dev@openjdk.java.net> Cc: build-dev <build-dev@openjdk.java.net>; core-libs- dev@openjdk.java.net Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features
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.
On Oct 4, 2018, at 2:59 AM, Lindenmaier, Goetz <goetz.lindenmaier@sap.com> wrote:
Hi,
I appreciate this is handled in a JEP and well communicated!
XLc, the compiler we use for AIX, might be a bottleneck here.
But we currently have no compiler-constraints by products on our aix port of jdk12 (for jdk11 we must stay with the current compiler xlc 12 which does not support C++11, and jdk11 even should be compilable with aCC by HP for which we won't get new versions!)
We will update our compiler for jdk/jdk to the most recent Xlc as soon as possible. To my current knowledge, Xlc 14 was dropped, and xlc 16 is to be released early 2019. It is supposed to support C++ 11, and also some C++ 14 features.
The information I've been able to find mostly discusses Linux support for XLC 16. Any information about "some C++14 features"? I haven't found any detail on that. I am working toward being able to target this for JDK 12, but realize that might not be reachable. Windows is already there, because of VS2017 support. There are a couple of minor patches needed for gcc and clang based builds; Linux-x64 and MacOSX-x64 have had a fair amount of ad hoc testing. We (Oracle) only switched over the Solaris/sparc builds to the necessary compiler version (Oracle Studio 12.6) very recently, and there are some issues still to be dealt with there. And the currently used XLC is just not up to the change.
Hi Kim,
for XLC 16. Any information about "some C++14 features"? I haven't found any detail on that. we will user our internal connections to IBM to find out :)
Best regards, Goetz.
-----Original Message----- From: Kim Barrett <kim.barrett@oracle.com> Sent: Donnerstag, 4. Oktober 2018 23:01 To: Lindenmaier, Goetz <goetz.lindenmaier@sap.com> Cc: hotspot-dev developers <hotspot-dev@openjdk.java.net>; build-dev <build-dev@openjdk.java.net>; core-libs-dev@openjdk.java.net Subject: Re: JEP JDK-8208089: Implement C++14 Language Features
On Oct 4, 2018, at 2:59 AM, Lindenmaier, Goetz <goetz.lindenmaier@sap.com> wrote:
Hi,
I appreciate this is handled in a JEP and well communicated!
XLc, the compiler we use for AIX, might be a bottleneck here.
But we currently have no compiler-constraints by products on our aix port of jdk12 (for jdk11 we must stay with the current compiler xlc 12 which does not support C++11, and jdk11 even should be compilable with aCC by HP for which we won't get new versions!)
We will update our compiler for jdk/jdk to the most recent Xlc as soon as possible. To my current knowledge, Xlc 14 was dropped, and xlc 16 is to be released early 2019. It is supposed to support C++ 11, and also some C++ 14 features.
The information I've been able to find mostly discusses Linux support for XLC 16. Any information about "some C++14 features"? I haven't found any detail on that.
I am working toward being able to target this for JDK 12, but realize that might not be reachable. Windows is already there, because of VS2017 support. There are a couple of minor patches needed for gcc and clang based builds; Linux-x64 and MacOSX-x64 have had a fair amount of ad hoc testing. We (Oracle) only switched over the Solaris/sparc builds to the necessary compiler version (Oracle Studio 12.6) very recently, and there are some issues still to be dealt with there. And the currently used XLC is just not up to the change.
Hi Tim, Jeff, Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard) https://bugs.openjdk.java.net/browse/JDK-8208089 Could you please provide a summary of which of these features are already available since which version of xlC for AIX and potentially escalate the implementation of the missing features within IBM’s xlC on AIX team. Thank you and best regards, Volker Kim Barrett <kim.barrett@oracle.com> schrieb am Mi. 3. Okt. 2018 um 22:13:
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.
On Oct 4, 2018, at 4:35 AM, Volker Simonis <volker.simonis@gmail.com> wrote:
Hi Tim, Jeff,
Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard)
Note that this list is intended as a starting point. The JEP also describes a process for adding to the list of permitted features, and I anticipate that process will be used. There are several that I personally think would be good to add (perhaps with some limits or restrictions), but that I think may involve more detailed discussion. And other folks may have their favorite must have feature(s) that didn’t seem to me to be needed in this initial seed list.
Hi Kim, I like this initiative. I'm wondering if some of these rules can be easily codified or written into a jcheck style checker (ccheck?) so that Authors can adhere to the conventions and not rely on a Human review to pick out where that convention isn't met. Cheers, Martijn On Wed, 3 Oct 2018 at 20:13, Kim Barrett <kim.barrett@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.
4 okt. 2018 kl. 10:57 skrev Martijn Verburg <martijnverburg@gmail.com>:
Hi Kim,
I like this initiative. I'm wondering if some of these rules can be easily codified or written into a jcheck style checker (ccheck?) so that Authors can adhere to the conventions and not rely on a Human review to pick out where that convention isn't met.
That's an interesting thought! I googled around a bit, but could find no obvious candidate for doing such a check. In fact, parsing and analyzing C++ seems quite a hard problem, compared to many other languages. (Sad, but not really surprising.) I found two possible routes to explore: cpplint [1], the official Google tool to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a framework for creating scripts that can analyze and/or transform C++ code. Neither seem like an ideal solution. The Google tool is hard coded to support the Google rules. It's possible we can fork it and add our own, but it's not clear that this is even possible, much less so that it's a good way forward. Vera++, on the other hand, seems much more likely to be able to provide the tooling needed to write checks that enforce these rules. However, what we have is just a framework, and someone's got to write those rules (in TCL of all languages...). Then again, Vera++ is an old and quite popular tool, so its possible there is already a bunch of predefined rules that we can use as a starting point out there. (I didn't go that far in my analysis). Apart from these two, there appear to be no popular, well-encompassing, open source C++ checker out there, that could possibly be verifying rules like these. :( /Magnus [1] https://github.com/google/styleguide/tree/gh-pages/cpplint [2] https://google.github.io/styleguide/cppguide.html [3] https://bitbucket.org/verateam/vera/wiki/Introduction
Cheers, Martijn
On Wed, 3 Oct 2018 at 20:13, Kim Barrett <kim.barrett@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.
On 10/4/18 2:31 PM, Magnus Ihse Bursie wrote:>> 4 okt. 2018 kl. 10:57 skrev Martijn Verburg <martijnverburg@gmail.com>:
I like this initiative. I'm wondering if some of these rules can be easily codified or written into a jcheck style checker (ccheck?) so that Authors can adhere to the conventions and not rely on a Human review to pick out where that convention isn't met.
That's an interesting thought!
I googled around a bit, but could find no obvious candidate for doing such a check. In fact, parsing and analyzing C++ seems quite a hard problem, compared to many other languages. (Sad, but not really surprising.)
I found two possible routes to explore: cpplint [1], the official Google tool to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a framework for creating scripts that can analyze and/or transform C++ code.
As usual there is of a third route, this one is "just a matter of programming" :) The (probably) easiest way to enforce usage of only a subset of C++ is to write custom clang-tidy checks [0]. We could most likely write a couple of ASTMatchers [1] to watch out for features we do not want. It used to be very hard to use the clang tooling with HotSpot, but thanks to Robin Westberg's compile-commands patch [2] that just went in, this is no longer an issue. Unfortunately I don't think requiring all contributors to install a custom version of clang-tidy with HotSpot checks is feasible, this is more something you would want to run in a CI setup. Thanks, Erik [0]: https://clang.llvm.org/extra/clang-tidy/#writing-a-clang-tidy-check [1]: http://clang.llvm.org/docs/LibASTMatchers.html [2]: http://hg.openjdk.java.net/jdk/jdk/rev/804792ce736f
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. 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. Thanks, -Aleksei On 03/10/2018 22:13, Kim Barrett 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.
On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov <aleksei.voitylov@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.
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@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.
On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov <aleksei.voitylov@bell-sw.com> wrote:
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.
It seems to me that JDK 11 being an LTS might provide an answer to this. JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat "experimental" in that it might require a more recent compiler version that hasn't received as much testing as was done for JDK 11. Similarly, the AIX/ppc platform might not be supported after JDK 11 until an improved version of the relevant compiler becomes available. I don't know if such an approach is acceptable to the community, nor do I know how such a decision might be made. But I think it would be unfortunate if such issues blocked progress in this area.
Kim, Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success. -Aleksei On 08/10/2018 22:34, Kim Barrett wrote:
On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov <aleksei.voitylov@bell-sw.com> wrote:
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. It seems to me that JDK 11 being an LTS might provide an answer to this.
JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat "experimental" in that it might require a more recent compiler version that hasn't received as much testing as was done for JDK 11.
Similarly, the AIX/ppc platform might not be supported after JDK 11 until an improved version of the relevant compiler becomes available.
I don't know if such an approach is acceptable to the community, nor do I know how such a decision might be made. But I think it would be unfortunate if such issues blocked progress in this area.
On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov <aleksei.voitylov@bell-sw.com> wrote:
Kim,
Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing.
My impression is that most of these were not toolchain issues per se. Rather, they were broken or incomplete changes in platform-dependent code that weren't tested on these "alternative" platforms before being pushed. Oracle has provided dev-submit so that non-Oracle folks can do some minimal testing on all the platforms that Oracle supports. I know that I would sometimes like to have similarly "easy" testing for various platforms not supported by Oracle. I didn't suggest "no testing" if there is a compiler version that supports the new language standards but has not yet been fully product-qualified by the people who are using it. I think gcc on arm may be in that category. But I think it would be very disappointing if the complete lack of a usable version of some compiler were to completely block us in this area. (Unfortunately, such a lack appears to be the situation for XLC compiler used for the AIX/ppc port.) The proposal is not very aggressive.
We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11.
I'm understand that it takes time and effort to do a toolchain upgrade. And turning on support for new language version without changing the toolchain version isn't really all that different. This proposal didn't suddenly appear out of nowhere. There has been wistful discussion about using new language features for a long time, with an understanding that going anywhere with that was difficult because of some popular toolchain deficiencies (notably MSVC++) and the need to upgrade others. There have been ongoing efforts in this direction, e.g. various changes to support building with C++11/14 support enabled. Oracle made toolchain upgrades in JDK 11, in part to support the language standard change. (Unfortunately, the relevant toolchain upgrade JEP was labelled "Confidential", even though a lot of the work was in the open, and some of it was explicitly about dealing with differences arising from turning on C++11/14.) I think JDK 12 for this JEP is reasonable goal at this stage. Of course, that goal might not be achieved, for a variety of reasons. That's why it is not yet in the Targeted state and why there is a formal process for moving to that state; there's still work to be done, and we'll have to see how that work proceeds.
With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success.
Kim, If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. -Aleksei On 11/10/2018 22:23, Kim Barrett wrote:
On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov <aleksei.voitylov@bell-sw.com> wrote:
Kim,
Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. My impression is that most of these were not toolchain issues per se. Rather, they were broken or incomplete changes in platform-dependent code that weren't tested on these "alternative" platforms before being pushed. Oracle has provided dev-submit so that non-Oracle folks can do some minimal testing on all the platforms that Oracle supports. I know that I would sometimes like to have similarly "easy" testing for various platforms not supported by Oracle.
I didn't suggest "no testing" if there is a compiler version that supports the new language standards but has not yet been fully product-qualified by the people who are using it. I think gcc on arm may be in that category. But I think it would be very disappointing if the complete lack of a usable version of some compiler were to completely block us in this area. (Unfortunately, such a lack appears to be the situation for XLC compiler used for the AIX/ppc port.) The proposal is not very aggressive.
We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. I'm understand that it takes time and effort to do a toolchain upgrade. And turning on support for new language version without changing the toolchain version isn't really all that different.
This proposal didn't suddenly appear out of nowhere. There has been wistful discussion about using new language features for a long time, with an understanding that going anywhere with that was difficult because of some popular toolchain deficiencies (notably MSVC++) and the need to upgrade others. There have been ongoing efforts in this direction, e.g. various changes to support building with C++11/14 support enabled. Oracle made toolchain upgrades in JDK 11, in part to support the language standard change. (Unfortunately, the relevant toolchain upgrade JEP was labelled "Confidential", even though a lot of the work was in the open, and some of it was explicitly about dealing with differences arising from turning on C++11/14.)
I think JDK 12 for this JEP is reasonable goal at this stage. Of course, that goal might not be achieved, for a variety of reasons. That's why it is not yet in the Targeted state and why there is a formal process for moving to that state; there's still work to be done, and we'll have to see how that work proceeds.
With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success.
On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov <aleksei.voitylov@bell-sw.com> wrote:
Kim,
If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming.
What is "sufficient lead time"? I'm not proposing an answer, just suggesting that 3 months (approx time between JEP publication and JDK 12 fork) might be sufficient, and a worthy goal. That's a decision that ought to be made as part of the Targeting discussion for this JEP. Right now, it's not even a Candidate, since there's still work to be done.
Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker.
That's good news, though pretty much what I expected. I'm more worried about Solaris. Having a goal of JDK 12 may help move things along.
On 16/10/2018 02:25, Kim Barrett wrote:
On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov <aleksei.voitylov@bell-sw.com> wrote:
Kim,
If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. What is "sufficient lead time"? I'm not proposing an answer, just suggesting that 3 months (approx time between JEP publication and JDK 12 fork) might be sufficient, and a worthy goal. That's a decision that ought to be made as part of the Targeting discussion for this JEP. Right now, it's not even a Candidate, since there's still work to be done. I'm fine with that, and you probably can assume to document this goal in the JEP if noone speaks up.
Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. That's good news, though pretty much what I expected.
I'm more worried about Solaris. Having a goal of JDK 12 may help move things along.
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@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.
On Mon, Oct 8, 2018 at 12:49 PM Thomas Stüfe <thomas.stuefe@gmail.com> wrote:
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:
That's overdue since a long time! It would allow us to finally get correct code navigation in IDEs.
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:
As far as I saw, "using" directives are already on the "Exclude" list in Kim's proposal.
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@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.
On Oct 8, 2018, at 6:48 AM, Thomas Stüfe <thomas.stuefe@gmail.com> wrote:
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.
I would like to keep this JEP focused on C++11/14 usage. However, it presently describes a process for recording and updating HotSpot usage. I think that process is pretty close to the de facto process, which is rarely used successfully because it's not written down anywhere. We could extract that part of the JEP out, formalize, discuss, agree, and record it. Then you could propose a change and there would be a process for dealing with the proposal, rather than having it slide into oblivion because we don't know how to proceed. And the JEP could be made a bit smaller because it could just refer to that process.
Hi Kim, On Mon, Oct 8, 2018 at 8:32 PM Kim Barrett <kim.barrett@oracle.com> wrote:
On Oct 8, 2018, at 6:48 AM, Thomas Stüfe <thomas.stuefe@gmail.com> wrote:
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.
I would like to keep this JEP focused on C++11/14 usage.
However, it presently describes a process for recording and updating HotSpot usage. I think that process is pretty close to the de facto process, which is rarely used successfully because it's not written down anywhere.
We could extract that part of the JEP out, formalize, discuss, agree, and record it. Then you could propose a change and there would be a process for dealing with the proposal, rather than having it slide into oblivion because we don't know how to proceed. And the JEP could be made a bit smaller because it could just refer to that process.
Yes, I would like that. It would be really good to have a process in place to preserve and actually live a consensus about what features we use. We have the Hotspot Style Guide, but we let it become woefully outdated in the face of new developments. I always smile when I read the "Be sparing with templates." remark - that ship has sailed long ago. --- A small remark to the text of your JEP: "As a rule of thumb, permitting features which simplify writing, and especially reading, code should be encouraged." I would like to add to that that simplifying build error analysis should also be a goal. That directly influences programmer productivity. We had some cases in the recent past where we spent a lot of time scratching our heads over walls of template related compiler errors. (not sure how to reach this goal though, since this seems to be a problem inherent in using C++ templates). Best Regards, Thomas
On Oct 3, 2018, at 3:13 PM, Kim Barrett <kim.barrett@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.
While there has been some discussion of this JEP here, so far only Mikael has officially reviewed or endorsed it. Regarding the timing of this JEP, integration in time for JDK 12 seems unlikely.
Hi Kim, On 16/11/2018 12:31 pm, Kim Barrett wrote:
On Oct 3, 2018, at 3:13 PM, Kim Barrett <kim.barrett@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.
While there has been some discussion of this JEP here, so far only Mikael has officially reviewed or endorsed it.
I added myself as a Reviewer.
Regarding the timing of this JEP, integration in time for JDK 12 seems unlikely.
This doesn't strike me as a JEP that actually integrates anything. It wants to establish a process by which future C++ features are accepted for use with hotspot. That's just documentation on the OpenJDK wiki as far as I can see. The actual set of features and any "vote" on them can happen any time after the JEP is approved. Any actual use of those features can follow any time after that. I think it is important that all the port owners buy into this. Thanks, David
On Nov 19, 2018, at 1:31 AM, David Holmes <david.holmes@oracle.com> wrote:
Hi Kim,
On 16/11/2018 12:31 pm, Kim Barrett wrote:
On Oct 3, 2018, at 3:13 PM, Kim Barrett <kim.barrett@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 While there has been some discussion of this JEP here, so far only Mikael has officially reviewed or endorsed it.
I added myself as a Reviewer.
Thanks.
Regarding the timing of this JEP, integration in time for JDK 12 seems unlikely.
This doesn't strike me as a JEP that actually integrates anything. It wants to establish a process by which future C++ features are accepted for use with hotspot. That's just documentation on the OpenJDK wiki as far as I can see. The actual set of features and any "vote" on them can happen any time after the JEP is approved. Any actual use of those features can follow any time after that.
There is the integration of the build changes needed to enable the use of C++14. Presently we explicitly specify C++98 (actually, gnu++98) for gcc. We also presently permit the use of older versions of compilers that don’t support C++14 (or even C++11) at all, or only partially. Those need to be dropped.
I think it is important that all the port owners buy into this.
At least one port (aix_ppc) presently seems to have no way to support this change, because the compiler being used is seriously deficient and appears to be languishing. (It doesn’t even support C++11, let alone C++14.) I think the community could (and in my opinion, should) chose to move ahead despite that. If a new and adequate compiler is expected “soon” then the community might choose to wait, or might proceed and let that port languish until the new compiler is available. I think that’s all part of the discussion that should happen around the targeting of this JEP. I hope this inadequate compiler on a relatively niche platform won’t be an indefinite blocker in this area.
On Nov 19, 2018, at 2:04 AM, Kim Barrett <kim.barrett@oracle.com> wrote:
On Nov 19, 2018, at 1:31 AM, David Holmes <david.holmes@oracle.com> wrote: I think it is important that all the port owners buy into this.
At least one port (aix_ppc) presently seems to have no way to support this change, because the compiler being used is seriously deficient and appears to be languishing. (It doesn’t even support C++11, let alone C++14.) I think the community could (and in my opinion, should) chose to move ahead despite that. If a new and adequate compiler is expected “soon” then the community might choose to wait, or might proceed and let that port languish until the new compiler is available. I think that’s all part of the discussion that should happen around the targeting of this JEP. I hope this inadequate compiler on a relatively niche platform won’t be an indefinite blocker in this area.
Here’s what Volker said on the build-dev list, 2017-07-19, subject “C++11/C++14 support in XLC ?” <begin quote> - SAP is currently maintaining the AIX port in the OpenJDK and we're willing to do that in the future. But we're not IBM and we can not decide about the XLC feature list. If Oracle and the OpenJDK community finally decide to use C++11/14 features which are not available in XLC we have to live with that. We can either escalate the XLC deficiencies to IBM and suspend the port until the compiler gets fixed. Or we can switch the port to use the GCC tool chain with all the pros (bigger compatibility with Linux platforms) and cons (porting effort, testing, compatibility with other AIX software compiled with XLC, compiler support). While the GCC alternative sounds very appealing at a first glance it really isn't that perfect in reality, especially not for our commercial SAP JVM version of OpenJDK. One problem is the fact that there's no official support for GCC on AIX, the other is compatibility. Just think you had to replace Solaris Studio by GCC on Solaris :) <end quote> He had more to say on the general topic at the time. I don’t know if anything has changed in the intervening nearly 1 1/2 years.
On Mon, Nov 19, 2018 at 9:00 AM Kim Barrett <kim.barrett@oracle.com> wrote:
On Nov 19, 2018, at 2:04 AM, Kim Barrett <kim.barrett@oracle.com> wrote:
On Nov 19, 2018, at 1:31 AM, David Holmes <david.holmes@oracle.com> wrote: I think it is important that all the port owners buy into this.
At least one port (aix_ppc) presently seems to have no way to support this change, because the compiler being used is seriously deficient and appears to be languishing. (It doesn’t even support C++11, let alone C++14.) I think the community could (and in my opinion, should) chose to move ahead despite that. If a new and adequate compiler is expected “soon” then the community might choose to wait, or might proceed and let that port languish until the new compiler is available. I think that’s all part of the discussion that should happen around the targeting of this JEP. I hope this inadequate compiler on a relatively niche platform won’t be an indefinite blocker in this area.
Here’s what Volker said on the build-dev list, 2017-07-19, subject “C++11/C++14 support in XLC ?”
<begin quote> - SAP is currently maintaining the AIX port in the OpenJDK and we're willing to do that in the future. But we're not IBM and we can not decide about the XLC feature list. If Oracle and the OpenJDK community finally decide to use C++11/14 features which are not available in XLC we have to live with that. We can either escalate the XLC deficiencies to IBM and suspend the port until the compiler gets fixed. Or we can switch the port to use the GCC tool chain with all the pros (bigger compatibility with Linux platforms) and cons (porting effort, testing, compatibility with other AIX software compiled with XLC, compiler support). While the GCC alternative sounds very appealing at a first glance it really isn't that perfect in reality, especially not for our commercial SAP JVM version of OpenJDK. One problem is the fact that there's no official support for GCC on AIX, the other is compatibility. Just think you had to replace Solaris Studio by GCC on Solaris :) <end quote>
He had more to say on the general topic at the time. I don’t know if anything has changed in the intervening nearly 1 1/2 years.
Not really. IBM is working on a new compiler which is in Beta now. But neither have I tested it nor do I know exactly if it will have full C++11/14 support. As I wrote before, this is a chicken/egg problem which I can not solve and I agree that it shouldn't be a blocker for OpenJDK. Therefore, please go ahead and use whichever feature the OpenJDK community agrees upon. Regards, Volker
On 19/11/2018 5:04 pm, Kim Barrett wrote:
On Nov 19, 2018, at 1:31 AM, David Holmes <david.holmes@oracle.com> wrote:
Hi Kim,
On 16/11/2018 12:31 pm, Kim Barrett wrote:
On Oct 3, 2018, at 3:13 PM, Kim Barrett <kim.barrett@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 While there has been some discussion of this JEP here, so far only Mikael has officially reviewed or endorsed it.
I added myself as a Reviewer.
Thanks.
Regarding the timing of this JEP, integration in time for JDK 12 seems unlikely.
This doesn't strike me as a JEP that actually integrates anything. It wants to establish a process by which future C++ features are accepted for use with hotspot. That's just documentation on the OpenJDK wiki as far as I can see. The actual set of features and any "vote" on them can happen any time after the JEP is approved. Any actual use of those features can follow any time after that.
There is the integration of the build changes needed to enable the use of C++14. Presently we explicitly specify C++98 (actually, gnu++98) for gcc. We also presently permit the use of older versions of compilers that don’t support C++14 (or even C++11) at all, or only partially. Those need to be dropped.
Even so those changes don't need to be put in place until we actually need to start using a new feature. So I would still think we can finalize the JEP independently of the subsequent code changes.
I think it is important that all the port owners buy into this.
At least one port (aix_ppc) presently seems to have no way to support this change, because the compiler being used is seriously deficient and appears to be languishing. (It doesn’t even support C++11, let alone C++14.) I think the community could (and in my opinion, should) chose to move ahead despite that.
Okay I've seen the mail on this - thanks. Cheers, David
If a new and adequate compiler is expected “soon” then the community might choose to wait, or might proceed and let that port languish until the new compiler is available. I think that’s all part of the discussion that should happen around the targeting of this JEP. I hope this inadequate compiler on a relatively niche platform won’t be an indefinite blocker in this area.
On Nov 19, 2018, at 7:56 AM, David Holmes <david.holmes@oracle.com> wrote:
On 19/11/2018 5:04 pm, Kim Barrett wrote:
On Nov 19, 2018, at 1:31 AM, David Holmes <david.holmes@oracle.com> wrote:
Hi Kim,
On 16/11/2018 12:31 pm, Kim Barrett wrote:
This doesn't strike me as a JEP that actually integrates anything. It wants to establish a process by which future C++ features are accepted for use with hotspot. That's just documentation on the OpenJDK wiki as far as I can see. The actual set of features and any "vote" on them can happen any time after the JEP is approved. Any actual use of those features can follow any time after that. There is the integration of the build changes needed to enable the use of C++14. Presently we explicitly specify C++98 (actually, gnu++98) for gcc. We also presently permit the use of older versions of compilers that don’t support C++14 (or even C++11) at all, or only partially. Those need to be dropped.
Even so those changes don't need to be put in place until we actually need to start using a new feature. So I would still think we can finalize the JEP independently of the subsequent code changes.
I don't see any benefit to making the first C++ code change that uses a new feature also incorporate the needed build system changes. Indeed, how does one develop that feature usage unless one has the build system changes already in hand? It seems to me that if the documentation says one can use some new language feature but the build system hasn't been updated to actually support doing so, then the documentation is wrong. And recall that this JEP includes making some new features available immediately. (That initial list might be modified as part of this JEP discussion.)
On 20/11/2018 6:39 am, Kim Barrett wrote:
On Nov 19, 2018, at 7:56 AM, David Holmes <david.holmes@oracle.com> wrote:
On 19/11/2018 5:04 pm, Kim Barrett wrote:
On Nov 19, 2018, at 1:31 AM, David Holmes <david.holmes@oracle.com> wrote:
Hi Kim,
On 16/11/2018 12:31 pm, Kim Barrett wrote:
This doesn't strike me as a JEP that actually integrates anything. It wants to establish a process by which future C++ features are accepted for use with hotspot. That's just documentation on the OpenJDK wiki as far as I can see. The actual set of features and any "vote" on them can happen any time after the JEP is approved. Any actual use of those features can follow any time after that. There is the integration of the build changes needed to enable the use of C++14. Presently we explicitly specify C++98 (actually, gnu++98) for gcc. We also presently permit the use of older versions of compilers that don’t support C++14 (or even C++11) at all, or only partially. Those need to be dropped.
Even so those changes don't need to be put in place until we actually need to start using a new feature. So I would still think we can finalize the JEP independently of the subsequent code changes.
I don't see any benefit to making the first C++ code change that uses a new feature also incorporate the needed build system changes. Indeed, how does one develop that feature usage unless one has the build system changes already in hand?
Just trying to distinguish the JEP from the build changes that will enable what is agreed upon by the JEP versus the first use of such changes. If you want it all tied together that's fine - you're right it likely won't make 12. Cheers, David -----
It seems to me that if the documentation says one can use some new language feature but the build system hasn't been updated to actually support doing so, then the documentation is wrong. And recall that this JEP includes making some new features available immediately. (That initial list might be modified as part of this JEP discussion.)
On 11/19/18 8:39 PM, Kim Barrett wrote:
I don't see any benefit to making the first C++ code change that uses a new feature also incorporate the needed build system changes. Indeed, how does one develop that feature usage unless one has the build system changes already in hand?
It seems to me that if the documentation says one can use some new language feature but the build system hasn't been updated to actually support doing so, then the documentation is wrong. And recall that this JEP includes making some new features available immediately. (That initial list might be modified as part of this JEP discussion.)
What is the status of this? I thought we'd decide, but I still see $1_CXXSTD_CXXFLAG="-std=gnu++98" in flags-cflags.m4 I need std::make_unsigned in order to fix some undefined behaviour in HotSpot. I could implement it myself in share/metaprogramming but if we've agreed to allow C++14, can we please get it done now? Thx. -- 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
On Mar 2, 2020, at 7:00 AM, Andrew Haley <aph@redhat.com> wrote:
On 11/19/18 8:39 PM, Kim Barrett wrote:
I don't see any benefit to making the first C++ code change that uses a new feature also incorporate the needed build system changes. Indeed, how does one develop that feature usage unless one has the build system changes already in hand?
It seems to me that if the documentation says one can use some new language feature but the build system hasn't been updated to actually support doing so, then the documentation is wrong. And recall that this JEP includes making some new features available immediately. (That initial list might be modified as part of this JEP discussion.)
What is the status of this? I thought we'd decide, but I still see
$1_CXXSTD_CXXFLAG="-std=gnu++98"
in flags-cflags.m4
I need std::make_unsigned in order to fix some undefined behaviour in HotSpot. I could implement it myself in share/metaprogramming but if we've agreed to allow C++14, can we please get it done now? Thx.
In light of JEP 362 "Deprecate the Solaris and SPARC Ports" https://bugs.openjdk.java.net/browse/JDK-8231554 with the intended removal of Oracle Developer Studio (aka Solaris Studio) as a supported compiler sometime soon, we don't want to spend effort getting HotSpot to production quality on that platform with C++11/14 features enabled and in use.
On 3/2/20 9:51 PM, Kim Barrett wrote:
On Mar 2, 2020, at 7:00 AM, Andrew Haley <aph@redhat.com> wrote:
On 11/19/18 8:39 PM, Kim Barrett wrote:
I don't see any benefit to making the first C++ code change that uses a new feature also incorporate the needed build system changes. Indeed, how does one develop that feature usage unless one has the build system changes already in hand?
It seems to me that if the documentation says one can use some new language feature but the build system hasn't been updated to actually support doing so, then the documentation is wrong. And recall that this JEP includes making some new features available immediately. (That initial list might be modified as part of this JEP discussion.)
What is the status of this? I thought we'd decide, but I still see
$1_CXXSTD_CXXFLAG="-std=gnu++98"
in flags-cflags.m4
I need std::make_unsigned in order to fix some undefined behaviour in HotSpot. I could implement it myself in share/metaprogramming but if we've agreed to allow C++14, can we please get it done now? Thx.
In light of JEP 362 "Deprecate the Solaris and SPARC Ports" https://bugs.openjdk.java.net/browse/JDK-8231554 with the intended removal of Oracle Developer Studio (aka Solaris Studio) as a supported compiler sometime soon, we don't want to spend effort getting HotSpot to production quality on that platform with C++11/14 features enabled and in use.
OK. So, I guess this means that we're stuck with C++98 (!) for a while. It's not too hard for me to write the support for make_unsigned and add it to share/metaprogramming. I'll do that and see what people say. -- 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
Andrew Haley <aph@redhat.com> schrieb am Mo., 2. März 2020, 13:00:
On 11/19/18 8:39 PM, Kim Barrett wrote:
I don't see any benefit to making the first C++ code change that uses a new feature also incorporate the needed build system changes. Indeed, how does one develop that feature usage unless one has the build system changes already in hand?
It seems to me that if the documentation says one can use some new language feature but the build system hasn't been updated to actually support doing so, then the documentation is wrong. And recall that this JEP includes making some new features available immediately. (That initial list might be modified as part of this JEP discussion.)
What is the status of this? I thought we'd decide, but I still see
$1_CXXSTD_CXXFLAG="-std=gnu++98"
in flags-cflags.m4
I need std::make_unsigned in order to fix some undefined behaviour in HotSpot. I could implement it myself in share/metaprogramming but if we've agreed to allow C++14, can we please get it done now? Thx.
As lead of the 8 and 11 update projects you probably know best, if this fix will eventually be considered for backporting and choose your means wisely :)
-- 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
On 3/2/20 10:46 PM, Volker Simonis wrote:
As lead of the 8 and 11 update projects you probably know best, if this fix will eventually be considered for backporting and choose your means wisely :)
Yeah, I know. Srsly. :-) But one of the few things of which I am certain is that we must not allow the needs of backporting to determine the future of Java. That's the way of staying in the past. As Patrick Head put it, “Some people tell me that Formula 1 would be better if the drivers still used stick shifts, but that’s a bit like saying, 'isn’t it a pity we don’t still walk around in clogs!'” -- 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
On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley <aph@redhat.com> wrote:
On 3/2/20 10:46 PM, Volker Simonis wrote:
As lead of the 8 and 11 update projects you probably know best, if this fix will eventually be considered for backporting and choose your means wisely :)
Yeah, I know. Srsly. :-)
But one of the few things of which I am certain is that we must not allow the needs of backporting to determine the future of Java. That's the way of staying in the past.
As Patrick Head put it, “Some people tell me that Formula 1 would be better if the drivers still used stick shifts, but that’s a bit like saying, 'isn’t it a pity we don’t still walk around in clogs!'”
Totally agree.
-- 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
How about C++11? I have a pending patch for jpackage that depends on C++11 features that I hesitate to pull in jdk15. - Alexey On 3/3/2020 5:22 AM, Volker Simonis wrote:
On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley <aph@redhat.com> wrote:
On 3/2/20 10:46 PM, Volker Simonis wrote:
As lead of the 8 and 11 update projects you probably know best, if this fix will eventually be considered for backporting and choose your means wisely :) Yeah, I know. Srsly. :-)
But one of the few things of which I am certain is that we must not allow the needs of backporting to determine the future of Java. That's the way of staying in the past.
As Patrick Head put it, “Some people tell me that Formula 1 would be better if the drivers still used stick shifts, but that’s a bit like saying, 'isn’t it a pity we don’t still walk around in clogs!'”
Totally agree.
-- 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
On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk <alexey.semenyuk@oracle.com> wrote:
How about C++11? I have a pending patch for jpackage that depends on C++11 features that I hesitate to pull in jdk15.
The reasons for HotSpot (at least) not already being on C++14 (cost of switching over the Solaris Studio based platform) also apply to C++11. A big part of the work involves dealing with changes to the compilation model, the runtime libraries, and the ABI, all of which are part of Solaris Studio's transition from C++98 to C++11.
jpackage is not and not planned to be available on Solaris. It is only on Windows, Linux and Mac. Is this a sufficient argument to bring in the patch as is and not rework it to make C++98 compliant? According to the list of supported compilers [1] on platforms where jpackage is available they all support C++11 for several years already. [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms - Alexey On 3/3/2020 7:29 PM, Kim Barrett wrote:
On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk <alexey.semenyuk@oracle.com> wrote:
How about C++11? I have a pending patch for jpackage that depends on C++11 features that I hesitate to pull in jdk15. The reasons for HotSpot (at least) not already being on C++14 (cost of switching over the Solaris Studio based platform) also apply to C++11. A big part of the work involves dealing with changes to the compilation model, the runtime libraries, and the ABI, all of which are part of Solaris Studio's transition from C++98 to C++11.
On 3/3/20 10:26 AM, Andrew Haley wrote:
But one of the few things of which I am certain is that we must not allow the needs of backporting to determine the future of Java. That's the way of staying in the past.
Unpopular opinion: It's the enterprise customers that mainly pay for the development of software, not the users of rolling release distributions. I know that maintaining old stuff is boring but that's where the money is made. Too many developers unfortunately seem to forget that.
As Patrick Head put it, “Some people tell me that Formula 1 would be better if the drivers still used stick shifts, but that’s a bit like saying, 'isn’t it a pity we don’t still walk around in clogs!'”
Maintenance of stable software isn't done for nostalgic reasons, it's because enterprise customers need a reliable and stable platform to run their businesses on. A lot of businesses are still running on JDK-8 for this reason. Running bleeding edge software might be an option for a single desktop user, but not in an enterprise environment with thousands of users or in a critical environment like the booking system of an airline. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 3/3/20 10:18 PM, John Paul Adrian Glaubitz wrote:
On 3/3/20 10:26 AM, Andrew Haley wrote:
But one of the few things of which I am certain is that we must not allow the needs of backporting to determine the future of Java. That's the way of staying in the past.
Unpopular opinion: It's the enterprise customers that mainly pay for the development of software, not the users of rolling release distributions.
I don't think that's an unpopular opinion at all! It's why most of us who work on Java updates get paid. Continuing to depend on C++98 is not good for us in the long term. It means we're using an obsolete programming language, and that inevitably carries its own risks, and we miss opportunities to do things better.
I know that maintaining old stuff is boring but that's where the money is made. Too many developers unfortunately seem to forget that.
Seriously now, who are you talking about? We spend a tremendous amount of time and money maintaining old stuff.
As Patrick Head put it, “Some people tell me that Formula 1 would be better if the drivers still used stick shifts, but that’s a bit like saying, 'isn’t it a pity we don’t still walk around in clogs!'”
Maintenance of stable software isn't done for nostalgic reasons, it's because enterprise customers need a reliable and stable platform to run their businesses on. A lot of businesses are still running on JDK-8 for this reason.
Yes, that's why we do it.
Running bleeding edge software might be an option for a single desktop user, but not in an enterprise environment with thousands of users or in a critical environment like the booking system of an airline.
Bear in mind that, if people hadn't pressed forward after JDK 7, there wouldn't be a "legacy" JDK 8 to maintain. -- 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
participants (13)
-
Aleksei Voitylov
-
Alexey Semenyuk
-
Andrew Haley
-
David Holmes
-
Erik Helin
-
John Paul Adrian Glaubitz
-
Kim Barrett
-
Lindenmaier, Goetz
-
Magnus Ihse Bursie
-
mark.reinhold＠oracle.com
-
Martijn Verburg
-
Thomas Stüfe
-
Volker Simonis