Andrew John Hughes wrote:
2009/8/28 Joseph D. Darcy :
Hello.
More cleanup of docs build warnings; this time from
javax.sql.rowset.BaseRowSet.java where non-existent getter methods are
repeatedly referenced. Assuming someone approves the change, I'll file a
bug and commit the fix.
-Joe
-
2009/8/28 Joseph D. Darcy :
> Hello.
>
> More cleanup of docs build warnings; this time from
> javax.sql.rowset.BaseRowSet.java where non-existent getter methods are
> repeatedly referenced. Assuming someone approves the change, I'll file a
> bug and commit the fix.
>
> -Joe
>
> --- old/src/share/
Changeset: 5342b0cdbf95
Author:xlu
Date: 2009-08-27 18:00 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5342b0cdbf95
6876282: BigDecimal's divide(BigDecimal bd, RoundingFormat r) produces
incorrect result
Reviewed-by: darcy
! src/share/classes/java/math/BigDecimal.java
! t
Hi Joe,
I will look at this get back to you. There is already a CR for
cleaning up the rowset javadocs.
I also need to compare the version in OpenJDK to what is in the Rowset
workspace as there looks to be some differences in the javadocs for this
class (where some of the errors below hav
Changeset: 477c5bf1149c
Author:jjg
Date: 2009-08-27 18:25 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/477c5bf1149c
6876765: javah tests fail on Windows
Reviewed-by: darcy
! test/tools/javah/6257087/foo.sh
! test/tools/javah/ConstMacroTest.sh
! test/tools/javah/Missi
Hello.
More cleanup of docs build warnings; this time from
javax.sql.rowset.BaseRowSet.java where non-existent getter methods are
repeatedly referenced. Assuming someone approves the change, I'll file
a bug and commit the fix.
-Joe
--- old/src/share/classes/javax/sql/rowset/BaseRowSet.java
Changeset: f29068bfeaed
Author:jjg
Date: 2009-08-27 17:50 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f29068bfeaed
6876755: apt tests fail on Windows
Reviewed-by: darcy
! test/tools/apt/Basics/apt.sh
! test/tools/apt/Basics/print.sh
! test/tools/apt/Compile/compile.
Changeset: 2c20f17c429c
Author:jjg
Date: 2009-08-27 17:39 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2c20f17c429c
6876753: javap tests fail on Windows
Reviewed-by: darcy
! test/tools/javap/T4975569.java
! test/tools/javap/T6729471.java
! test/tools/javap/pathsep.sh
Changeset: 74760fd5197f
Author:jjg
Date: 2009-08-27 15:12 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/74760fd5197f
6843707: bad tests generate files in the test/ directory
6876699: generated files in repository
Reviewed-by: darcy
- test/tools/javac/meth/InvokeMH_BAD
Am 27.08.2009 22:17, Xueming Shen schrieb:
I'm reading all those 100xxx one by one. The problem is that you've
mixed too many things together in one bag and there are
too many "dependencies" among them.
Yes, there are indeed many dependencies in 100098. The before 100098
changes have been mor
Ulf Zibis wrote:
Am 27.08.2009 20:03, Xueming Shen schrieb:
Ulf Zibis wrote:
Am 26.08.2009 21:01, Xueming Shen schrieb:
> - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see
jdk1.7.0/src.zip)
Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the
code in the
gener
Am 27.08.2009 20:03, Xueming Shen schrieb:
Ulf Zibis wrote:
Am 26.08.2009 21:01, Xueming Shen schrieb:
> - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see
jdk1.7.0/src.zip)
Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the
code in the
generated source file h
I understand the advantage and as you wrote there are cases where this
is a disadvantage.
The thing is one can't even extend this class according the needed
functionality, since header is defined as private.
Guy
On Thu, Aug 27, 2009 at 8:27 PM, Martin Buchholz wrote:
> On Thu, Aug 27, 2009 at 10:
Am 27.08.2009 18:44, Kelly O'Hair schrieb:
Ulf Zibis wrote:
Am 26.08.2009 21:01, Xueming Shen schrieb:
> - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see
jdk1.7.0/src.zip)
Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the
code in the
generated source file
Changeset: 25371bf31658
Author:darcy
Date: 2009-08-27 11:48 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25371bf31658
6876628: @throw instead of @throws in two ParagraphView classes
Reviewed-by: peterz
! src/share/classes/javax/swing/text/ParagraphView.java
! src/share/cla
Changeset: ed31953ca025
Author:jjg
Date: 2009-08-27 11:08 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ed31953ca025
6875336: some tests should use /nodynamiccopyright/
Reviewed-by: darcy
! test/tools/javac/6521805/T6521805a.java
! test/tools/javac/6521805/T6521805a_1
Ulf Zibis wrote:
Am 26.08.2009 21:01, Xueming Shen schrieb:
> - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see
jdk1.7.0/src.zip)
Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the
code in the
generated source file have exactly the same line number as they
ap
On Thu, Aug 27, 2009 at 10:23, Guy Korland wrote:
> First I don't think this is the same issue, in the clear case, there's
> no reference from the root to any of the entries.
> Second as I know any MarkAndSweep GC should not suffer from such issue.
> Since the sweep phase should collect any unreach
Very interesting - thanks for the pointer to the bug id.
Chris, could you update the bug report to contain a (public) diff
of the actual changes that were made?
The bug report does not mention clear().
Curiously, the jsr166 team has been working on fixing the same
kinds of issues in java.util.conc
First I don't think this is the same issue, in the clear case, there's
no reference from the root to any of the entries.
Second as I know any MarkAndSweep GC should not suffer from such issue.
Since the sweep phase should collect any unreachable entry no matter
how many dead references point to it.
Ulf Zibis wrote:
Am 26.08.2009 21:01, Xueming Shen schrieb:
> - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see
jdk1.7.0/src.zip)
Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the
code in the
generated source file have exactly the same line number as they a
Am 27.08.2009 03:24, Martin Buchholz schrieb:
---
It would help to separate cosmetic and "real" changes to get them
reviewed and accepted.
I've thought of that, but how to deal best? 2 changesets for 1 Bug Id ?
-Ulf
I think this change was made to address:
4863813: Stressing single LinkedList from multiple threads causes
heapspace to completely
http://bugs.sun.com/view_bug.do?bug_id=4863813
-Chris.
Guy Korland wrote:
How does it help the GC?
As I understand the M&S algorithm, there's no real advantag
Sherman,
thanks for your detailed review.
Am 26.08.2009 20:02, Xueming Shen schrieb:
Ulf,
"get rid of sun.nio.cs.Surrogate" itself is not a sufficient enough
reason to add bunch of new supplementary
support related APIs into Character and CharBuffer classes. You
probably need to demonstrate
How does it help the GC?
As I understand the M&S algorithm, there's no real advantages in doing so.
In fact in many places to "null" references is considered to be an
anti pattern in java.
Guy
On Thu, Aug 27, 2009 at 4:37 PM, Tom Hawtin wrote:
> Guy Korland wrote:
>
>> It seems like linkedList.c
Am 26.08.2009 21:01, Xueming Shen schrieb:
> - Fixed ugly output of make/tools/src/build.tools.spp.Spp; (see
jdk1.7.0/src.zip)
Ulf, those buf.append(LNSEP) lines serve the purpose of keeping the
code in the
generated source file have exactly the same line number as they appear
in the
origi
Guy Korland wrote:
It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).
The code is like that on purpose(!). It was done to help GC, in mustang
IIRC. There really isn't a problem with clear() being O(n) - it's going
to take at least O(n) to populate it, and in realit
Martin, thanks for your review ...
Am 27.08.2009 03:24, Martin Buchholz schrieb:
On Wed, Aug 26, 2009 at 02:59, Ulf Zibis wrote:
Hi all,
I have put all important things of sun.nio.cs.Surrogate to java.* packages,
I guess. We likely could get rid of it.
I am in principle of adding th
Changeset: 8109aa93b212
Author:mcimadamore
Date: 2009-08-27 13:40 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8109aa93b212
6840638: Project Coin: Improved Type Inference for Generic Instance Creation
(aka 'diamond')
Summary: diamond operator implementation (simple a
First, LinkedList by definition is not thread safe so there's no need
to care about concurrency.
Second this is what modCount is all about, preventing an iterator to
keep on working.
Guy
On Thu, Aug 27, 2009 at 3:35 PM, Carsten Otto
wrote:
>
> On Thu, Aug 27, 2009 at 03:31:13PM +0300, Guy Korland
On Thu, Aug 27, 2009 at 03:31:13PM +0300, Guy Korland wrote:
> It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).
With your solution one would be possible to continue working (traversing)
on an empty (read: emptied) list. I don't think this is desired.
Best regards,
--
Hi,
It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).
Meaning:
308 public void clear() {
309 Entry e = header.next;
310 while (e != header) {
311 Entry next = e.next;
312 e.next = e.previo
32 matches
Mail list logo
