Changeset: 2443d24d096a
Author:vromero
Date: 2012-11-01 13:06 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2443d24d096a
6949443: visitTree assertion triggered using -Xjcov on small sample program
Reviewed-by: jjg, mcimadamore
! src/share/classes/com/sun/tools/javac/j
Hi Remi,
Thank you for the feedback
On Nov 2, 2012, at 7:42 PM, Remi Forax wrote:
> On 11/02/2012 11:57 PM, Lance Andersen - Oracle wrote:
>> This is similar to 8001536, just additional classes.
>>
>> This adds read/writeObject, equals, clone methods to additional SerialXXX
>> classes
>>
>> SQ
On 11/02/2012 11:57 PM, Lance Andersen - Oracle wrote:
This is similar to 8001536, just additional classes.
This adds read/writeObject, equals, clone methods to additional SerialXXX
classes
SQE, JCK and JDBC Unit tests all pass.
The webrev can be viewed at http://cr.openjdk.java.net/~lancea/8
On 11/02/2012 11:44 PM, Joe Darcy wrote:
On 10/15/2012 03:56 AM, Alan Bateman wrote:
On 15/10/2012 11:28, Joel Borggrén-Franck wrote:
On 10/15/2012 12:34 AM, David Holmes wrote:
> Remi,
>
> This ship has sailed you can't recall it.
CloneNotSupportedException > is a checked exception and needs
This is similar to 8001536, just additional classes.
This adds read/writeObject, equals, clone methods to additional SerialXXX
classes
SQE, JCK and JDBC Unit tests all pass.
The webrev can be viewed at http://cr.openjdk.java.net/~lancea/8002212/webrev.00
Best
Lance
Lance Andersen| Principal M
On 10/15/2012 03:56 AM, Alan Bateman wrote:
On 15/10/2012 11:28, Joel Borggrén-Franck wrote:
On 10/15/2012 12:34 AM, David Holmes wrote:
> Remi,
>
> This ship has sailed you can't recall it.
CloneNotSupportedException > is a checked exception and needs to
remain so for source and binary
> com
On 02/11/2012 18:36, Staffan Larsen wrote:
This is a preliminary review request for adding an API for tracing I/O calls.
For now, this is an empty infrastructure intended to enable diagnosing/tracing
of i/o calls. A user of the API can register a listener and get callbacks for
read and write o
Include me on any review requests for these things, I'll be happy to be a
reviewer.
-kto
On Nov 2, 2012, at 1:08 PM, Steve Sides wrote:
> On 11/2/2012 9:47 AM, Kelly O'Hair wrote:
>>
>> It looked fine to me.
>>
>> One of the reasons this has fallen through the cracks so much is because
>> no
Hi Vladimir,
Thanks for the review!
Jiangli
On 11/02/2012 03:03 PM, Vladimir Kozlov wrote:
Looks good.
We know that VerifyDependencies has significant effect on debug VM
performance.
Thanks,
Vladimir
Jiangli Zhou wrote:
Redirecting the review request to [email protected] mail
Changeset: bf76f4190ef8
Author:jjg
Date: 2012-11-02 14:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf76f4190ef8
7169362: JDK8: Write compiler tests for repeating annotations for JDK8
Reviewed-by: darcy, jjg
Contributed-by: [email protected]
+ test/tools/java
On 11/02/2012 02:33 PM, Jiangli Zhou wrote:
Redirecting the review request to [email protected] mail
list (second try) ...
Here is the webrev based on the jdk8/tl/jdk repository:
http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/
The '-XX:+IgnoreUnrecognizedVMOptions -XX:-Ver
On 11/2/2012 1:47 PM, Staffan Larsen wrote:
On 2 nov 2012, at 21:12, Mandy Chung wrote:
The *Begin() methods return a "handle" that will be passed to the *End()
methods. Have you considered to define a type for it rather than Object?
Something like an empty interface, just to signal the int
Changeset: 75c936d14c6a
Author:vromero
Date: 2012-11-01 12:47 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/75c936d14c6a
8000483: cryptic error message when source file contains hash
Summary: cryptic error message when source file contains hash
Reviewed-by: jjg, mcimad
On 11/02/2012 09:49 PM, Staffan Larsen wrote:
Thanks, Jim. I'll come back with micro-benchmark numbers.
/Staffan
I think this code is a good candidate for the almost final design pattern :)
http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field
Basica
Hi David, Kelly, Erik,
as Kelly stated the jdk only build, uses the compiler from the
import JDK, this works with -source 8 -target, which was prepped
by Joe earlier. I also checked with a jdk only jprt build submission,
which exposed another location that needed a bump.
I have fixed the new in
Thanks, Jim. I'll come back with micro-benchmark numbers.
/Staffan
On 2 nov 2012, at 21:27, Jim Gish wrote:
> Hi Staffan,
>
> This looks fine to me as well, but I had the same question as Mandy about
> performance. Given the sensitivity to changes in I/O it would be good to
> have some micr
On 2 nov 2012, at 21:12, Mandy Chung wrote:
> Hi Staffan,
>
> On 11/2/2012 11:36 AM, Staffan Larsen wrote:
>> This is a preliminary review request for adding an API for tracing I/O
>> calls. For now, this is an empty infrastructure intended to enable
>> diagnosing/tracing of i/o calls. A user
Hi Staffan,
This looks fine to me as well, but I had the same question as Mandy
about performance. Given the sensitivity to changes in I/O it would be
good to have some micro-benchmarks here.
Thanks,
Jim
On 11/02/2012 04:12 PM, Mandy Chung wrote:
Hi Staffan,
On 11/2/2012 11:36 AM, Staff
Hi Staffan,
On 11/2/2012 11:36 AM, Staffan Larsen wrote:
This is a preliminary review request for adding an API for tracing I/O calls.
For now, this is an empty infrastructure intended to enable diagnosing/tracing
of i/o calls. A user of the API can register a listener and get callbacks for
r
On 11/2/2012 9:47 AM, Kelly O'Hair wrote:
It looked fine to me.
One of the reasons this has fallen through the cracks so much is
because nobody has any time to do it.
Completely automating it is risky, and it needs to be reviewed. So it
needs an official owner and
I agree. You can't completel
This is a preliminary review request for adding an API for tracing I/O calls.
For now, this is an empty infrastructure intended to enable diagnosing/tracing
of i/o calls. A user of the API can register a listener and get callbacks for
read and write operations on sockets and files. It does not (
On 11/2/2012 5:46 AM, Alan Bateman wrote:
Now for some noise.
The copyright date in the source files needs updating. The man behind
the curtain is Steve Sides from the Quality and Release Engineering
team in Oracle. Jon pushed, on Steve's behalf, the update to the
langtools files recently [1
All changes to JDK sources require a CR, an OpenJDK author name, and a review
by a second OpenJDK author.
So although you can automate the preparation of the commit, you cannot fully
automate this process.
There have been many discussions over the years about automating various
changes, anythin
So the 3000+ files Alan is referring to are all files which have been
modified but which haven't had their year updated? If we're not worried
about files which haven't been modified then a pre/post-commit script
will suffice and depending on how we implement it we might not need
periodic updat
It looked fine to me.
One of the reasons this has fallen through the cracks so much is because nobody
has any time to do it.
Completely automating it is risky, and it needs to be reviewed. So it needs an
official owner and
someone to automate the whole thing as much as possible.
My recommendati
> but ultimately there are files which never get touched which will
need processing to update the year.
The policy has varied over the years, but presently the policy is not to
update the year in files that have not been updated code-wise.
-phil.
On 11/2/2012 9:37 AM, Darryl Mocek wrote:
Alan
Alan,
I was responsible for updating the copyrights for JavaME. I used a
Perl script to update the copyright year in the source files. I can
point you to the relevant information if you like. There were challenges
as there are various copyrights in the source files (Oracle, Oracle +
3rd
Hi Alan,
Thank you for doing this. I see that Kumar volunteered to be your reviewer.
So are you pushing the change today?
> BTW: Would it make sense to integrate jdk8/tl -> master next week too?
I thought about this too and yes, this would make everybody's life easier.
I can start TL PIT as soon
On 02/11/2012 16:08, Phil Race wrote:
Looks fine to me although I don't know how I can easily (ie not
tediously)
verify that a particular file is correctly updated to 2011 vs 2012 ..
Thanks, although I've already pushed it, just to get it out of the way.
I looked at a few samples, as I think Ch
Looks fine to me although I don't know how I can easily (ie not tediously)
verify that a particular file is correctly updated to 2011 vs 2012 ..
I don't think doing the updates at integration time is particularly
desirable
as it would suggest that a file is updated once by the engineer who is
m
On 02/11/2012 13:44, Chris Hegarty wrote:
I'm not sure what you are looking for here, but I skimmed quickly up
and down the patch stopping occasionally, and the updated headers look
ok.
On the general issue, is there a reason what on the 1st of January
ever source file cannot have its year ra
Changeset: 98a47dc23296
Author:peytoia
Date: 2012-11-02 23:17 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a47dc23296
8001209: Evaluate findbugs reprot for java.text.ChoiceFormat
Reviewed-by: okutsu
! src/share/classes/java/text/ChoiceFormat.java
+ test/java/text/Format/
Alan,
I grepped the patch and it seems to be ok.
You can add me as a reviewer.
Kumar
Now for some noise.
The copyright date in the source files needs updating. The man behind
the curtain is Steve Sides from the Quality and Release Engineering
team in Oracle. Jon pushed, on Steve's behalf,
I'm not sure what you are looking for here, but I skimmed quickly up and
down the patch stopping occasionally, and the updated headers look ok.
On the general issue, is there a reason what on the 1st of January ever
source file cannot have its year range updated to that year. Then just
forget
Now for some noise.
The copyright date in the source files needs updating. The man behind
the curtain is Steve Sides from the Quality and Release Engineering team
in Oracle. Jon pushed, on Steve's behalf, the update to the langtools
files recently [1], and Mikael updated hotspot [2]. The elep
On 11/02/2012 11:03 AM, Alexander Knöller wrote:
Hello there.
(Reposting this request for improvement as suggested in mailing list jdk6-dev)
java.lang.Class.getAnnotations() always enters a synchronized-block
(initAnnotationsIfNecessary() ), slowing down multi core machines that heavily
make
Hello there.
(Reposting this request for improvement as suggested in mailing list jdk6-dev)
java.lang.Class.getAnnotations() always enters a synchronized-block
(initAnnotationsIfNecessary() ), slowing down multi core machines that heavily
make use of Annotations.
(in our Case we use LoadTimeWea
37 matches
Mail list logo
