date:20130219


On 19/02/2013 06:58, Joe Darcy wrote:

Hello,

Please review these two simple fixes for javadoc warnings I noticed 
during a build (I'll file a bug after getting a review):
Looks okay to me too, we seem to have picked up several javadoc warnings 
recently.


-Alan

Truncate a LinkedList

2013-02-19 Thread Weijun Wang


Hi All

I'm using LinkedList to maintain a history and the elements are ordered 
by their timestamps. Every now and then I would expunge the list, that 
is to say, iterating through the list and when an element is old enough 
all elements after (and including) it will be removed. Currently I'm 
removing them one by one.


Is there a way to truncate the list using a single method?

Thanks
Max

Re: Truncate a LinkedList

2013-02-19 Thread Daniel Fuchs


On 2/19/13 11:27 AM, Weijun Wang wrote:

Hi All

I'm using LinkedList to maintain a history and the elements are ordered
by their timestamps. Every now and then I would expunge the list, that
is to say, iterating through the list and when an element is old enough
all elements after (and including) it will be removed. Currently I'm
removing them one by one.

Is there a way to truncate the list using a single method?

Thanks
Max


Hi Max,

You could try to use AbstractList.subList(...)

http://docs.oracle.com/javase/6/docs/api/java/util/AbstractList.html#subList%28int,%20int%29

Quoting from the doc:


For example, the following idiom removes a range of elements from a list:

  list.subList(from, to).clear();



-- daniel

Re: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone

2013-02-19 Thread Stephen Colebourne

On 19 February 2013 06:58, Joe Darcy joe.da...@oracle.com wrote:
 diff -r bcde0486261e
 src/share/classes/java/time/format/DateTimeFormatterBuilder.java
 --- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon
 Feb 18 08:14:18 2013 +
 +++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon
 Feb 18 22:55:56 2013 -0800
 @@ -1007,7 +1007,7 @@
   * is used, with {@code IsoChronology} as the fallback.
   * p
   * Note that this method provides similar functionality to methods on
 - * {@code DateFormat} such as {@link
 DateFormat#getDateTimeInstance(int, int)}.
 + * {@code DateFormat} such as {@link
 java.text.DateFormat#getDateTimeInstance(int, int)}.

My preference would have been to add an import statement, but this fix is fine.

Stephen

Re: RFR: 8007806: Need a Throwables performance counter

2013-02-19 Thread Nils Loodin


Hey Kasper!

You're right that there are methods that throw exceptions as a part of 
the normal program flow.


However, this number can be (and has been) used as a very high level 
telemetry for an application. Depending on exactly how large this number 
is, and how fast it is growing, something can be seen to be amis in the 
application. Paired together with data of what type of exceptions are 
being thrown, and from where, it can be useful for support to have this 
information.


Regards,
Nils Loodin

On 02/12/2013 06:28 PM, Kasper Nielsen wrote:

Jrockit mission control supports an exception count based on exception
type.

I have found the approach of just counting the total number of exception
completely useless.
Mainly because there are methods that throw exceptions as part of the
normal flow. For example, Class.forName() is commonly used to test
whether or not a certain
class is on the classpath.

And most developers will cringe whenever they see an exception count0
for an application they think is bug free.





On Fri, Feb 8, 2013 at 6:10 PM, Nils Loodin nils.loo...@oracle.com
mailto:nils.loo...@oracle.com wrote:

It would be interesting to know the number of thrown throwables in
the JVM, to be able to do some high level application diagnostics /
statistics. A good way to put this number would be a performance
counter, since it is accessible both from Java and from the VM.

http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=8007806
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007806
http://cr.openjdk.java.net/~__nloodin/8007806/webrev.00/
http://cr.openjdk.java.net/~nloodin/8007806/webrev.00/

Regards,
Nils Loodin

Re: Truncate a LinkedList

2013-02-19 Thread Peter Levart


On 02/19/2013 11:38 AM, Daniel Fuchs wrote:

On 2/19/13 11:27 AM, Weijun Wang wrote:

Hi All

I'm using LinkedList to maintain a history and the elements are ordered
by their timestamps. Every now and then I would expunge the list, that
is to say, iterating through the list and when an element is old enough
all elements after (and including) it will be removed. Currently I'm
removing them one by one.

Is there a way to truncate the list using a single method?

Thanks
Max


Hi Max,

You could try to use AbstractList.subList(...)

http://docs.oracle.com/javase/6/docs/api/java/util/AbstractList.html#subList%28int,%20int%29 



Quoting from the doc:

For example, the following idiom removes a range of elements from a 
list:


  list.subList(from, to).clear();


Hi Daniel,

That's not terribly efficient. It does the list.removeRange(from, to) 
which iterates the list again from the beginning to from followed by 
iterating elements further to to while removing elements one-by-one. 
That's worse than Weijun's original algorithm which iterates the 
elements from 1st to from only once.


I would make my own linked structure for that task, but if you want to 
stick with LinkedList, your expunging algorithm could copy the 
elements, from the 1st to the one that is the last to be kept, into a 
new LinkedList and then just exchange the old list with the new...


Regards, Peter



-- daniel

Re: Truncate a LinkedList

2013-02-19 Thread Peter Levart

On 02/19/2013 01:24 PM, Peter Levart wrote:

On 02/19/2013 11:38 AM, Daniel Fuchs wrote:

On 2/19/13 11:27 AM, Weijun Wang wrote:

Hi All

I'm using LinkedList to maintain a history and the elements are ordered
by their timestamps. Every now and then I would expunge the list,
that

is to say, iterating through the list and when an element is old enough
all elements after (and including) it will be removed. Currently I'm
removing them one by one.

Is there a way to truncate the list using a single method?

Thanks
Max

Hi Max,

You could try to use AbstractList.subList(...)

http://docs.oracle.com/javase/6/docs/api/java/util/AbstractList.html#subList%28int,%20int%29

Quoting from the doc:

For example, the following idiom removes a range of elements from a
list:

list.subList(from, to).clear();

Hi Daniel,

That's not terribly efficient. It does the list.removeRange(from, to)
which iterates the list again from the beginning to from followed by
iterating elements further to to while removing elements one-by-one.
That's worse than Weijun's original algorithm which iterates the
elements from 1st to from only once.

I would make my own linked structure for that task, but if you want to
stick with LinkedList, your expunging algorithm could copy the
elements, from the 1st to the one that is the last to be kept, into a
new LinkedList and then just exchange the old list with the new...

Hi Weijun,

The above would be efficient if the remaining head is small compared
to the discarded tail. If it's the other way around, you could iterate
the LinkedList from the end backwards and remove the elements along the
way until you reach the one you want to keep...

Regards, Peter

-- daniel

Re: Truncate a LinkedList

2013-02-19 Thread Stephen Colebourne

On 19 February 2013 10:27, Weijun Wang weijun.w...@oracle.com wrote:
 I'm using LinkedList to maintain a history

Don't use LinkedList. Multiple benchmarks down the years have shown it
is almost always worse than ArrayList.

Stephen


 and the elements are ordered by
 their timestamps. Every now and then I would expunge the list, that is to
 say, iterating through the list and when an element is old enough all
 elements after (and including) it will be removed. Currently I'm removing
 them one by one.

 Is there a way to truncate the list using a single method?

 Thanks
 Max

Re: JDK 8 request for review: two javadoc warning fixes, on in DateTimeFormatterBuilder, another in TimeZone

2013-02-19 Thread Roger Riggs


HI Joe,

These look fine.

I'd have been happy to fix these as ongoing ThreeTen work.
We'll need to be more careful merging now that changes will be coming 
from other

than the Threeten project.

Thanks, Roger


On 2/19/13 1:58 AM, Joe Darcy wrote:

Hello,

Please review these two simple fixes for javadoc warnings I noticed 
during a build (I'll file a bug after getting a review):


diff -r bcde0486261e 
src/share/classes/java/time/format/DateTimeFormatterBuilder.java
--- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java 
Mon Feb 18 08:14:18 2013 +
+++ b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java 
Mon Feb 18 22:55:56 2013 -0800

@@ -1007,7 +1007,7 @@
  * is used, with {@code IsoChronology} as the fallback.
  * p
  * Note that this method provides similar functionality to 
methods on
- * {@code DateFormat} such as {@link 
DateFormat#getDateTimeInstance(int, int)}.
+ * {@code DateFormat} such as {@link 
java.text.DateFormat#getDateTimeInstance(int, int)}.

  *
  * @param dateStyle  the date style to use, null means no date 
required
  * @param timeStyle  the time style to use, null means no time 
required

diff -r bcde0486261e src/share/classes/java/util/TimeZone.java
--- a/src/share/classes/java/util/TimeZone.javaMon Feb 18 08:14:18 
2013 +
+++ b/src/share/classes/java/util/TimeZone.javaMon Feb 18 22:55:56 
2013 -0800

@@ -534,7 +534,7 @@
 /**
  * Gets the {@code TimeZone} for the given {@code zoneId}.
  *
- * @param zoneid a {@link ZoneId} from which the time zone ID is 
obtained
+ * @param zoneId a {@link ZoneId} from which the time zone ID is 
obtained
  * @return the specified {@code TimeZone}, or the GMT zone if the 
given ID

  * cannot be understood.
  * @throws NullPointerException if {@code zoneId} is {@code null}

Thanks,

-Joe

hg: jdk8/tl/jdk: 2 new changesets

2013-02-19 Thread sean . coffey

Changeset: 885bb24f6018
Author:coffeys
Date:  2013-02-19 14:07 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/885bb24f6018

7197187: Currency.isPastCutoverDate should be made more robust
Reviewed-by: alanb

! src/share/classes/java/util/Currency.java

Changeset: 01b6b0dd2006
Author:coffeys
Date:  2013-02-19 14:12 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b6b0dd2006

8007315: HttpURLConnection.filterHeaderField method returns null where empty 
string is expected
Reviewed-by: chegar

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! test/sun/net/www/protocol/http/HttpOnly.java

Re: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence()

2013-02-19 Thread Remi Forax


Hi Mike,
I agree with Peter,
a new method is better than changing subSequence to return a 
CharSequence implementation that try to fake itself as a String.


And as a guys that have written several parsers (for HTTP servers or not),
ByteBuffer/CharBuffer was introduced in 1.4 to write effective parsers 
in Java,

no one should try write a Java parser using String buffers anymore.

Rémi

On 02/19/2013 10:28 AM, Peter Levart wrote:

Hi Mike,

Regarding the implementation details: I think it would be better to 
reference just the String's value[] array in the String.SubSequence 
instead of the String instance itself. Two reasons come to mind:


- eliminate another indirection when accessing the array
- when referencing the String instance, code like this would leak 
implementation details (again):


String s = new String(...);
CharSequence cs = s.subSequence(0, s.length()-1);
WeakReferenceString wr = new WeakReference(s);
// ... if we keep a reference to cs, wr will never be cleared...

Regarding the strategy: It's very unfortunate that code exists that 
uses String.subSequence result in a way treating it as an object with 
value semantics for equals() and hashCode() despite the specification 
for CharSequence clearly stating:


/This interface does not refine the general contracts of the 
//|equals| 
http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#equals%28java.lang.Object%29//and 
//|hashCode| 
http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode%28%29//methods. 
The result of comparing two objects that implement //CharSequence//is 
therefore, in general, undefined. Each object may be implemented by a 
different class, and there is no guarantee that each class will be 
capable of testing its instances for equality with those of the other. 
It is therefore inappropriate to use arbitrary 
//CharSequence//instances as elements in a set or as keys in a map./


The excuse for such usage is the specification of String.subSequence 
method:


/Returns a new character sequence that is a subsequence of this 
sequence. /


/An invocation of this method of the form /

   /  str.subSequence(begin, end)/

/behaves in exactly the same way as the invocation /

   /  str.substring(begin, end)/

/This method is defined so that the //String//class can implement the 
//|CharSequence| 
http://docs.oracle.com/javase/6/docs/api/java/lang/CharSequence.html//interface. 
/



So this proposal actually breaks this specification. It tries to break 
it in a way that would keep some of the usages still behave like 
before, but it can't entirely succeed. The following code is valid 
now, but will throw CCE with this proposal:


String s = ...;
String s0 = (String) s.subSequence(0, 1);

One can imagine other scenarios that would break (like custom 
comparators casting to String, etc.).


So to be entirely compatible, an escape-hatch would have to be 
available (in the form of a System property for example) to restore 
the old behaviour if requested.


If there is an escape-hatch, the question arises: Why not breaking the 
String.subSequence entirely? We could brake it so that the method 
would clearly specify the returned CharSequence behaviour regarding 
underlying value[] array sharing, hashCode(), equals(), subSequence() 
and Comparable only in terms of CharSequence instances returned from 
the method and not cross String - String.SubSequence.


This would encourage migration of behaviourally incompatible code to 
forms that are compatible with both pre JDK8 and post JDK8 
String.subSequence specification instead of keeping the status quo.


There's also a third option - adding new method (back-porting it to 
JDK7):


public String.SubSequence stringSubSequence(int, int);

...and keeping subSequence as is.

Regards, Peter

On 02/19/2013 06:27 AM, Mike Duigou wrote:

Hello all;

JDK 7u6 included a significant change to java.lang.String. The change 
was internal to the String implementation and didn't result in any 
API changes but it does have a significant impact on the performance 
of some uses cases. (See 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html 
for an earlier discussion)


Prior to 7u6 String maintained two fields count and offset which 
described the location within the character array of the String's 
characters. In 7u6 the count and offset fields were removed and 
String instances no longer share their character arrays with other 
String instances. Each substring(), subSequence() or split() now 
creates entirely new String instances for it's results. Before 7u6 
two or more instances of String could share the same backing 
character array. A number of String operations; clone(), split(), 
subString(), subSequence() did not copy the backing character array 
but created new String instances pointing at their character array 
with appropriate count and offset values.


As with most sharing techniques, there are tradeoffs. The 
count/offset approach works

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries



On 02/19/2013 05:29 AM, David Holmes wrote:

...
Aside: it would be much easier to maintain consistent style if we used a
template to define the main outline of each family of interfaces and
generated the specializations from that (similar to how we generate the
various bytebuffer classes).


Oh, please god no! I find the way the buffer classes are generated a 
real pain. Yes, it is good for maintaining consistency across similar 
versions, but I don't see that as a good justification to introduce this 
complexity. I was secretly hoping that nio Buffer generation would go 
away in jdk8.


-Chris.

Re: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence()

2013-02-19 Thread Ulf Zibis


Am 19.02.2013 06:27, schrieb Mike Duigou:

http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/


I think, you should add
|| (s instanceof AbstractStringBuilder)
as third in
else if ((s instanceof StringBuilder) || (s instanceof StringBuffer)) {
, as someone could use his own subclass of AbstractStringBuilder.

-Ulf

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries


On 02/19/2013 03:08 PM, Alan Bateman wrote:

On 19/02/2013 14:39, Chris Hegarty wrote:

:

Oh, please god no! I find the way the buffer classes are generated a
real pain. Yes, it is good for maintaining consistency across similar
versions, but I don't see that as a good justification to introduce
this complexity. I was secretly hoping that nio Buffer generation
would go away in jdk8.

I assume the pain with the generated buffer classes is in the IDE so
you need to remember to include the gensrc tree in the project.


Right, but this assumes you to have a build. They also don't play well 
with tools that index the source, like opengrok.


-Chris.



-Alan.

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries


Mike,

Thanks for updating the j.u.c classes. David seems to have covered most 
of the issues, otherwise looks fine to me.


On 02/19/2013 05:29 AM, David Holmes wrote:

...
package-info.java

I've flagged this elsewhere but you may not have seen it:

+ * Predicatelt;String

If we use lt; then we should also use gt;.


Additionally, typo

58  * and {@link java.util.function.Supplier} (@{code () - T}).

-Chris.

Re: JEP 161 SE Compact Profiles has pushed to jdk8/build forest


On 19/02/2013 01:54, David Holmes wrote:
The implementation support for the Reference Implementation of the SE 
Compact Profiles described by:


http://openjdk.java.net/jeps/161

has now been pushed to the jdk8/build forest ready for integration 
with jdk8/jdk8 in time for b78.


This reference implementation is for the Linux platform only.

To build the compact profiles JREs specify the profiles target to make:

make profiles

or to build the full JDK/JRE and profile images use:

make images profiles
One thing to add to David's mail. We have included a simple dependency 
analyzer that runs in the profiles build to catch changes that 
introduce new or undesirable dependencies, say someone mistakenly adds a 
dependency on AWT to one of the core classes. That should help catch 
issues quickly and also help keep the profile definitions up to date as 
jdk8 evolves.


-Alan

RFR: 8008262: pack200/MethodParameters change

2013-02-19 Thread Kumar Srinivasan


Hi,

fyi. Let me know if you have any comments, the change is simple, the flag
is being changed from a u4 to a u2.

This has already been reviewed by jrose.

http://cr.openjdk.java.net/~ksrini/8008262/webrev.jdk.0/

Thanks
Kumar

Re: RFR (XS) 8008089: Delete OS dependent check in JdkFinder.getExecutable()


On 13/02/2013 09:47, Yekaterina Kantserova wrote:

Hi everyone,

This small fixconcerns jdk.testlibrary.JdkFinder utility class. The 
check below is too OS dependent and should be deleted.

...
binPath += File.separatorChar + bin + File.separatorChar + 
executable;

File toolFile = new File(binPath);
== if (!toolFile.exists()) {
throw new RuntimeException(binPath +  does not exist);
}
...

On windows if executable is specified as e.g. 'java', without '.exe', 
the File exists() will fail. But it's still possible to run executable.

This looks okay to me, do you have someone to push this for you?

-Alan.

hg: jdk8/tl/jdk: 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc

2013-02-19 Thread chris . hegarty

Changeset: 824187de1591
Author:jzavgren
Date:  2013-02-19 16:19 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/824187de1591

8007609: WinNTFileSystem_md.c should correctly check value returned from realloc
Reviewed-by: alanb, chegar, dholmes

! src/windows/native/java/io/WinNTFileSystem_md.c

hg: jdk8/tl/jdk: 8008312: Re-enable MethodParameter tests in JDK

2013-02-19 Thread alan . bateman

Changeset: e20c1c9197bf
Author:emc
Date:  2013-02-19 17:09 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e20c1c9197bf

8008312: Re-enable MethodParameter tests in JDK
Reviewed-by: darcy

! src/share/classes/java/lang/reflect/Parameter.java
! test/java/lang/reflect/Parameter/WithParameters.java

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

2013-02-19 Thread Martin Buchholz

On Wed, Jan 16, 2013 at 7:01 AM, Chris Hegarty chris.hega...@oracle.comwrote:

 Thanks to all for the reviews and suggestions here. As you probably seen,
 I pushed these changes to jdk8/tl earlier today (sorry, I missed Alan as an
 official reviewer on the changeset.). Consider it an initial version,
 pending any outcome from this, or other, discussions.

 Also, 8006409: ThreadLocalRandom should dropping padding fields from its
 serialized form, has been filed to follow up on the changes required to
 update the serial form.

 For those watching, I was preferable to push on with these changes ( and I
 apologize if it appeared pushy ), as the Double/Long Adder/Accumulator
 implementation, Striped64, now has a dependency on this change. It has
 become unbearable to keep in sync with different version of across
 different repositories.


Taking a look at this, I don't see any reason why we can't simply do
(while maintaining serialization compatibility):

 diff --git a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java
b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java
--- a/src/share/classes/java/util/concurrent/ThreadLocalRandom.java
+++ b/src/share/classes/java/util/concurrent/ThreadLocalRandom.java
@@ -368,50 +368,6 @@
 private static final long serialVersionUID = -5851777807851030925L;

 /**
- * @serialField rnd long
- * @serialField initialized boolean
- * @serialField pad0 long
- * @serialField pad1 long
- * @serialField pad2 long
- * @serialField pad3 long
- * @serialField pad4 long
- * @serialField pad5 long
- * @serialField pad6 long
- * @serialField pad7 long
- */
-private static final ObjectStreamField[] serialPersistentFields = {
-new ObjectStreamField(rnd, long.class),
-new ObjectStreamField(initialized, boolean.class),
-new ObjectStreamField(pad0, long.class),
-new ObjectStreamField(pad1, long.class),
-new ObjectStreamField(pad2, long.class),
-new ObjectStreamField(pad3, long.class),
-new ObjectStreamField(pad4, long.class),
-new ObjectStreamField(pad5, long.class),
-new ObjectStreamField(pad6, long.class),
-new ObjectStreamField(pad7, long.class) };
-
-/**
- * Saves the {@code ThreadLocalRandom} to a stream (that is,
serializes it).
- */
-private void writeObject(java.io.ObjectOutputStream out)
-throws java.io.IOException {
-
-java.io.ObjectOutputStream.PutField fields = out.putFields();
-fields.put(rnd, 0L);
-fields.put(initialized, true);
-fields.put(pad0, 0L);
-fields.put(pad1, 0L);
-fields.put(pad2, 0L);
-fields.put(pad3, 0L);
-fields.put(pad4, 0L);
-fields.put(pad5, 0L);
-fields.put(pad6, 0L);
-fields.put(pad7, 0L);
-out.writeFields();
-}
-
-/**
  * Returns the {@link #current() current} thread's {@code
ThreadLocalRandom}.
  */
 private Object readResolve() {

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread


On 19/02/2013 17:48, Martin Buchholz wrote:

:

Taking a look at this, I don't see any reason why we can't simply do
(while maintaining serialization compatibility):
Right, it's not needed and I think we had Chris persuaded on this a few 
weeks ago. It does change the serialized form but that it's not an issue 
issue and it doesn't matter that they have the default value when 
deserialized on an older release.


-Alan.

hg: jdk8/tl/jdk: 7092447: Clarify the default locale used in each locale sensitive operation

2013-02-19 Thread naoto . sato

Changeset: af396ec087f4
Author:naoto
Date:  2013-02-19 10:34 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af396ec087f4

7092447: Clarify the default locale used in each locale sensitive operation
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormat.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/DecimalFormatSymbols.java
! src/share/classes/java/text/MessageFormat.java
! src/share/classes/java/text/NumberFormat.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/time/format/DateTimeFormatSymbols.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/Scanner.java

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries

2013-02-19 Thread Joe Darcy


On 02/19/2013 07:14 AM, Chris Hegarty wrote:

On 02/19/2013 03:08 PM, Alan Bateman wrote:

On 19/02/2013 14:39, Chris Hegarty wrote:

:

Oh, please god no! I find the way the buffer classes are generated a
real pain. Yes, it is good for maintaining consistency across similar
versions, but I don't see that as a good justification to introduce
this complexity. I was secretly hoping that nio Buffer generation
would go away in jdk8.

I assume the pain with the generated buffer classes is in the IDE so
you need to remember to include the gensrc tree in the project.

Right, but this assumes you to have a build. They also don't play well
with tools that index the source, like opengrok.




As an aside, a code generation technique that should play better with 
tooling would to be use an annotation processor to generate the code 
from within the context of the compiler/IDE. As a general-purpose 
meta-programming system, annotation processing doesn't have to be tied 
to annotations.


-Joe

Re: hg: jdk8/tl/langtools: 8006212: javac, convert jtreg tests from shell script to java

2013-02-19 Thread Jonathan Gibbons

Woohoo -- 23 shell tests replaced with equivalent Java code: that's over 
2/3 of the shell tests in langtools/test.


-- Jon

On 02/19/2013 09:54 AM, vicente.rom...@oracle.com wrote:

Changeset: dc8b7aa7cef3
Author:vromero
Date:  2013-02-19 17:53 +
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dc8b7aa7cef3

8006212: javac, convert jtreg tests from shell script to java
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java
+ test/tools/apt/Basics/CheckAptIsRemovedTest.java
- test/tools/apt/Basics/NullAPF.java
- test/tools/apt/Basics/apt.sh
- test/tools/apt/verifyVariables.sh
+ test/tools/javac/4846262/CheckEBCDICLocaleTest.java
- test/tools/javac/4846262/Test.java
- test/tools/javac/4846262/Test.out
- test/tools/javac/4846262/Test.sh
+ test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java
- test/tools/javac/6302184/T6302184.sh
+ test/tools/javac/ClassPathTest/ClassPathTest.java
- test/tools/javac/ClassPathTest/ClassPathTest.sh
- test/tools/javac/ClassPathTest/ClassPathTest1.java
- test/tools/javac/ClassPathTest/ClassPathTest2.java
- test/tools/javac/ClassPathTest/ClassPathTest3.java
- test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java
- test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java
- test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java
+ test/tools/javac/ExtDirs/ExtDirTest.java
- test/tools/javac/ExtDirs/ExtDirTest_1.java
- test/tools/javac/ExtDirs/ExtDirTest_2.java
- test/tools/javac/ExtDirs/ExtDirTest_3.java
- test/tools/javac/ExtDirs/ExtDirs.sh
- test/tools/javac/MissingInclude.java
- test/tools/javac/MissingInclude.sh
+ test/tools/javac/MissingInclude/MissingIncludeTest.java
- test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh
- test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java
+ test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java
- test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java
- test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java
- test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java
+ test/tools/javac/T5090006/AssertionFailureTest.java
- test/tools/javac/T5090006/T5090006.java
- test/tools/javac/T5090006/compiler.sh
- test/tools/javac/constDebug/ConstDebug.java
- test/tools/javac/constDebug/ConstDebug.sh
+ test/tools/javac/constDebug/ConstDebugTest.java
- test/tools/javac/fatalErrors/NoJavaLang.java
- test/tools/javac/fatalErrors/NoJavaLang.out
- test/tools/javac/fatalErrors/NoJavaLang.sh
+ test/tools/javac/fatalErrors/NoJavaLangTest.java
- test/tools/javac/innerClassFile/Driver.sh
+ test/tools/javac/innerClassFile/InnerClassFileTest.java
- test/tools/javac/innerClassFile/x/B.java
- test/tools/javac/innerClassFile/x/C.java
- test/tools/javac/innerClassFile/y/Main.java
- test/tools/javac/innerClassFile/y/R1.java
- test/tools/javac/innerClassFile/y/R2.java
- test/tools/javac/innerClassFile/y/R3.java
- test/tools/javac/javazip/A.java
+ test/tools/javac/javazip/JavaZipTest.java
- test/tools/javac/javazip/Test.sh
- test/tools/javac/javazip/bad/B.java
- test/tools/javac/javazip/good/B.java
+ test/tools/javac/lib/ToolBox.java
+ test/tools/javac/links/LinksTest.java
- test/tools/javac/links/T.java
- test/tools/javac/links/b/B.java
- test/tools/javac/links/links.sh
+ test/tools/javac/newlines/NewLineTest.java
- test/tools/javac/newlines/Newlines.sh
+ test/tools/javac/stackmap/StackMapTest.java
- test/tools/javac/stackmap/T4955930.java
- test/tools/javac/stackmap/T4955930.sh
! test/tools/javac/unicode/SupplementaryJavaID6.java
- test/tools/javac/unicode/SupplementaryJavaID6.sh
+ test/tools/javah/6257087/T6257087.java
- test/tools/javah/6257087/foo.java
- test/tools/javah/6257087/foo.sh
- test/tools/javah/6257087/foo_bar.h
- test/tools/javah/ConstMacroTest.sh
- test/tools/javah/MissingParamClassException.java
- test/tools/javah/MissingParamClassTest.sh
- test/tools/javah/ParamClassTest.java
- test/tools/javah/SubClassConsts.java
- test/tools/javah/SubClassConsts.out
- test/tools/javah/SubClassConsts.win
- test/tools/javah/SuperClassConsts.java
+ test/tools/javah/T4942232/MissingParamClassTest.java
+ test/tools/javah/constMacroTest/ConstMacroTest.java
+ test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java
+ test/tools/javap/4866831/PublicInterfaceTest.java
- test/tools/javap/NotPackagePrivateInterface.java
- test/tools/javap/PublicInterfaceTest.sh
- test/tools/javap/pathsep.sh
+ test/tools/javap/stackmap/StackmapTest.java
- test/tools/javap/stackmap/T6271292.java
- test/tools/javap/stackmap/T6271292.out
- test/tools/javap/stackmap/T6271292.sh

Re: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence()


On 19/02/2013 05:27, Mike Duigou wrote:

:

http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/

 From our current testing we found that applications currently using subSequence() failed 
if the equals(), hashCode() and toString() implementations did not exactly match String. 
Additionally we had to change String.equals() so that it recognizes can return 
true for matching instances of String.SubSequence.

I'm not sure about this either, especially with String.equals clearly 
specifying that the argument must be a String.


The updates to AbstractStringBuilder append and insert seems unrelated, 
I assume you did measurements. Just wondering about separating them out 
as a separate patch?


-Alan

Re: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence()

2013-02-19 Thread Mike Duigou


On Feb 19 2013, at 10:50 , Alan Bateman wrote:

 On 19/02/2013 05:27, Mike Duigou wrote:
 :
 
 http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/
 
 From our current testing we found that applications currently using 
 subSequence() failed if the equals(), hashCode() and toString() 
 implementations did not exactly match String. Additionally we had to change 
 String.equals() so that it recognizes can return true for matching 
 instances of String.SubSequence.
 
 I'm not sure about this either, especially with String.equals clearly 
 specifying that the argument must be a String.

Yes, this patch is rather skanky in that it provides special not normally 
something anyone should ever do handling for String.SubSequence in 
String.equals().

This patch is an exploration of how far we could go to improve the performance 
of String.subSequence but it would certainly come at a definite cost. Creating 
this implementation has revealed usage patterns that are surprising and 
problematic (even with this patch).

 The updates to AbstractStringBuilder append and insert seems unrelated, I 
 assume you did measurements. Just wondering about separating them out as a 
 separate patch?

They certainly could be separated out. The changes in AbstractStringBuilder 
bring performance of:

StringBuilder.append(string, lower, upper);

in line with or improve upon:

StringBuilder.append(string.substring(lower, upper));

This change was generated in response to this comment from Martin Desruisseaux 
which seems entirely reasonable optimization:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010667.html

If I update this patch I will add Ulf suggestion of adding 
AbstractStringBuilder as a third instanceof case.

Mike

Re: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence()

2013-02-19 Thread Ulf Zibis


Am 19.02.2013 20:00, schrieb Mike Duigou:
If I update this patch I will add Ulf suggestion of adding AbstractStringBuilder as a third 
instanceof case. Mike 


Thanks!
I'm stil wondering, why HotSpot doesn't optimize
for (int i = start, j = count; i  end; i++, j++) {
value[j] = s.charAt(i);
}
to something equivalent of System.arrayCopy(...)
Maybe we could introduce a new intrinsic for something like
CharSequence.rangeCopy(int start, int end, CharSequence dst, int start)

-Ulf

hg: jdk8/tl/jdk: 8004561: Additional functional interfaces, extension methods and name changes

2013-02-19 Thread mike . duigou

Changeset: 16efb7ba188f
Author:mduigou
Date:  2013-02-19 11:56 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16efb7ba188f

8004561: Additional functional interfaces, extension methods and name changes
Summary: Adds additional functional interfaces for primitives and Bi (two 
operand). Adds utility extension methods. Includes some name changes for 
existing functional interfaces per EG decisions.
Reviewed-by: briangoetz, darcy, chegar, dholmes

! src/share/classes/java/time/chrono/HijrahDeviationReader.java
! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/share/classes/java/util/concurrent/atomic/Striped64.java
+ src/share/classes/java/util/function/BiConsumer.java
+ src/share/classes/java/util/function/BiFunction.java
+ src/share/classes/java/util/function/BiPredicate.java
! src/share/classes/java/util/function/BinaryOperator.java
- src/share/classes/java/util/function/Block.java
+ src/share/classes/java/util/function/BooleanSupplier.java
+ src/share/classes/java/util/function/Consumer.java
! src/share/classes/java/util/function/DoubleBinaryOperator.java
- src/share/classes/java/util/function/DoubleBlock.java
+ src/share/classes/java/util/function/DoubleConsumer.java
! src/share/classes/java/util/function/DoubleFunction.java
+ src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/DoubleSupplier.java
! src/share/classes/java/util/function/DoubleUnaryOperator.java
! src/share/classes/java/util/function/Function.java
! src/share/classes/java/util/function/IntBinaryOperator.java
- src/share/classes/java/util/function/IntBlock.java
+ src/share/classes/java/util/function/IntConsumer.java
! src/share/classes/java/util/function/IntFunction.java
+ src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/IntSupplier.java
! src/share/classes/java/util/function/IntUnaryOperator.java
! src/share/classes/java/util/function/LongBinaryOperator.java
- src/share/classes/java/util/function/LongBlock.java
+ src/share/classes/java/util/function/LongConsumer.java
! src/share/classes/java/util/function/LongFunction.java
+ src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/LongSupplier.java
! src/share/classes/java/util/function/LongUnaryOperator.java
+ src/share/classes/java/util/function/ObjDoubleConsumer.java
+ src/share/classes/java/util/function/ObjIntConsumer.java
+ src/share/classes/java/util/function/ObjLongConsumer.java
! src/share/classes/java/util/function/Predicate.java
+ src/share/classes/java/util/function/ToDoubleBiFunction.java
+ src/share/classes/java/util/function/ToDoubleFunction.java
+ src/share/classes/java/util/function/ToIntBiFunction.java
+ src/share/classes/java/util/function/ToIntFunction.java
+ src/share/classes/java/util/function/ToLongBiFunction.java
+ src/share/classes/java/util/function/ToLongFunction.java
! src/share/classes/java/util/function/UnaryOperator.java
! src/share/classes/java/util/function/package-info.java
! test/java/lang/PrimitiveSumMinMaxTest.java

Re: Define JNIEXPORT as visibility default with GCC?

2013-02-19 Thread Jeremy Manson

Since the proposed change is user-visible (i.e., not just for building the
JDK, but also for building pretty much every JNI blob in existence),
wouldn't you want the correct check anyway?  Does the JDK have rules about
which version of gcc you are allowed to use to build JNI?

Jeremy


On Mon, Feb 18, 2013 at 1:36 AM, Florian Weimer fwei...@redhat.com wrote:

 On 02/17/2013 11:55 PM, David Holmes wrote:

 On 16/02/2013 2:46 AM, Florian Weimer wrote:

 On 02/15/2013 05:41 PM, Jeremy Manson wrote:

 Can we just blacklist 4.1.2 explicitly?


 Folks, per README-build.html, the minimum GCC version is 4.2 on MacOS X
 and 4.3 everywhere else.  Do we really have to bother with 4.1.2 at this
 point?


 There are ports that still use these older gcc versions.


 Oh.  Perhaps this information can be added to README-builds.html?


 --
 Florian Weimer / Red Hat Product Security Team

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries

2013-02-19 Thread Mike Duigou

Thank you for the feedback David. 

On Feb 18 2013, at 21:29 , David Holmes wrote:

 package-info.java
 
 I've flagged this elsewhere but you may not have seen it:
 
 + * Predicatelt;String
 
 If we use lt; then we should also use gt;.

It's not required to use gt; in HTML 4.01 transitional or HTML 5.0. Doclint 
was complaining about this but it has (or soon will be) amended. It could still 
be a style requirement to use gt;

I will push this changeset with  but assume that if the decision is to 
require gt; then doclint will remind us thoroughly and repeatedly to correct 
this before Java 8 is released. 

 Aside: it would be much easier to maintain consistent style if we used a 
 template to define the main outline of each family of interfaces and 
 generated the specializations from that (similar to how we generate the 
 various bytebuffer classes).

Like Chris I have mixed feelings about templating for similar reasons. Our 
current generated sources work very poorly with IDEs. If we can improve the 
user experience with generated sources I would be very much willing to consider 
it.

Thanks again!

Mike

hg: jdk8/tl/jdk: 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c

2013-02-19 Thread sean . mullan

Changeset: 267bca6af07e
Author:jzavgren
Date:  2013-02-19 15:31 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/267bca6af07e

8008107: [parfait] Use after free of pointer in 
jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
Reviewed-by: mullan, chegar

! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c

RFR: 8008481 Dependency analyzer needs exclusion for profile builds with JFR disabled

The new jar dependency analyzer detects unsatisfied dependencies in a 
profile build with JFR disabled:


Analyzing 
/export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/management-agent.jar
Analyzing 
/export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/jce.jar
Analyzing 
/export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/resources.jar
Analyzing 
/export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/jsse.jar
Analyzing 
/export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/rt.jar
Analyzing 
/export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/images/j2re-compact3-image/lib/tzdb.jar
com.sun.management.MissionControl - 
com.oracle.jrockit.jfr.management.FlightRecorderMBean (unknown type)
com.sun.management.MissionControl - 
com.oracle.jrockit.jfr.FlightRecorder (unknown type)

One or more unexpected references encountered
Check 
/export/users/dh198349/jdk8-build/build/b77c/linux-i586-ea/jdk/btclasses/build/tools/deps/refs.allowed 
is up to date


Fix is to add these two entries to ref.allowed

http://cr.openjdk.java.net/~dholmes/8008481/webrev/

--- old/make/tools/src/build/tools/deps/refs.allowed	2013-02-19 
15:36:37.863380282 -0500
+++ new/make/tools/src/build/tools/deps/refs.allowed	2013-02-19 
15:36:36.551306476 -0500

@@ -33,3 +33,8 @@
 #

java.beans.PropertyChangeListener=java.util.logging.LogManager,sun.org.mozilla.javascript.internal.Context,compact1,compact2,compact3

java.beans.PropertyChangeEvent=sun.org.mozilla.javascript.internal.Context,compact3
+
+# JFR traces even in builds with JFR disabled
+com.oracle.jrockit.jfr.FlightRecorder: 
com.sun.management.MissionControl, compact3
+com.oracle.jrockit.jfr.management.FlightRecorderMBean: 
com.sun.management.MissionControl, compact3

+

Thanks,
David

Re: RFR: 8008481 Dependency analyzer needs exclusion for profile builds with JFR disabled


On 19/02/2013 20:37, David Holmes wrote:

:
+
+# JFR traces even in builds with JFR disabled
+com.oracle.jrockit.jfr.FlightRecorder: 
com.sun.management.MissionControl, compact3
+com.oracle.jrockit.jfr.management.FlightRecorderMBean: 
com.sun.management.MissionControl, compact3

+
This looks fine to okay and I know you need to get this resolved 
today.It is of course a workaround to a somewhat messy issue that needs 
separate follow-up.


-Alan

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread


On 19 Feb 2013, at 18:35, Alan Bateman alan.bate...@oracle.com wrote:

 On 19/02/2013 17:48, Martin Buchholz wrote:
 :
 
 Taking a look at this, I don't see any reason why we can't simply do
 (while maintaining serialization compatibility):
 Right, it's not needed and I think we had Chris persuaded on this a few weeks 
 ago. It does change the serialized form but that it's not an issue issue and 
 it doesn't matter that they have the default value when deserialized on an 
 older release.

Agreed, but we do need to have this approved by the CCC. I'll follow up on this.

-Chris

 
 -Alan.

Re: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence()

2013-02-19 Thread Zhong Yu

I think it's really easy for users to write a SubSequence by
themselves if they need to solve the problem; there is no need for
String to do it, and definitely not at the expense of breaching
previous explicit contracts. We should solve this problem externally,
explicitly; not internally with some surprising plumbings.

The patch may not be very helpful anyway. It is unlikely that an
application can simply switch from using sub-String to using
sub-CharSequence, since CharSequence is not nearly as convenient as
String - CharSequence has no contract on hashCode/equals, and no
operations like indexOf() etc. CharSequence is still not widely used,
not even in the standard lib - among java.** classes, besides
subclasses of CharSequence/Appendable, there are only 4 classes with
public methods accepting CharSequence args:  Normalizer, Matcher,
Pattern, CharsetEncoder.

A new top level public class that mimics String is probably going to
be helpful; this class may not be worthy of being included in
java.lang; it could be provided by 3rd parties. The class should

1. be able to wrap any CharSequence and char[] source
2. reference the source without copying, till explicitly asked to
3. though not immutable, remain constant if source remains constant
4. have well defined hashCode/equals
5. have convenience operations like indexOf()
6. include popular methods from various StringUtils
7. have well defined space/time cost on all methods

Let me call it Strand. If anyone got a problem with the change of
String impl, we can refer him to wrap the string in a Strand, and
operate on the strand instead.

Zhong Yu

On Mon, Feb 18, 2013 at 11:27 PM, Mike Duigou mike.dui...@oracle.com wrote:
 Hello all;

 JDK 7u6 included a significant change to java.lang.String. The change was 
 internal to the String implementation and didn't result in any API changes 
 but it does have a significant impact on the performance of some uses cases. 
 (See 
 http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html 
 for an earlier discussion)

 Prior to 7u6 String maintained two fields count and offset which 
 described the location within the character array of the String's characters. 
 In 7u6 the count and offset fields were removed and String instances no 
 longer share their character arrays with other String instances. Each 
 substring(), subSequence() or split() now creates entirely new String 
 instances for it's results. Before 7u6 two or more instances of String could 
 share the same backing character array. A number of String operations; 
 clone(), split(), subString(), subSequence() did not copy the backing 
 character array but created new String instances pointing at their character 
 array with appropriate count and offset values.

 As with most sharing techniques, there are tradeoffs. The count/offset 
 approach works reasonably well for cases where the substrings have a shorter 
 lifetime than the original. Frequently it was found though that the large 
 character arrays leaked through small Strings derived from larger String 
 instances. Examples would be tokens parsed with substring() from HTTP headers 
 being used as keys in Maps. This caused the entire header character array 
 from the original header String to not be garbage collected (or worse the 
 entire set of headers for a request).

 Our benchmarking and application testing prior to changing the String 
 implementation in 7u6 showed that it was a net benefit to not share the 
 character array instances. The benchmarking and performance testing for this 
 change actually began in 2007 and was very extensive. Benchmarking and 
 performance analysis since the release of 7u6 continues to indicate that 
 removal of sharing is the better approach. It is extremely unlikely that we 
 would consider returning to the pre-7u6 implementation (in case you were 
 thinking of suggesting that).

 There are some cases where the new approach can result in significant 
 performance penalties. This is a For Your Consideration review not a 
 pre-push changeset. The review changeset is a weakening of the never share 
 the String character array rule and it means that it would suffer from 
 exactly the same weakness. Few applications currently use subSequence() most 
 currently use subString(). Applications which would benefit from this change 
 would have to switch to using subSequence(). Apps can safely switch to 
 subSequence in anticipation of this change because currently subSequence() is 
 identical to substring(). This means that should this changeset not be 
 integrated app code would suffer no penalty and if this change is eventually 
 integrated then app performance will improve.

 http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/

 From our current testing we found that applications currently using 
 subSequence() failed if the equals(), hashCode() and toString() 
 implementations did not exactly match String. Additionally we had to change 
 String.equals() so

Re: API question for point lambdafication

2013-02-19 Thread Zhong Yu

On Tue, Feb 19, 2013 at 2:45 PM, Ben Evans
benjamin.john.ev...@gmail.com wrote:
 Hi,

 I've got my regex point lambdafication patch going against the current
 state of lambda, but now I have an API question I'd like some feedback
 on.

 (Btw, if this is more appropriate for core-libs just let me know, and
 I'll take my carcass over there  bug those guys instead.)

 I currently have this new method on java.util.regex.Pattern:

 public StreamCharSequence splitAsStream(final CharSequence input);

`input.subSequence()` can be expensive anyway; in String,
StringBuilder and StringBuffer, the method will copy the chars in
range. Therefore you may as well do the copy yourself to make Strings.

Currently String does not have a constructor like

public String(CharSequence source, int offset, int count)

maybe it should be added?

Zhong Yu

 This provides a stream of values from the input CharSequence, split
 around occurrences of this pattern.

 However, as the return type of splitAsStream() is
 StreamCharSequence, then we need to map stream values back to String
 to be most useful, like this:

 ListString out = p.splitAsStream(s)
 .map(cs - cs.toString())
 .collect(Collectors.toList());

 So, my question is this - should I continue to use the above
 signature, or should it be:

 public StreamString splitAsStream(final CharSequence input);

 This avoids the need for the intermediate map(), which seems like a
 bit of a wart to me.

 Pattern has a vanilla split() method, which returns String[] - so for
 those 2 reasons I'm minded towards the second form.

 Anyone else have any thoughts about this?

 Ben

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries

2013-02-19 Thread Remi Forax


On 02/19/2013 07:40 PM, Joe Darcy wrote:

On 02/19/2013 07:14 AM, Chris Hegarty wrote:

On 02/19/2013 03:08 PM, Alan Bateman wrote:

On 19/02/2013 14:39, Chris Hegarty wrote:

:

Oh, please god no! I find the way the buffer classes are generated a
real pain. Yes, it is good for maintaining consistency across similar
versions, but I don't see that as a good justification to introduce
this complexity. I was secretly hoping that nio Buffer generation
would go away in jdk8.

I assume the pain with the generated buffer classes is in the IDE so
you need to remember to include the gensrc tree in the project.

Right, but this assumes you to have a build. They also don't play well
with tools that index the source, like opengrok.




As an aside, a code generation technique that should play better with 
tooling would to be use an annotation processor to generate the code 
from within the context of the compiler/IDE. As a general-purpose 
meta-programming system, annotation processing doesn't have to be tied 
to annotations.


hence the name :)



-Joe


Rémi

Re: RFR: 8008481 Dependency analyzer needs exclusion for profile builds with JFR disabled


Thanks Alan.

cc'ing build-dev as this is technically build related and going into 
jdk8/build.


David

On 20/02/2013 7:04 AM, Alan Bateman wrote:

On 19/02/2013 20:37, David Holmes wrote:

:
+
+# JFR traces even in builds with JFR disabled
+com.oracle.jrockit.jfr.FlightRecorder:
com.sun.management.MissionControl, compact3
+com.oracle.jrockit.jfr.management.FlightRecorderMBean:
com.sun.management.MissionControl, compact3
+

This looks fine to okay and I know you need to get this resolved
today.It is of course a workaround to a somewhat messy issue that needs
separate follow-up.

-Alan

Re: FYC : JDK-7197183 : Improve copying behaviour of String.subSequence()

2013-02-19 Thread Peter Levart



On 02/19/2013 10:35 PM, Zhong Yu wrote:

I think it's really easy for users to write a SubSequence by
themselves if they need to solve the problem; there is no need for
String to do it, and definitely not at the expense of breaching
previous explicit contracts. We should solve this problem externally,
explicitly; not internally with some surprising plumbings.

The patch may not be very helpful anyway. It is unlikely that an
application can simply switch from using sub-String to using
sub-CharSequence, since CharSequence is not nearly as convenient as
String - CharSequence has no contract on hashCode/equals, and no
operations like indexOf() etc. CharSequence is still not widely used,
not even in the standard lib - among java.** classes, besides
subclasses of CharSequence/Appendable, there are only 4 classes with
public methods accepting CharSequence args:  Normalizer, Matcher,
Pattern, CharsetEncoder.

A new top level public class that mimics String is probably going to
be helpful; this class may not be worthy of being included in
java.lang; it could be provided by 3rd parties. The class should

1. be able to wrap any CharSequence and char[] source
2. reference the source without copying, till explicitly asked to
3. though not immutable, remain constant if source remains constant
4. have well defined hashCode/equals
5. have convenience operations like indexOf()
6. include popular methods from various StringUtils
7. have well defined space/time cost on all methods

Let me call it Strand.


A Rope?

http://en.wikipedia.org/wiki/Rope_%28data_structure%29

Peter


If anyone got a problem with the change of
String impl, we can refer him to wrap the string in a Strand, and
operate on the strand instead.

Zhong Yu

On Mon, Feb 18, 2013 at 11:27 PM, Mike Duigou mike.dui...@oracle.com wrote:

Hello all;

JDK 7u6 included a significant change to java.lang.String. The change was 
internal to the String implementation and didn't result in any API changes but 
it does have a significant impact on the performance of some uses cases. (See 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010509.html for 
an earlier discussion)

Prior to 7u6 String maintained two fields count and offset which described the location within 
the character array of the String's characters. In 7u6 the count and offset fields were removed and String instances no 
longer share their character arrays with other String instances. Each substring(), subSequence() or split() now creates 
entirely new String instances for it's results. Before 7u6 two or more instances of String could share the same backing 
character array. A number of String operations; clone(), split(), subString(), subSequence() did not copy the backing 
character array but created new String instances pointing at their character array with appropriate count 
and offset values.

As with most sharing techniques, there are tradeoffs. The count/offset approach works 
reasonably well for cases where the substrings have a shorter lifetime than the original. 
Frequently it was found though that the large character arrays leaked through small 
Strings derived from larger String instances. Examples would be tokens parsed with substring() from 
HTTP headers being used as keys in Maps. This caused the entire header character array from the 
original header String to not be garbage collected (or worse the entire set of headers for a 
request).

Our benchmarking and application testing prior to changing the String 
implementation in 7u6 showed that it was a net benefit to not share the 
character array instances. The benchmarking and performance testing for this 
change actually began in 2007 and was very extensive. Benchmarking and 
performance analysis since the release of 7u6 continues to indicate that 
removal of sharing is the better approach. It is extremely unlikely that we 
would consider returning to the pre-7u6 implementation (in case you were 
thinking of suggesting that).

There are some cases where the new approach can result in significant performance penalties. This 
is a For Your Consideration review not a pre-push changeset. The review changeset is a 
weakening of the never share the String character array rule and it means that it would 
suffer from exactly the same weakness. Few applications currently use subSequence() most currently 
use subString(). Applications which would benefit from this change would have to switch to using 
subSequence(). Apps can safely switch to subSequence in anticipation of this change because 
currently subSequence() is identical to substring(). This means that should this changeset not be 
integrated app code would suffer no penalty and if this change is eventually integrated then app 
performance will improve.

http://cr.openjdk.java.net/~mduigou/JDK-7197183/0/

 From our current testing we found that applications currently using subSequence() failed 
if the equals(), hashCode() and toString() implementations did not exactly

Re: Define JNIEXPORT as visibility default with GCC?

2013-02-19 Thread Daniel D. Daugherty


I couldn't find a 'jdk' repo relevant bug for this issue so I filed:

8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's
 jni_md.h needs similar change
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008509
https://jbs.oracle.com/bugs/browse/JDK-8008509

Coleen did the original work on 6588413 so I added her to the interest
list for the new bug. The need for an update to the jdk repo's jni_md.h
file was raised during the code review for 6588413, but that detail appears
to have been dropped.

Dan



On 2/19/13 1:20 PM, Jeremy Manson wrote:
Since the proposed change is user-visible (i.e., not just for building 
the JDK, but also for building pretty much every JNI blob in 
existence), wouldn't you want the correct check anyway?  Does the JDK 
have rules about which version of gcc you are allowed to use to build 
JNI?


Jeremy


On Mon, Feb 18, 2013 at 1:36 AM, Florian Weimer fwei...@redhat.com 
mailto:fwei...@redhat.com wrote:


On 02/17/2013 11:55 PM, David Holmes wrote:

On 16/02/2013 2:46 AM, Florian Weimer wrote:

On 02/15/2013 05:41 PM, Jeremy Manson wrote:

Can we just blacklist 4.1.2 explicitly?


Folks, per README-build.html, the minimum GCC version is
4.2 on MacOS X
and 4.3 everywhere else.  Do we really have to bother with
4.1.2 at this
point?


There are ports that still use these older gcc versions.


Oh.  Perhaps this information can be added to README-builds.html?


-- 
Florian Weimer / Red Hat Product Security Team

hg: jdk8/tl/jdk: 8008262: pack200 should support MethodParameters - part 2

2013-02-19 Thread kumar . x . srinivasan

Changeset: ec1a79c3a99c
Author:ksrini
Date:  2013-02-19 16:49 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec1a79c3a99c

8008262: pack200 should support MethodParameters - part 2
Reviewed-by: jrose

! src/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java
! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java
! src/share/native/com/sun/java/util/jar/pack/bands.cpp
! src/share/native/com/sun/java/util/jar/pack/bands.h
! src/share/native/com/sun/java/util/jar/pack/unpack.cpp
! test/tools/pack200/AttributeTests.java
! test/tools/pack200/Utils.java

hg: jdk8/tl/langtools: 8006948: Update javac for MethodParameters format change

2013-02-19 Thread kumar . x . srinivasan

Changeset: 9345394ac8fe
Author:ksrini
Date:  2013-02-19 17:19 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9345394ac8fe

8006948: Update javac for MethodParameters format change
Reviewed-by: ksrini, forax
Contributed-by: eric.mccor...@oracle.com

! src/share/classes/com/sun/tools/classfile/ClassWriter.java
! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java

Re: Truncate a LinkedList

2013-02-19 Thread Weijun Wang

In my case, I am planning to do an expunge when there are more old
entries than new entries (or plus a constant), so the head and tail
are likely of the same size.

I'll think about creating my own LinkedList. It will be nice to just
break at one link.

Thanks
Max

On 2/19/13 8:36 PM, Peter Levart wrote:

On 02/19/2013 01:24 PM, Peter Levart wrote:

On 02/19/2013 11:38 AM, Daniel Fuchs wrote:

On 2/19/13 11:27 AM, Weijun Wang wrote:

Hi All

I'm using LinkedList to maintain a history and the elements are ordered
by their timestamps. Every now and then I would expunge the list,
that
is to say, iterating through the list and when an element is old enough
all elements after (and including) it will be removed. Currently I'm
removing them one by one.

Is there a way to truncate the list using a single method?

Thanks
Max

Hi Max,

You could try to use AbstractList.subList(...)

http://docs.oracle.com/javase/6/docs/api/java/util/AbstractList.html#subList%28int,%20int%29

Quoting from the doc:

For example, the following idiom removes a range of elements from a
list:

list.subList(from, to).clear();

Hi Daniel,

Hi Weijun,

Regards, Peter

-- daniel

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries


On 20/02/2013 12:39 AM, Chris Hegarty wrote:


On 02/19/2013 05:29 AM, David Holmes wrote:

...
Aside: it would be much easier to maintain consistent style if we used a
template to define the main outline of each family of interfaces and
generated the specializations from that (similar to how we generate the
various bytebuffer classes).


Oh, please god no! I find the way the buffer classes are generated a
real pain. Yes, it is good for maintaining consistency across similar
versions, but I don't see that as a good justification to introduce this
complexity. I was secretly hoping that nio Buffer generation would go
away in jdk8.


:) I only meant as a tool during development of the classes, not to 
actually generate them as part of the build.


Sorry for alarming you like that. :)

David


-Chris.

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries


On 20/02/2013 6:22 AM, Mike Duigou wrote:

Thank you for the feedback David.


So what got updated, if anything, before the push?

The biggest gripe I have with reviewing all this stuff is being able to 
keep track of what comments have been made, what comments have been 
acted upon and what is still outstanding. I'd love to see a nightly doc 
build with change bars; or a doc build with annotations highlighting 
known issues. Don't know if we have any tools capable of that though.



On Feb 18 2013, at 21:29 , David Holmes wrote:


package-info.java

I've flagged this elsewhere but you may not have seen it:

+ * Predicatelt;String

If we use lt; then we should also use gt;.


It's not required to use gt; in HTML 4.01 transitional or HTML 5.0. Doclint was 
complaining about this but it has (or soon will be) amended. It could still be a style 
requirement to use gt;


Nothing like being inconsistent :( (that's directed at HTML standard)



I will push this changeset with  but assume that if the decision is to require 
gt; then doclint will remind us thoroughly and repeatedly to correct this before Java 8 
is released.


Aside: it would be much easier to maintain consistent style if we used a 
template to define the main outline of each family of interfaces and 
generated the specializations from that (similar to how we generate the various 
bytebuffer classes).


Like Chris I have mixed feelings about templating for similar reasons. Our 
current generated sources work very poorly with IDEs. If we can improve the 
user experience with generated sources I would be very much willing to consider 
it.


As I replied to Chris I didn't mean that as a permanent feature or even 
something committed at this stage - simply a tool to help with these 
repetitive definitions of class/method docs to ensure that they are 
consistent in the way they name and express things. Maybe there isn't 
enough commonality to make this worthwhile (you may still have multiple 
templates to keep consistent), but I know from past experience that this 
level of consistency is one of the hardest things to get right - it is 
tedious and error prone.


Cheers,
David


Thanks again!

Mike

Re: RFR (M) : JDK-8004561 : Addition Functional Interfaces for Lambda Libraries

2013-02-19 Thread Mike Duigou


On Feb 19 2013, at 19:37 , David Holmes wrote:

 On 20/02/2013 6:22 AM, Mike Duigou wrote:
 Thank you for the feedback David.
 
 So what got updated, if anything, before the push?

Everything. With the exception of the gt; which I mentioned in my response I 
accepted all of your feedback suggestions as well as Chris's. It was good 
feedback!

 The biggest gripe I have with reviewing all this stuff is being able to keep 
 track of what comments have been made, what comments have been acted upon and 
 what is still outstanding.

Yes, from experience it's been too easy for review feedback and comments to get 
lost. I do try to either address as many of the comments as possible and 
proceed to produce an updated webrev or if nothing seems blocking, push the 
changeset.

 I'd love to see a nightly doc build with change bars; or a doc build with 
 annotations highlighting known issues. Don't know if we have any tools 
 capable of that though.

We don't unfortunately. And ultimately you'd want to be able to diff any two 
arbitrary versions from the repository. Tools like specdiff do exist for this 
but aren't hooked up in such a way to make generating the necessary reports 
simple. It's an infrastructure and tooling shortcoming. :-(

 On Feb 18 2013, at 21:29 , David Holmes wrote:
 
 package-info.java
 
 I've flagged this elsewhere but you may not have seen it:
 
 + * Predicatelt;String
 
 If we use lt; then we should also use gt;.
 
 It's not required to use gt; in HTML 4.01 transitional or HTML 5.0. Doclint 
 was complaining about this but it has (or soon will be) amended. It could 
 still be a style requirement to use gt;
 
 Nothing like being inconsistent :( (that's directed at HTML standard)
 
 
 I will push this changeset with  but assume that if the decision is to 
 require gt; then doclint will remind us thoroughly and repeatedly to 
 correct this before Java 8 is released.
 
 Aside: it would be much easier to maintain consistent style if we used a 
 template to define the main outline of each family of interfaces and 
 generated the specializations from that (similar to how we generate the 
 various bytebuffer classes).
 
 Like Chris I have mixed feelings about templating for similar reasons. Our 
 current generated sources work very poorly with IDEs. If we can improve the 
 user experience with generated sources I would be very much willing to 
 consider it.
 
 As I replied to Chris I didn't mean that as a permanent feature or even 
 something committed at this stage - simply a tool to help with these 
 repetitive definitions of class/method docs to ensure that they are 
 consistent in the way they name and express things. Maybe there isn't enough 
 commonality to make this worthwhile (you may still have multiple templates to 
 keep consistent), but I know from past experience that this level of 
 consistency is one of the hardest things to get right - it is tedious and 
 error prone.

I have been using a merge tool, meld, to try to make fewer transcription errors 
between the primitive specializations. I agree that some form of template would 
be the best solution in the long run.

We could add an explicit gensrc target to our make process which caused all of 
the generated/templated sources to be build for consumption by IDEs (and later 
build phases). This is the workflow used by maven projects and it seems to be 
OK. When you clone or update a maven project you re-run the equivalent of 
configure+gensrc to get the project ready for use by IDE tools.

 
 Cheers,
 David
 
 Thanks again!
 
 Mike

hg: jdk8/tl/corba: 2 new changesets

Changeset: 27d6368ae8ba
Author:katleman
Date:  2013-02-14 11:43 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/27d6368ae8ba

Added tag jdk8-b77 for changeset 35684a40c584

! .hgtags

Changeset: c528d8ce83f1
Author:lana
Date:  2013-02-19 20:48 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/corba/rev/c528d8ce83f1

Merge

hg: jdk8/tl/jaxp: Added tag jdk8-b77 for changeset 573e789c187a

Changeset: 00958c5a7070
Author:katleman
Date:  2013-02-14 11:43 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/00958c5a7070

Added tag jdk8-b77 for changeset 573e789c187a

! .hgtags

hg: jdk8/tl/jaxws: Added tag jdk8-b77 for changeset 64dfba1bad16

Changeset: 391de4c992d1
Author:katleman
Date:  2013-02-14 11:43 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/391de4c992d1

Added tag jdk8-b77 for changeset 64dfba1bad16

! .hgtags

hg: jdk8/tl/langtools: 3 new changesets

Changeset: bc24411bcc37
Author:katleman
Date:  2013-02-14 11:44 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc24411bcc37

Added tag jdk8-b77 for changeset 89c664151689

! .hgtags

Changeset: a3aa32fe4536
Author:lana
Date:  2013-02-14 22:11 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a3aa32fe4536

Merge


Changeset: 4cf6e84f844f
Author:lana
Date:  2013-02-19 20:53 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4cf6e84f844f

Merge

hg: jdk8/tl: 3 new changesets

Changeset: 45d6d221
Author:katleman
Date:  2013-02-14 11:43 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/45d6d221

Added tag jdk8-b77 for changeset 3933eebc659d

! .hgtags

Changeset: bbb7548d45c7
Author:lana
Date:  2013-02-14 22:11 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/bbb7548d45c7

Merge


Changeset: eca3bce3d151
Author:lana
Date:  2013-02-19 20:48 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/rev/eca3bce3d151

Merge

hg: jdk8/tl/hotspot: 36 new changesets