Re: Possible addition of a default 'getOne' method on Iterable?

[Dave Brosius]

Basically, but it's

annoying and ugly to write

most likely sub-optimal

has problems with things like synchronized collections


On 01/31/2018 12:28 AM, Zheka Kozlov wrote:

Isn't iterable.getOne() the same as iterable.iterator().next()?

2018-01-31 12:15 GMT+07:00 Dave Brosius <dbros...@mebigfatguy.com 
<mailto:dbros...@mebigfatguy.com>>:


Greetings,


sorry if this has been asked before, but has there been any
consideration for adding a

default T getOne() {

    Iterator it = iterator();
    if (!it.hasNext()) {
    throw new NoSuchElementException();
    }

    return it.next();
}


on the Iterable interface?


It is often the case you have a collection of some sort (un
indexed, in this case), where you know there is only one value in
the collection, or you know for some attribute of all the objects
in the Iterable, all objects can be thought of as the same, and so
you just want to get any of the elements.

Having to craft this iterator code is annoying, and it would be
much nicer to be able to do

String s = mySet.getOne();

In addition to this, it is likely that most collections could
implement getOne() more optimally than using the standard iterator
approach.

Of course i am not stuck on the choice of the name 'getOne'
anything would do. examplar() ?  As we know, naming is always the
hardest part.

thoughts?
dave

Possible addition of a default 'getOne' method on Iterable?

[Dave Brosius]

Greetings,


sorry if this has been asked before, but has there been any 
consideration for adding a


default T getOne() {

    Iterator it = iterator();
    if (!it.hasNext()) {
    throw new NoSuchElementException();
    }

    return it.next();
}


on the Iterable interface?


It is often the case you have a collection of some sort (un indexed, in 
this case), where you know there is only one value in the collection, or 
you know for some attribute of all the objects in the Iterable, all 
objects can be thought of as the same, and so you just want to get any 
of the elements.


Having to craft this iterator code is annoying, and it would be much 
nicer to be able to do


String s = mySet.getOne();

In addition to this, it is likely that most collections could implement 
getOne() more optimally than using the standard iterator approach.


Of course i am not stuck on the choice of the name 'getOne' anything 
would do. examplar() ?  As we know, naming is always the hardest part.


thoughts?
dave

Re: java.util.Pair

[Dave Brosius]

I would avoid Pair and Entry like the plague. They are devoid of meaning 
and are just there to save your fingers. If that is your main impetus, 
i'd just turn to using lombok and have true bean classes, that are 
finger-cost free.



On 07/13/2017 05:41 PM, fo...@univ-mlv.fr wrote:

De: "John Rose" 
À: "Rémi Forax" 
Cc: "joe darcy" , "core-libs-dev"

Envoyé: Jeudi 13 Juillet 2017 23:05:14
Objet: Re: java.util.Pair
On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
fo...@univ-mlv.fr ] > wrote:

Tuples are like an array of value types parameterized by a constant integer

The homogeneous case is pretty simple; most of what you need is
to allow a generic type to be parameterized by an integer. C++ templates
have had that for a long time.
What's harder is to have a two-step process for type instantiation:
First, tell me the arity N, and second, for each position under that arity,
tell me the type T[i], i
or use a recursive definition like in Ceylon
https://modules.ceylon-lang.org/repo/1/ceylon/language/1.0.0/module-doc/Tuple.type.html
and the fact that value types are flatten to specify the rest, i.e a Tuple 
contains a T first and a Tuple rest.


C++ templates can express heterogeneous tuples:
[ http://en.cppreference.com/w/cpp/utility/tuple |
http://en.cppreference.com/w/cpp/utility/tuple ]
Typically there is a small limit to C++ tuple size, because the underlying
template implementation has its size set to the arity limit.
— John

Rémi

Soften interface for javax.management.ObjectName.getInstance and friends

[Dave Brosius]

Greetings. the method

public static ObjectName getInstance(String domain,
Hashtable table)
throws MalformedObjectNameException {
return new ObjectName(domain, table);
}

in javax.management.ObjectName allows for a provided Hashtable to 
specify properties for the objectname.


The semantics of an ObjectName don't consider the order of these 
properties, however certain tools like jconsole (when used as a name for 
a jmx property) does consider the order.


If you wish to create a folder structure to report metrics in jmx, you 
need to use this properties map to specify the folder names. JConsole, 
then, uses order of iteration to determine the order of the folder 
hierarchy.


Suppose you want a folder hierarchy similar to a package name, you may 
specify properties like


table.put("a0", "com");
table.put("a1", "acme");
table.put("name", "MyMetric");

in hopes of producing a metric in JConsole in the folder structure, 
com/acme/MyMetric.


The problem is of course, that the argument is a Hashtable, not a Map, 
and so the items are not ordered at all, yet JConsole uses iteration 
order to build the path, so you may get


acme/ao/MyMetric or MyMetric/acme/ao or .

This means if you really want to have ordered packages, you have to 
derive from Hashtable, and override the entrySet() method, including 
that set's iterator() to return the values in the order you wish to have 
them shown.


That is really janky.

I'm proposing that the interface for getInstance be softened to

public static ObjectName getInstance(String domain,
 Map table)

as well as

public ObjectName(String domain, Map table)

thoughts?

Re: Make iterators cloneable?

[Dave Brosius]

That would give you unwanted duplicates

Fi-Fum and Fum-Fi for instance


On 09/11/2016 08:58 PM, Tagir Valeev wrote:
Actually given the fact that we're iterating the Set (so the elements 
are unique) and using the assumption that iteration of the same set is 
stable, you can avoid numbering like this:


for(String e1 : set) {
  for(String e2 : set) {
if(e1 == e2) break;
System.out.println(e1+" <-> "+e2);
  }
}

Again, such algorithm is fragile to concurrent changes.

With best regards,
Tagir Valeev.

On Mon, Sep 12, 2016 at 7:51 AM, Tagir Valeev > wrote:


Hello, Peter!

I thought about numbering, but original Dave's code involved
concurrent set, so I presume that it's expected to be modified
from other threads. In this case my algorithm would output some
legal pairs (probably reflecting changes or not or reflecting only
partially) while your algorithm can output garbage (pair with
equal e1, e2 or two pairs like e1 <-> e2, e2 <-> e1 or can even
die with NoSuchElementException). Not sure what is better in
author's case.

Tagir.

On Sun, Sep 11, 2016 at 7:20 PM, Peter Levart
> wrote:

Hi,

Even if the elements are not comparable, you could rely on the
fact that Collection(s) usually create iterators with stable
iteration order, so you could do the following:


Set set = Set.of(1, 2, 3, 4);

Iterator it1 = set.iterator();
for (int n1 = 0; it1.hasNext(); n1++) {
Integer e1 = it1.next();
Iterator it2 = set.iterator();
for (int n2 = 0; n2 < n1; n2++) {
Integer e2 = it2.next();
System.out.println(e1 + " <-> " + e2);
}
}


Regards, Peter


On 09/11/2016 02:02 PM, Tagir F. Valeev wrote:

Hello!

As your keys are comparable, you can create normal iterators and
filter the results like this:

for(String v1 : s) {
   for(String v2 : s) {
 if(v1.compareTo(v2) < 0) {
   System.out.println(v1 + " <-->" + v2);
 }
   }
}

Or using Stream API:

s.stream().flatMap(v1 -> s.stream()
 .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2))
  .forEach(System.out::println);

With best regards,
Tagir Valeev.


DB> It would be nice to be able to associate each element in a 
collection
DB> with another element in the collection, which is something very 
easily
DB> done with index based collections, but with sets, etc this isn't so
DB> easy... unless i'm having a brainfart.

DB> So i'd like to do this, but Iterator doesn't implement Cloneable... 
Any
DB> reason not to? or is there another way that's missing me?

DB> public class ItClone {

DB>  public static void main(String[] args) {
DB>  Set s = Collections.newSetFromMap(new
DB> ConcurrentHashMap());

DB>  s.add("Fee");
DB>  s.add("Fi");
DB>  s.add("Fo");
DB>  s.add("Fum");

DB>  Iterator it1 = s.iterator();
DB>  while (it1.hasNext()) {
DB>  String v1 = it1.next();

DB>  Iterator it2 = (Iterator) 
it1.*clone*();
DB>  while (it2.hasNext()) {
DB>  String v2 = it2.next();

DB>  System.out.println(v1 + " <-->" + v2);
DB>  }
DB>  }
DB>  }
DB> }

Re: Make iterators cloneable?

[Dave Brosius]

Sure, but both of those algorithms are n^2, which is a bit painful, 
especially given all the pointer chasing that occurs with iterators.



On 09/11/2016 08:20 AM, Peter Levart wrote:

Hi,

Even if the elements are not comparable, you could rely on the fact 
that Collection(s) usually create iterators with stable iteration 
order, so you could do the following:



Set set = Set.of(1, 2, 3, 4);

Iterator it1 = set.iterator();
for (int n1 = 0; it1.hasNext(); n1++) {
Integer e1 = it1.next();
Iterator it2 = set.iterator();
for (int n2 = 0; n2 < n1; n2++) {
Integer e2 = it2.next();
System.out.println(e1 + " <-> " + e2);
}
}


Regards, Peter

On 09/11/2016 02:02 PM, Tagir F. Valeev wrote:

Hello!

As your keys are comparable, you can create normal iterators and
filter the results like this:

for(String v1 : s) {
   for(String v2 : s) {
 if(v1.compareTo(v2) < 0) {
   System.out.println(v1 + " <-->" + v2);
 }
   }
}

Or using Stream API:

s.stream().flatMap(v1 -> s.stream()
 .filter(v2 -> v1.compareTo(v2) < 0).map(v2 -> v1 + " <-->" + v2))
  .forEach(System.out::println);

With best regards,
Tagir Valeev.


DB> It would be nice to be able to associate each element in a collection
DB> with another element in the collection, which is something very easily
DB> done with index based collections, but with sets, etc this isn't so
DB> easy... unless i'm having a brainfart.

DB> So i'd like to do this, but Iterator doesn't implement Cloneable... Any
DB> reason not to? or is there another way that's missing me?

DB> public class ItClone {

DB>  public static void main(String[] args) {
DB>  Set s = Collections.newSetFromMap(new
DB> ConcurrentHashMap());

DB>  s.add("Fee");
DB>  s.add("Fi");
DB>  s.add("Fo");
DB>  s.add("Fum");

DB>  Iterator it1 = s.iterator();
DB>  while (it1.hasNext()) {
DB>  String v1 = it1.next();

DB>  Iterator it2 = (Iterator) it1.*clone*();
DB>  while (it2.hasNext()) {
DB>  String v2 = it2.next();

DB>  System.out.println(v1 + " <-->" + v2);
DB>  }
DB>  }
DB>  }
DB> }

Re: Make iterators cloneable?

[Dave Brosius]

Hi,


The failfast argument is is irrelevant. It only matters if you use 
it.remove() which is no different than any other failfast situation.


Obviously the 3rd argument is bogus too, as you say.

The second argument, ok, is not arguable, as it's just a persons 
opinion. The bug report is in the genre of subList implementation which 
is different than this use, but ok. The problem is that there are no 
reasonable concurrent indexable collections, and the thought of copying 
large collections into a List everytime you want to do this is crazy.



Unfortunately you can't even have one-off fixes for specific collections 
by having an iterator with a 'copy constructor' for instance, as in the 
case of collection iterators you _really_ have no business knowing what 
the real class is.



On 09/11/2016 05:40 AM, Remi Forax wrote:


Hi,
digging a little bit in the bug database, there is a bug from 1999
   https://bugs.openjdk.java.net/browse/JDK-4244952

answers seems to be
- having different iterators on the same collection is error prone because 
iterators are failfast,
   the proposed workaround to use an array or a List with several indexes
- it's too C++ish, C++ defines clone and equals, Java tries to define a simpler 
iteration protocol
   (from now, given that this question is raised only once in a while, it's 
doesn't seem to be a bad idea)
- iterators are interfaces, so having several iterators means several virtual 
dispatch calls
   (this one is not true anymore because any JITs routinely devirtualize this 
kind of call).

cheers,
Rémi

- Mail original -

De: "Dave Brosius" <dbros...@mebigfatguy.com>
À: "Louis Wasserman" <lowas...@google.com>, "Jonathan Bluett-Duncan" 
<jbluettdun...@gmail.com>
Cc: core-libs-dev@openjdk.java.net
Envoyé: Dimanche 11 Septembre 2016 02:23:41
Objet: Re: Make iterators cloneable?

Iterators reading from a BufferedReader

yes that's true. altho given the contract of Cloneable, adding the clone
method on Iterator would be safe, as it would only be available if the
real implementing class 'extends Cloneable'... it's actually kind of
funny that Object methods aren't available on interface references, anyway.


But i get the "age of Iterator" answer.. Shame there isn't an answer, tho.

thanks, dave

On 09/10/2016 07:44 PM, Louis Wasserman wrote:

Some iterators might be.  Many may not be. Certainly Iterator as an
interface has been out there for long enough there are Iterator
implementations out there that aren't cloneable -- say, Iterators
reading from a BufferedReader, where there really won't be any way to
do what you're hoping for; BufferedReaders certainly aren't cloneable.

On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius <dbros...@mebigfatguy.com
<mailto:dbros...@mebigfatguy.com>> wrote:

 Yes Louis is correct.

 I want the pair wise associations or all elements of a set.

 Fee-Fi

 Fee-Fo

 Fee-Fum

 Fi-Fo

 Fi-Fum

 Fo-Fum


 the independent iterators produce Fee-Fee (etc) as well as the
 duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want.


 This is obviously simplistic with index based collections, but not
 with sets/maps

 I don't see why an Iterator isn't by nature easily cloneable.



 On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote:

 Ah okay Louis, if that's the case then that certainly makes
 sense, and I'd agree that there's no good way of doing so, as one
 would need to copy the set into a list.

 Dave, did Louis hit the mark? If not, would you kindly go into
 further detail as to exactly what it is you're trying to do?

 Best,
 Jonathan

 On 10 September 2016 at 23:36, Jonathan Bluett-Duncan
 <jbluettdun...@gmail.com <mailto:jbluettdun...@gmail.com>> wrote:

 Hi Dave,

 Rather than using Iterator.clone(), how about you just call
 collection.iterator() 2 times to return 2 unique, non-same
 iterators; something like the following:

 import java.util.Collections;
 import java.util.Iterator;
 import java.util.Set;
 import java.util.concurrent.ConcurrentHashMap;

 public class Example {public static void main(String[] args) { 
Set s =
 Collections.newSetFromMap(new ConcurrentHashMap<String,
 Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo");
 s.add("Fum"); Iterator it1 = s.iterator();  for (String v1 
=null;
 it1.hasNext(); v1 =it1.next()) {
Iterator it2 = s.iterator();// a completely separate 
iterator to it1 for
(String v2 =null; it2.hasNext(); v2 = it2.next()) 
{System.out.println(v1 + "
<-->" + v2); } } } }

 Or, even better, if you're using Java 5+, you can skip using
 Iterators altogether and use for-loops directly:

 imp

Re: Make iterators cloneable?

[Dave Brosius]

>> Iterators reading from a BufferedReader

yes that's true. altho given the contract of Cloneable, adding the clone 
method on Iterator would be safe, as it would only be available if the 
real implementing class 'extends Cloneable'... it's actually kind of 
funny that Object methods aren't available on interface references, anyway.



But i get the "age of Iterator" answer.. Shame there isn't an answer, tho.

thanks, dave

On 09/10/2016 07:44 PM, Louis Wasserman wrote:
Some iterators might be.  Many may not be. Certainly Iterator as an 
interface has been out there for long enough there are Iterator 
implementations out there that aren't cloneable -- say, Iterators 
reading from a BufferedReader, where there really won't be any way to 
do what you're hoping for; BufferedReaders certainly aren't cloneable.


On Sat, Sep 10, 2016 at 4:33 PM Dave Brosius <dbros...@mebigfatguy.com 
<mailto:dbros...@mebigfatguy.com>> wrote:


Yes Louis is correct.

I want the pair wise associations or all elements of a set.

Fee-Fi

Fee-Fo

Fee-Fum

Fi-Fo

Fi-Fum

Fo-Fum


the independent iterators produce Fee-Fee (etc) as well as the
duplicate Fee-Fi and Fi-Fee (etc), both of which i don't want.


This is obviously simplistic with index based collections, but not
with sets/maps

I don't see why an Iterator isn't by nature easily cloneable.



On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote:

Ah okay Louis, if that's the case then that certainly makes
sense, and I'd agree that there's no good way of doing so, as one
would need to copy the set into a list.

Dave, did Louis hit the mark? If not, would you kindly go into
further detail as to exactly what it is you're trying to do?

Best,
Jonathan

On 10 September 2016 at 23:36, Jonathan Bluett-Duncan
<jbluettdun...@gmail.com <mailto:jbluettdun...@gmail.com>> wrote:

Hi Dave,

Rather than using Iterator.clone(), how about you just call
collection.iterator() 2 times to return 2 unique, non-same
iterators; something like the following:

import java.util.Collections;
import java.util.Iterator;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;

public class Example {public static void main(String[] args) { 
Set s =
Collections.newSetFromMap(new ConcurrentHashMap<String,
Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo");
s.add("Fum"); Iterator it1 = s.iterator();  for (String v1 
=null; it1.hasNext(); v1 =it1.next()) {
   Iterator it2 = s.iterator();// a completely separate iterator to it1 for 
(String v2 =null; it2.hasNext(); v2 = it2.next()) {System.out.println(v1 + " <-->" + 
v2); } } } }

Or, even better, if you're using Java 5+, you can skip using
Iterators altogether and use for-loops directly:

import java.util.Collections;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;

public class Example {public static void main(String[] args) { 
Set s =
Collections.newSetFromMap(new ConcurrentHashMap<String,
Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo");
s.add("Fum");  for (String v1 : s) {
   for (String v2 : s) {System.out.println(v1 + "<-->" + v2); } } } 
}

Kind regards,
Jonathan
On 10 September 2016 at 23:13, Dave Brosius
<dbros...@mebigfatguy.com <mailto:dbros...@mebigfatguy.com>>
wrote:

It would be nice to be able to associate each element in
a collection with another element in the collection,
which is something very easily done with index based
collections, but with sets, etc this isn't so easy...
unless i'm having a brainfart. So i'd like to do this,
but Iterator doesn't implement Cloneable... Any reason
not to? or is there another way that's missing me? public
class ItClone { public static void main(String[]
args) { Set s =
Collections.newSetFromMap(new ConcurrentHashMap<String,
Boolean>()); s.add("Fee"); s.add("Fi");  
  s.add("Fo"); s.add("Fum");
Iterator it1 = s.iterator(); while
(it1.hasNext()) { String v1 = it1.next();
Iterator it2 = (Iterator)
it1.*clone*(); while (it2.hasNext()) {  
  String v2 = it2.next();
System.out.println(v1 + " <-->" + v2); }
} } } 

Re: Make iterators cloneable?

[Dave Brosius]

Yes Louis is correct.

I want the pair wise associations or all elements of a set.

Fee-Fi

Fee-Fo

Fee-Fum

Fi-Fo

Fi-Fum

Fo-Fum


the independent iterators produce Fee-Fee (etc) as well as the duplicate 
Fee-Fi and Fi-Fee (etc), both of which i don't want.



This is obviously simplistic with index based collections, but not with 
sets/maps


I don't see why an Iterator isn't by nature easily cloneable.



On 09/10/2016 06:45 PM, Jonathan Bluett-Duncan wrote:
Ah okay Louis, if that's the case then that certainly makes sense, and 
I'd agree that there's no good way of doing so, as one would need to 
copy the set into a list.


Dave, did Louis hit the mark? If not, would you kindly go into further 
detail as to exactly what it is you're trying to do?


Best,
Jonathan

On 10 September 2016 at 23:36, Jonathan Bluett-Duncan 
<jbluettdun...@gmail.com <mailto:jbluettdun...@gmail.com>> wrote:


Hi Dave,

Rather than using Iterator.clone(), how about you just call
collection.iterator() 2 times to return 2 unique, non-same
iterators; something like the following:

import java.util.Collections;
import java.util.Iterator;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;

public class Example {public static void main(String[] args) { Set 
s =
Collections.newSetFromMap(new ConcurrentHashMap<String,
Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); s.add("Fum");
Iterator it1 = s.iterator();  for (String v1 =null; 
it1.hasNext(); v1 =it1.next()) {
   Iterator it2 = s.iterator();// a completely separate iterator to it1 for 
(String v2 =null; it2.hasNext(); v2 = it2.next()) {System.out.println(v1 + " <-->" + 
v2); } } } }

Or, even better, if you're using Java 5+, you can skip using
Iterators altogether and use for-loops directly:

import java.util.Collections;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;

public class Example {public static void main(String[] args) { Set 
s =
Collections.newSetFromMap(new ConcurrentHashMap<String,
Boolean>()); s.add("Fee"); s.add("Fi"); s.add("Fo"); s.add("Fum");  for 
(String v1 : s) {
   for (String v2 : s) {System.out.println(v1 + "<-->" + v2); } } } }

Kind regards,
Jonathan
On 10 September 2016 at 23:13, Dave Brosius
<dbros...@mebigfatguy.com <mailto:dbros...@mebigfatguy.com>> wrote:

It would be nice to be able to associate each element in a
collection with another element in the collection, which is
something very easily done with index based collections, but
with sets, etc this isn't so easy... unless i'm having a
brainfart. So i'd like to do this, but Iterator doesn't
implement Cloneable... Any reason not to? or is there another
way that's missing me? public class ItClone { public
static void main(String[] args) { Set s =
Collections.newSetFromMap(new ConcurrentHashMap<String,
Boolean>()); s.add("Fee"); s.add("Fi");  
  s.add("Fo"); s.add("Fum"); Iterator
it1 = s.iterator(); while (it1.hasNext()) {  
  String v1 = it1.next(); Iterator it2 =

(Iterator) it1.*clone*(); while
(it2.hasNext()) { String v2 = it2.next();
System.out.println(v1 + " <-->" + v2);
} } } } 

Make iterators cloneable?

[Dave Brosius]

It would be nice to be able to associate each element in a collection 
with another element in the collection, which is something very easily 
done with index based collections, but with sets, etc this isn't so 
easy... unless i'm having a brainfart.


So i'd like to do this, but Iterator doesn't implement Cloneable... Any 
reason not to? or is there another way that's missing me?


public class ItClone {

public static void main(String[] args) {
Set s = Collections.newSetFromMap(new 
ConcurrentHashMap());


s.add("Fee");
s.add("Fi");
s.add("Fo");
s.add("Fum");

Iterator it1 = s.iterator();
while (it1.hasNext()) {
String v1 = it1.next();

Iterator it2 = (Iterator) it1.*clone*();
while (it2.hasNext()) {
String v2 = it2.next();

System.out.println(v1 + " <-->" + v2);
}
}
}
}

Deprecation of String(String) constructor

[Dave Brosius]

Hi Folks,

I notice in that the

String 
(String 
 original)


constructor as seen here

http://download.java.net/java/jdk9/docs/api/index.html

is not deprecated... Is there any reason it should not be?

Originally it made some sense when String byte array sharing was used, 
but now that that is gone, i don't see the point. Am I missing something?

Re: RFR(m): 8145468u1 deprecations for java.lang

[Dave Brosius]

Greetings,

Along these lines, is there a reason not to deprecate the

String(String s)

constructor? Now that substring doesn't glom off the original string, i 
see no reason for this constructor.


-dave

On 04/15/2016 06:36 PM, Stuart Marks wrote:

Hi all,

Here's a small update to the jdk repo webrev for this change. There 
are no changes to any API deprecations or other specification changes. 
The changes are confined to the warnings cleanup work.


http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.1.jdk/

The files changed relative to the previous webrev are as follows.

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java

 - revert autoboxing per Remi, add @SuppressWarnings and comments

src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java
src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionExecuter.java

 - cleanups as suggested by Paul

src/java.base/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java 


src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java 



 - cleanups to windows files that I had missed previously

There are also no changes to langtools or top repo; those webrevs are 
unchanged:


http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.langtools/
http://cr.openjdk.java.net/~smarks/reviews/8145468/webrev.0.top/

Thanks,

s'marks

Match.appendReplacement with StringBuilder

[Dave Brosius]

Greetings,

   It would be nice if java.util.regex.Matcher had a replacement for

Matcher  appendReplacement(StringBuffer sb, String 
replacement)

StringBuffer appendTail(StringBuffer sb)


That took StringBuilder.

ExceptionTable addition?

[Dave Brosius]

Greetings,

From a byte code analysis--toolsy point of view, it would be nice 
if you could deterministically find the end of a catch/finally block. 
Unfortunately, the ExceptionTable attribute only lists the starts of 
trys/catches/finallys.


Now obviously, there are times when you can determine the end of the 
catch/finally block:


 If for instance a try block exits normally, javac, will insert a GOTO, 
from which you can clean the 'continuation' PC.


You can also determine the end of a catch block if it is followed by 
another catch or finally block.


However, there are pretty regular cases where you cannot, for instance 
if a try block ends with a return or a throw, and there is only one 
catch block or finally block, or those catch blocks that exist (before 
the last one) also return or throw.


String someMethod() {
   try {
return getSomething();
   } catch (IOException e) {
LOGGER.log("Oops");
   }

   return doSomeMoreStuff();
}

In this scenario, there's no way to know if the 'doSomeMoreStuff() is in 
the catch block or not.


Now from a program execution point of view, it doesn't really matter. 
You can consider everything below the catch, (or finally) block to be 
part of that catch (or finally) block.


But there are cases, where for code analysis, you would really like to know.

---

It would be really nice if the ExceptionTable also listed a 
'continuation pc'.