Hi Prakhar,
It's a bit late for Joe so allow me ...
On 9/10/2018 2:59 PM, Prakhar Makhija wrote:
Thanks Joseph, I'll check Skara.
I found one reference of "hgForest.sh"
I presume it is for cloning / pulling the jdk src projects, perhaps the hg
trees you are mentioning
A leftover from when we
Thanks Joseph, I'll check Skara.
I found one reference of "hgForest.sh"
I presume it is for cloning / pulling the jdk src projects, perhaps the hg
trees you are mentioning
Kindly tell me the process to clone the hg trees
Please also help me out with the development process here
Every time is th
The Skara project
(http://mail.openjdk.java.net/mailman/listinfo/skara-dev) has a JDK 12
mirror at
https://github.com/Project-Skara/jdk/
-Joe
On 10/8/2018 10:37 AM, Bernd Eckenfels wrote:
Hello,
there is no official/canonical one as far as I know, but there are a few
(externally mainta
> On Oct 8, 2018, at 4:10 PM, Alan Bateman wrote:
>
> On 08/10/2018 20:11, Kim Barrett wrote:
>> Please review this small change to native code in the (deprecated)
>> jdk.pack module. The existing code triggers a warning when building
>> with gcc with -std=c++11 or -std=c++14.
>>
>> CR:
>> http
Hello,
Please review the changes to address:
JDK-8058202 : AnnotatedType implementations don't override
toString(), equals(), hashCode()
http://cr.openjdk.java.net/~darcy/8058202.2/
Some discussion and explanation of the changes:
The java.lang.reflect.AnnotatedType interface hierarch
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,
there's been a history of deadlocks when attempting to close() various
streams which predates OpenJDK bug and source history, so I believe
having close synchronize on this is a bad idea. This move from
AtomicBoolean to a volatile for signaling should be semantically neutral
and more or le
On 08/10/2018 20:11, Kim Barrett wrote:
Please review this small change to native code in the (deprecated)
jdk.pack module. The existing code triggers a warning when building
with gcc with -std=c++11 or -std=c++14.
CR:
https://bugs.openjdk.java.net/browse/JDK-8211804
Webrev:
http://cr.openjdk.
On 08/10/2018 20:01, Xueming Shen wrote:
On 10/6/18, 1:54 AM, Alan Bateman wrote:
On 06/10/2018 09:29, Xueming Shen wrote:
The created mr jar file is being tested in #139 with
versionedStream(). Without the fix there will be a npe.
Right but it's not testing that the versioned stream doesn
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 namesp
Hello,
just noticed it is probably intended to not be synchronized for the reads
(since it is volatile)?.
In that case using `this` monitor would also allow to remove the volatile.
However not sure if that is good or bad for the Performance (close does not do
DCL then anymore, but ist probably
> 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 to
getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does
I guess work since the important part is make sure only one thread does the
close work, however Publishing the close change to getChannel is a secondary
effect of the AtomicBoolean which the new Version does not have(
Please review this small change to native code in the (deprecated)
jdk.pack module. The existing code triggers a warning when building
with gcc with -std=c++11 or -std=c++14.
CR:
https://bugs.openjdk.java.net/browse/JDK-8211804
Webrev:
http://cr.openjdk.java.net/~kbarrett/8211804/open.00/
Testi
On 10/6/18, 1:54 AM, Alan Bateman wrote:
On 06/10/2018 09:29, Xueming Shen wrote:
The created mr jar file is being tested in #139 with
versionedStream(). Without the fix there will be a npe.
Right but it's not testing that the versioned stream doesn't include
META-INF/Foo.class. We need some
> 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 t
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/
On 08/10/2018 16:32, Claes Redestad wrote:
Hi,
aligning the closing of RandomAccessFiles with the implementation in
FileInput-/OutputStream improves startup in a few tests.
Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8211859
This
On 2018-10-08 17:51, Alan Bateman wrote:
On 08/10/2018 16:24, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manife
On 08/10/2018 16:24, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest
doesn't eagerly read in the property val
Thanks, Sean!
/Claes
On 2018-10-08 17:47, Sean Mullan wrote:
Looks good to me.
--Sean
On 10/8/18 11:24 AM, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used i
Looks good to me.
--Sean
On 10/8/18 11:24 AM, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest doesn't
eagerly
+1
> On Oct 8, 2018, at 11:34 AM, Chris Hegarty wrote:
>
> Can I get a review to add javax/naming/module/RunBasic.java
> to the ProblemList until we can resolve 8211850. This test
> has been failing intermittently for months now.
>
> $ hg diff test/jdk/ProblemList.txt
> diff --git a/test/jdk/Pro
Can I get a review to add javax/naming/module/RunBasic.java
to the ProblemList until we can resolve 8211850. This test
has been failing intermittently for months now.
$ hg diff test/jdk/ProblemList.txt
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
Hi,
aligning the closing of RandomAccessFiles with the implementation in
FileInput-/OutputStream improves startup in a few tests.
Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8211859
Thanks!
/Claes
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest doesn't
eagerly read in the property value in the static initializer avoids this.
Web
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 ,
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
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 mak
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 t
29 matches
Mail list logo
