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
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
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:
> On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk
> 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
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 wrote:
On 3/2/20 10:46 PM, Volker Simonis wrote:
As lead of the 8 and 11
On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley 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. :-)
>
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
On 3/2/20 9:51 PM, Kim Barrett wrote:
>> On Mar 2, 2020, at 7:00 AM, Andrew Haley 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
Andrew Haley 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
> On Mar 2, 2020, at 7:00 AM, Andrew Haley 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
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
On 20/11/2018 6:39 am, Kim Barrett wrote:
On Nov 19, 2018, at 7:56 AM, David Holmes wrote:
On 19/11/2018 5:04 pm, Kim Barrett wrote:
On Nov 19, 2018, at 1:31 AM, David Holmes wrote:
Hi Kim,
On 16/11/2018 12:31 pm, Kim Barrett wrote:
This doesn't strike me as a JEP that actually integrates
> On Nov 19, 2018, at 7:56 AM, David Holmes wrote:
>
> On 19/11/2018 5:04 pm, Kim Barrett wrote:
>>> On Nov 19, 2018, at 1:31 AM, David Holmes 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.
On 19/11/2018 5:04 pm, Kim Barrett wrote:
On Nov 19, 2018, at 1:31 AM, David Holmes wrote:
Hi Kim,
On 16/11/2018 12:31 pm, Kim Barrett wrote:
On Oct 3, 2018, at 3:13 PM, Kim Barrett wrote:
I've submitted a JEP for
(1) enabling the use of C++14 Language Features when building the JDK,
(2)
On Mon, Nov 19, 2018 at 9:00 AM Kim Barrett wrote:
>
> > On Nov 19, 2018, at 2:04 AM, Kim Barrett wrote:
> >
> >> On Nov 19, 2018, at 1:31 AM, David Holmes 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
> On Nov 19, 2018, at 2:04 AM, Kim Barrett wrote:
>
>> On Nov 19, 2018, at 1:31 AM, David Holmes 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
> On Nov 19, 2018, at 1:31 AM, David Holmes wrote:
>
> Hi Kim,
>
> On 16/11/2018 12:31 pm, Kim Barrett wrote:
>>> On Oct 3, 2018, at 3:13 PM, Kim Barrett wrote:
>>>
>>> I've submitted a JEP for
>>>
>>> (1) enabling the use of C++14 Language Features when building the JDK,
>>>
>>> (2) define
Hi Kim,
On 16/11/2018 12:31 pm, Kim Barrett wrote:
On Oct 3, 2018, at 3:13 PM, 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
> On Oct 3, 2018, at 3:13 PM, 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
On 16/10/2018 02:25, Kim Barrett wrote:
On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov
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
> On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov
> 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
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
> On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov
> 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
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
Hi Kim,
On Mon, Oct 8, 2018 at 8:32 PM Kim Barrett wrote:
>
> > On Oct 8, 2018, at 6:48 AM, Thomas Stüfe 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
> On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov
> 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
> On Oct 8, 2018, at 6:48 AM, Thomas Stüfe 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
On Mon, Oct 8, 2018 at 12:49 PM Thomas Stüfe 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.
>
> HotSpot
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.
HotSpot makes very limited use of namespaces.
Not really true, we already use
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
On 10/4/18 2:31 PM, Magnus Ihse Bursie wrote:>> 4 okt. 2018 kl. 10:57
skrev Martijn Verburg :
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
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
> On Oct 4, 2018, at 4:35 AM, Volker Simonis 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)
>
> https://bugs.openjdk.java.net/browse/JDK-8208089
Note that this list
> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov
> 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
> 4 okt. 2018 kl. 10:57 skrev Martijn Verburg :
>
> 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
>
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
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
2018/10/3 12:13:15 -0700, kim.barr...@oracle.com:
> ...
>
> https://bugs.openjdk.java.net/browse/JDK-8208089
Or, more readably: https://openjdk.java.net/jeps/8208089
- Mark
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.
39 matches
Mail list logo
