Re: RFR: 8065831: Ensure the pack200/unpack200 help is consistent with man page

[Mandy Chung]

> On Jun 14, 2016, at 6:31 PM, Kumar Srinivasan  
> wrote:
> 
> Thanks for looking at this. I wrapped all of them.
> 
> http://cr.openjdk.java.net/~ksrini/8065831/webrev.01/
> 
> 

Looks fine.  Disclaimer - I didn’t validate with the current implementation :)

Mandy

Re: RFR: 8065831: Ensure the pack200/unpack200 help is consistent with man page

[Kumar Srinivasan]

Thanks for looking at this. I wrapped all of them.

http://cr.openjdk.java.net/~ksrini/8065831/webrev.01/


Kumar



On Jun 14, 2016, at 1:19 PM, Kumar Srinivasan  
wrote:

Hi,

Please review the simple changes which makes pack200
help consistent with man page.
http://cr.openjdk.java.net/~ksrini/8065831/webrev.00/

Can you wrap the long lines?

Mandy

RE: A new helper method Arrays.asArray

[timo.kinnunen]

The same issue is present even without any varargs or generics present, when 
using plain old arrays:

String[] list1 = new String[1];
list1[0] = "hello";
Integer[] list2 = new Integer[1];
list2[0] = 1;
String[][] array = {list1, null};
Object[][] array2 = array;
array2[1] = list2;
for(String[] l : array) {
System.out.println(l[0]);
}

Both issues stem from these unsafe implicit conversions which don’t get a 
warning:

private static List[] implicit1(List[] it) {
return it;
}

private static Object[][] implicit2(String[][] it) {
return it;
}


I don’t like these conversions either but I don’t see them directly relevant to 
introducing an Arrays.asArray()-method.

If you want to try to introduce mandatory warnings for these conversions I will 
definitely cheer you on!






-- 
Have a nice day, 
Timo

Sent from Mail for Windows 10

From: fo...@univ-mlv.fr

Re: Chair voting to *accept* (rather than approve) 8159111: JShell API: Add access to wrappers and dependencies

[Joseph D. Darcy]

On 6/14/2016 5:44 PM, Joseph D. Darcy wrote:

Chair voting to approve 8159111: JShell API: Add access to wrappers and dependencies

[Joseph D. Darcy]

Re: A new helper method Arrays.asArray

[forax]

- Mail original -

> De: "timo kinnunen" 
> À: "Remi Forax" 
> Cc: "core-libs-dev" , "Louis Wasserman"
> 
> Envoyé: Mardi 14 Juin 2016 23:39:19
> Objet: RE: A new helper method Arrays.asArray

> I think @SafeVarargs should be OK here since the array containing the varargs
> already exists before the method starts executing and so the annotation
> amounts to asserting that the passed-in vararg-array is just as safe during
> the execution of the method as it is after the method execution completes.

> In any case, I’m only adding it to my versions to silence a compiler warning.
> In a JDK version the API doc should nail down that the method executes
> indistinguishable from a method which simply returns the passed-in array and
> the JDK version can freely choose which annotations to have. I would
> actually prefer the JDK implementation to use @ForceInline or something like
> that instead which my versions can’t use. This would guarantee that there is
> no overhead in calling the method and that type-safety issues present, if
> any, will occur within the calling context. Which is where they would have
> been introduced.

Given the code of your method, it will be inlined because the implementation is 
trivial. 

And your code is unsafe because you can have a ClassCastException with no 
warning at a line where you see no cast,far away from where the bug lies, 
List list1 = new ArrayList<>(); 
list1.add("hello"); 
List list2 = new ArrayList<>(); 
list2.add(1); 

List[] array = asArray(list1, null); 
List[] array2 = array; 
array2[1] = list2; 

for(List l: array) { 
System.out.println(l.get(0)); 
} 

A warning in Java means something goes wrong and the compiler and the VM can 
not help you, forget about @SuppressWarnings or @SafeVarargs and change your 
code if you are not writing a class of java.util or guava. 

cheers, 
Rémi 

> --
> Have a nice day,
> Timo

> Sent from Mail for Windows 10

> From: Remi Forax
> Sent: Tuesday, June 14, 2016 21:43
> To: timo kinnunen
> Cc: core-libs-dev ; Louis Wasserman
> Subject: Re: A new helper method Arrays.asArray

> Hi Timo,

> your implementation can not use @SafeVarargs because you leak the array (you
> return it) so you're code is not safe because you can not be sure that the
> resulting array will not be modified after the call to asArray.

> Louis, because you can not create an array of parametrized type in Java :)

> Here, the easy solution is to not create an array but a List,

> List list = List.of(sort0, sort1);

> or

> List list = Arrays.asList(sort0, sort1);

> depending if you want a mutable List (but with a fixed size) or an immutable
> one.

> cheers,

> Rémi

> - Mail original -

> > De: "Louis Wasserman" 

> > À: "timo kinnunen" , "core-libs-dev"
> > 

> > Envoyé: Mardi 14 Juin 2016 19:47:23

> > Objet: Re: A new helper method Arrays.asArray

> >

> > Why would you not just write new Object[] {sort0, sort1, sort2, sort3}?

> >

> > On Tue, Jun 14, 2016, 10:35 AM  wrote:

> >

> > >

> > > Hi,

> > >

> > > I have found that many times I need to write this simple helper method:

> > >

> > > public static @SafeVarargs  T[] asArray(T… ts) { return ts; }

> > >

> > >

> > > I usually need this when I have several implementations I’m comparing and

> > > I want to change the code for observing one of them to observing two or

> > > more of them in sequence. I feel that in this case switching from
> > > operating

> > > on one object to operating on an unknown List implementation (from

> > > Arrays.asList) is a too drastic change when all I need is put a for-loop

> > > around some code and iterate.

> > >

> > > The code for which I have to write this method is often some variation of

> > > something like this:

> > >

> > > Comparator sort1 = (x, y) -> (Integer) x - (Integer) y;

> > > Comparator sort0 = (x, y) -> (int) (Math.pow((Integer) x,

> > > 2.0) - Math.pow((Integer) y, 2.0));

> > >

> > > // Have to use a helper method here

> > > Comparator[] sorts = asArray(sort0, sort1, sort2, sort3);

> > >

> > >

> > > Please consider and add this simple method to Arrays.

> > >

> > >

> > >

> > > --

> > > Have a nice day,

> > > Timo

> > >

> > > Sent from Mail for Windows 10

> > >

> > >

> >

RE: A new helper method Arrays.asArray

[timo.kinnunen]

I think @SafeVarargs should be OK here since the array containing the varargs 
already exists before the method starts executing and so the annotation amounts 
to asserting that the passed-in vararg-array is just as safe during the 
execution of the method as it is after the method execution completes. 

In any case, I’m only adding it to my versions to silence a compiler warning. 
In a JDK version the API doc should nail down that the method executes 
indistinguishable from a method which simply returns the passed-in array and 
the JDK version can freely choose which annotations to have. I would actually 
prefer the JDK implementation to use @ForceInline or something like that 
instead which my versions can’t use. This would guarantee that there is no 
overhead in calling the method and that type-safety issues present, if any, 
will occur within the calling context. Which is where they would have been 
introduced.






-- 
Have a nice day, 
Timo

Sent from Mail for Windows 10

From: Remi Forax

Re: RFR: 8065831: Ensure the pack200/unpack200 help is consistent with man page

[Mandy Chung]

> On Jun 14, 2016, at 1:19 PM, Kumar Srinivasan  
> wrote:
> 
> Hi,
> 
> Please review the simple changes which makes pack200
> help consistent with man page.
> http://cr.openjdk.java.net/~ksrini/8065831/webrev.00/

Can you wrap the long lines?

Mandy

Re: RFR JDK-8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException

[Stuart Marks]

Hi Sherman,

The fix looks good.

It would be helpful if the test for 8072582 generated the string instead of 
using a literal that's more than 1K long. The exact length is significant 
because Scanner's default buffer size is 1024, so the delimiter has to straddle 
the buffer boundary.


The 8139414 test generates its string, which is nicer. In this case the test is 
taken from the bug report, but in my opinion the addition of the "boundary" 
variable (which is the string ";") makes things more obscure. I'd suggest 
inlining it.


For both test cases it might be helpful to have a little utility that appends n 
copies of a char to a StringBuilder.


Thanks,

s'marks

On 6/8/16 1:57 PM, Xueming Shen wrote:

Hi,

Please help review the change for

JDK-8139414: java.util.Scanner hasNext() returns true, next() throws
NoSuchElementException
JDK-8072582: Scanner delimits incorrectly when delimiter spans a buffer boundary

issue: https://bugs.openjdk.java.net/browse/JDK-8139414
   https://bugs.openjdk.java.net/browse/JDK-8072582
webrev: http://cr.openjdk.java.net/~sherman/8072582_8139414/webrev

In both cases the delimiter pattern is a kinda of "alternation" regex construct
which can "match" the existing characters at the end of the internal buffer as
delimiters, AND can extend to match more delimiters if more input is available.

In issue JDK-8139414, the hasNext() uses hasTokenInBuffer() to find the 
delimiters
"-;". It does not go beyond the boundary to check if there is more character, 
such
as "-" that can also be part of the delimiters). So hasNext() returns true with 
the
assumption that there is a token because there is/are more character after "-;".
But method getCompleteTokenInBuffer() (used by next() implementation), which
has the logic to check beyond the boundary even the delimiter pattern already
has a match. It matches "-;-" as the delimiters and then find no "next" (null)
after
that.

Similar for issue 8072582. This time the getCompleteTokenInBuffer does not
use the "lookingAt() and beyond" logic for the second delimiters, which triggers
problem when the delimiter pattern has different match result (beginning 
position)
for cases within boundary and beyond boundary.

The proposed fix here is to always check if there is more input when match
delimiters at the internal buffer boundary.

Thanks,
Sherman

RFR: 8065831: Ensure the pack200/unpack200 help is consistent with man page

[Kumar Srinivasan]

Hi,

Please review the simple changes which makes pack200
help consistent with man page.
http://cr.openjdk.java.net/~ksrini/8065831/webrev.00/

Thanks
Kumar

Re: Create java.util.stream.Stream from Iterator / Enumeration

[Patrick Reinhart]

Hi Paul,

I see the point, that making it too easy there.  I might have to some
little explain where I have started from. I wanted to go over all
resource URL's from a ClassLoader and read them as a Stream:

Enumeration resources =
myInstance.getClassLoader().getResources("resource.name");
Collections.list(resources).stream()

Which will internally copy all elements right away into an ArrayList and
does more than I wanted... :-)

So, with that your good reasons in mind, in my case leaded me in a wrong
solution in the first attempt too - thanks good I looked into the source
code ;-)

In my case then is the used approach to get a Stream correct?

Cheers

Patrick



On 14.06.2016 18:26, Paul Sandoz wrote:
> Hi Patrick,
>
> Enumeration now has an asIterator method, that’s our attempt to bridge the 
> old traversal world to the less old ( :-) ) world.
>
> Bridging the gap between the less old world and the new world (streams) is 
> more subtle, and we have been holding out on that.
>
> We wanted to avoid providing simple methods to create a Stream from an 
> Iterator, that might serve as an attractive nuisance e.g. 
> Stream.of(arrayList.iterator()), rather than arrayList.stream(), and there 
> are details of size, order etc for which any defaults might be poor or just 
> wrong depending the Iterator’s source of elements.
>
> For example, your helper method assumes that the Iterator is covering a 
> structure that is both immutable and ordered, but what if the Iterator was 
> obtained from a HashSet?
>
> If we chose to provide such a helper method we would have to assume that the 
> Iterator’s source of elements is of unknown size, order and mutability, 
> essentially no Spliterator characteristics can be derived from the Iterator.
>
> Paul.
>
>> On 14 Jun 2016, at 01:13, Patrick Reinhart  wrote:
>>
>> Hi there,
>>
>> I know you are busy getting the latest release ready. Still I have question 
>> according the java.util.stream.Stream's static helper methods. During my 
>> work I ran into a couple places where creating a Stream out of a Iterator or 
>> Enumeration directly would be quite handy.
>>
>> At the moment I have made me two methods like this on a helper class in oder 
>> to not duplicate the code:
>>
>>  public static  Stream iterate(Iterator iterator) {
>>Objects.requireNonNull(iterator);
>>return StreamSupport.stream(Spliterators
>>  .spliteratorUnknownSize(iterator, Spliterator.ORDERED | 
>> Spliterator.IMMUTABLE), false);
>>  }
>>
>>  public static  Stream iterate(Enumeration enumeration) {
>>Objects.requireNonNull(enumeration);
>>final Iterator iterator = new Iterator() {
>>  @Override
>>  public boolean hasNext() {
>>return enumeration.hasMoreElements();
>>  }
>>
>>  @Override
>>  public T next() {
>>return enumeration.nextElement();
>>  }
>>};
>>return iterate(iterator);
>>  }
>>
>>
>> My question is now, if it would be worth while having something like this on 
>> the Stream itself?
>>
>>
>> Cheers
>>
>> Patrick

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

[Gerard Ziemski]

hi Brent,

Thank you very much for tackling this. The code overall looks good (aside from 
the 3 code language sub tag case that we need to handle, as Naoto pointed out)

Here are my 2 small comments:

#1

 63 CFRelease(languages); // was missing from original patch

I think we can drop the comment from line 63?


#2

131 void setOSNameAndVersion(java_props_t *sprops) {
132 /* Don't rely on JRSCopyOSName because there's no guarantee the value 
will
133  * remain the same, or even if the JRS functions will continue to be 
part of
134  * Mac OS X.  So hardcode os_name, and fill in os_version if we can.
135  */

The comment from lines 132-135 should be dropped - we no longer use JSR - and 
just say that we're hardcoding the OS name?


cheers

> On Jun 13, 2016, at 3:58 PM, Brent Christian  
> wrote:
> 
> Hi,
> 
> Please review this Mac-only fix:
> 
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-7131356
> 
> Thanks go to Gerard Ziemski for the thorough investigation and detailed 
> write-up in the bug report.
> 
> The symptoms:
> 
> On those OS X machines where the default system Java is not installed, any 
> attempt to instantiate JVM from a local JDK (for example via JNI as shown in 
> the bug) presents "No Java installed. Do you want to install Java?" dialog 
> and refuses to run. Clearly, a valid local JDK should be able to run in this 
> case.
> 
> The problem:
> 
> In java_props_macosx.c, there is code that dynamically looks up 4 methods in 
> JavaRuntimeSupport.framework (JRS) and calls into them to find out localized 
> OS version, default locale and the preferred language, but JRS checks for a 
> system available Java and refuses to run if none found.
> 
> Background:
> 
> JavaRuntimeSupport.framework (JRS) is a framework implemented and provided by 
> Apple for use by Java.  It is a "black box" that wraps SPIs required by the 
> Apple-provided implementation of JDK, exposing them to the JDK as APIs.
> 
> Now that the JDK implementation ownership has changed from Apple to Oracle, 
> we have the issue that we don't control the JRS implementation, but rely on 
> Apple to support it for our JDK to continue to run. Depending on a private 
> framework provided by a third party for our code to continue to run doesn't 
> seem like a good long term bet (see also 8024281).
> 
> Proposed solution:
> 
> Apple suggested changing the JDK initialization order so any access to JRS 
> happens only after the JLI_MemAlloc symbol is available.  We believe a better 
> solution is to re-implement the JSR APIs in question, as a move toward 
> eventually dropping reliance on JSR altogether.  The three main changes are:
> 
> 1. In "getMacOSXLocale", re-implement "JRSCopyPrimaryLanguage" using 
> "CFLocaleCopyPreferredLanguages", which gives us the preferred language as 
> set in "System Preferences"->"Language & Text"->"Language" in the form of 
> "xx" (ie. just the language code - ex. "en", "fr", etc.).  The original Apple 
> code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map 
> "language" into "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), 
> though this appears to be unnecessary.  Following the call to 
> setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map the 
> language to a default country, per this comment:
> 
> * If the locale name (without .encoding@variant, if any) matches
> * any of the names in the locale_aliases list, map it to the
> * corresponding full locale name.  Most of the entries in the
> * locale_aliases list are locales that include a language name but
> * no country name, and this facility is used to map each language
> * to a default country if that's possible.
> 
> I tried out a few locales, for English (en_US, en_GB), German (de_DE, de_CH) 
> and French (fr_FR, fr_CA).  Language/country system properties behave the 
> same before and after this change, as does the java.util.Locale test attached 
> to the bug.
> 
> 2. In "setupMacOSXLocale" we simply drop the call to 
> "JRSSetDefaultLocalization" as it appears to be a NOP. According to Apple, 
> that API sets up native bundle locale, so that any access to native Cocoa UI 
> (like FileOpenChooser) uses localized strings. Testing shows that this does 
> not seem to work even in Apple's own JDK (ie. JDK 6), so dropping the call to 
> this SPI here does not result in a regression.  An issue was filed to 
> investigate further (8024279, a dup of 8019464) which has since been closed 
> as, "Not an Issue".
> 
> 3. In "setOSNameAndVersion", re-implement JRSCopyOSVersion using 
> [NSProcessInfo operatingSystemVersion].  (Use of JRSCopyOSName was already 
> removed by 7178922).
> 
> 
> Thanks,
> -Brent
> 
> 1. 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/79043a1c3547/src/java.base/unix/native/libjava/java_props_md.c
> 

Re: A new helper method Arrays.asArray

[Remi Forax]

Hi Timo,
your implementation can not use @SafeVarargs because you leak the array (you 
return it) so you're code is not safe because you can not be sure that the 
resulting array will not be modified after the call to asArray.

Louis, because you can not create an array of parametrized type in Java :)

Here, the easy solution is to not create an array but a List,
  List list = List.of(sort0, sort1);
or
  List list = Arrays.asList(sort0, sort1);
depending if you want a mutable List (but with a fixed size) or an immutable 
one.

cheers,
Rémi

- Mail original -
> De: "Louis Wasserman" 
> À: "timo kinnunen" , "core-libs-dev" 
> 
> Envoyé: Mardi 14 Juin 2016 19:47:23
> Objet: Re: A new helper method Arrays.asArray
> 
> Why would you not just write new Object[] {sort0, sort1, sort2, sort3}?
> 
> On Tue, Jun 14, 2016, 10:35 AM  wrote:
> 
> >
> > Hi,
> >
> > I have found that many times I need to write this simple helper method:
> >
> > public static @SafeVarargs  T[] asArray(T… ts) { return ts; }
> >
> >
> > I usually need this when I have several implementations I’m comparing and
> > I want to change the code for observing one of them to observing two or
> > more of them in sequence. I feel that in this case switching from operating
> > on one object to operating on an unknown List implementation (from
> > Arrays.asList) is a too drastic change when all I need is put a for-loop
> > around some code and iterate.
> >
> > The code for which I have to write this method is often some variation of
> > something like this:
> >
> >Comparator sort1 = (x, y) -> (Integer) x - (Integer) y;
> >Comparator sort0 = (x, y) -> (int) (Math.pow((Integer) x,
> > 2.0) - Math.pow((Integer) y, 2.0));
> >
> >// Have to use a helper method here
> >Comparator[] sorts = asArray(sort0, sort1, sort2, sort3);
> >
> >
> > Please consider and add this simple method to Arrays.
> >
> >
> >
> > --
> > Have a nice day,
> > Timo
> >
> > Sent from Mail for Windows 10
> >
> >
> 

Re: RFR: 8153652 Update javap to be multi-release jar aware

[Alan Bateman]

On 14/06/2016 18:16, Steve Drach wrote:
Please review the following changeset that simply supplies the help 
information for the already existing javap command line option, 
-multi-release.


webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ 
 
>
issue: https://bugs.openjdk.java.net/browse/JDK-8153652 



It turns out that javap forwards unrecognized command line options 
to the JavaFileManager for processing.  One such option is 
-multi-release. The value that the -multi-release option is set to 
is used by JavaFileManager to open multi-release jar files so that 
the appropriate versioned view is presented to the client, javap in 
this case.  All this changeset does is add a help message describing 
the existing -multi-release command line option.


The values that can be assigned to this option, and the 
corresponding multi-release modes that the jar file is configured 
for are:


9 -> JarFile.Release.VERSION_9
runtime   -> JarFile.Release.RUNTIME
all others -> JarFile.Release.BASE

If the option is not present, the jar file mode is JarFile.Release.Base.

Is -multi-release the agreed option? Just curious as I would have 
expected -multirelease. If GNU style then it would be --multi-release 
of course.


-multi-release is the option defined in javac options
Is that in JDK 9 yet? It doesn't seem consistent with options like 
-processor path, -modulepath, and other multi-word options. Also if were 
to add GNU style then it might mean -multi-release and --multi-release.


-Alan

A new helper method Arrays.asArray

[timo.kinnunen]

Hi, 

I have found that many times I need to write this simple helper method:

public static @SafeVarargs  T[] asArray(T… ts) { return ts; }


I usually need this when I have several implementations I’m comparing and I 
want to change the code for observing one of them to observing two or more of 
them in sequence. I feel that in this case switching from operating on one 
object to operating on an unknown List implementation (from Arrays.asList) is a 
too drastic change when all I need is put a for-loop around some code and 
iterate.

The code for which I have to write this method is often some variation of 
something like this:
 
   Comparator sort1 = (x, y) -> (Integer) x - (Integer) y;
   Comparator sort0 = (x, y) -> (int) (Math.pow((Integer) x, 2.0) - 
Math.pow((Integer) y, 2.0));
   
   // Have to use a helper method here
   Comparator[] sorts = asArray(sort0, sort1, sort2, sort3);
   

Please consider and add this simple method to Arrays.



-- 
Have a nice day, 
Timo

Sent from Mail for Windows 10

Re: RFR: 8153652 Update javap to be multi-release jar aware

[Steve Drach]

>> Please review the following changeset that simply supplies the help 
>> information for the already existing javap command line option, 
>> -multi-release.
>> 
>> webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ 
>> 
>> issue: https://bugs.openjdk.java.net/browse/JDK-8153652 
>> 
>> 
>> It turns out that javap forwards unrecognized command line options to the 
>> JavaFileManager for processing.  One such option is -multi-release. The 
>> value that the -multi-release option is set to is used by JavaFileManager to 
>> open multi-release jar files so that the appropriate versioned view is 
>> presented to the client, javap in this case.  All this changeset does is add 
>> a help message describing the existing -multi-release command line option.
>> 
>> The values that can be assigned to this option, and the corresponding 
>> multi-release modes that the jar file is configured for are:
>> 
>> 9 -> JarFile.Release.VERSION_9
>> runtime   -> JarFile.Release.RUNTIME
>> all others -> JarFile.Release.BASE
>> 
>> If the option is not present, the jar file mode is JarFile.Release.Base.
>> 
> Is -multi-release the agreed option? Just curious as I would have expected 
> -multirelease. If GNU style then it would be --multi-release of course.

-multi-release is the option defined in javac options

Re: RFR: 8153652 Update javap to be multi-release jar aware

[Alan Bateman]

On 13/06/2016 18:24, Steve Drach wrote:


Hi,

Please review the following changeset that simply supplies the help information 
for the already existing javap command line option, -multi-release.

webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ 

issue: https://bugs.openjdk.java.net/browse/JDK-8153652 


It turns out that javap forwards unrecognized command line options to the 
JavaFileManager for processing.  One such option is -multi-release.  The value 
that the -multi-release option is set to is used by JavaFileManager to open 
multi-release jar files so that the appropriate versioned view is presented to 
the client, javap in this case.  All this changeset does is add a help message 
describing the existing -multi-release command line option.

The values that can be assigned to this option, and the corresponding 
multi-release modes that the jar file is configured for are:

9 -> JarFile.Release.VERSION_9
runtime   -> JarFile.Release.RUNTIME
all others -> JarFile.Release.BASE

If the option is not present, the jar file mode is JarFile.Release.Base.

Is -multi-release the agreed option? Just curious as I would have 
expected -multirelease. If GNU style then it would be --multi-release of 
course.


-Alan.

Re: RFR: 81536534 Update jdeps to be multi-release jar aware

[Mandy Chung]

> On Jun 14, 2016, at 9:41 AM, Steve Drach  wrote:
> 
> Hi Mandy,
> 
>>> Please review the following changeset to make jdeps multi-release jar aware.
>>> 
>>> webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html 
>>> 
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8153654 
>>> 
>>> 
>>> The changeset adds a new command line option to jdeps.  The -multi-release 
>>> option can be set to the string “runtime” or an integral string value 
>>> corresponding to the Java platform releases starting at 9 (i.e. 9, 10, 11, 
>>> etc.).  Jar files that jdeps accesses, either on the class path or as a 
>>> target, are opened with the appropriate JarFile.Release parameter.  The 
>>> mapping from -multi-release value to JarFile.Release is:
>>> 
>>> 9 -> JarFile.Release.VERSION_9
>>> runtime   -> JarFile.Release.RUNTIME
>>> all others -> JarFile.Release.BASE
>>> 
>>> If the option is not present, the jar file mode is JarFile.Release.Base.
>> 
>> Have you considered parsing all versioned entries in MRJAR as the default 
>> and include the version information in the output?
> 
> Briefly ;-)  But now that you brought it up, I think the right thing to do is 
> to rescind this RFR and redesign the output for jdeps so that it’ll be more 
> useful for the users by doing what you suggest.

Sounds good.

Mandy

Re: RFR: 81536534 Update jdeps to be multi-release jar aware

[Steve Drach]

Hi Mandy,

>> Please review the following changeset to make jdeps multi-release jar aware.
>> 
>> webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html 
>> 
>> issue: https://bugs.openjdk.java.net/browse/JDK-8153654 
>> 
>> 
>> The changeset adds a new command line option to jdeps.  The -multi-release 
>> option can be set to the string “runtime” or an integral string value 
>> corresponding to the Java platform releases starting at 9 (i.e. 9, 10, 11, 
>> etc.).  Jar files that jdeps accesses, either on the class path or as a 
>> target, are opened with the appropriate JarFile.Release parameter.  The 
>> mapping from -multi-release value to JarFile.Release is:
>> 
>> 9 -> JarFile.Release.VERSION_9
>> runtime   -> JarFile.Release.RUNTIME
>> all others -> JarFile.Release.BASE
>> 
>> If the option is not present, the jar file mode is JarFile.Release.Base.
> 
> Have you considered parsing all versioned entries in MRJAR as the default and 
> include the version information in the output?

Briefly ;-)  But now that you brought it up, I think the right thing to do is 
to rescind this RFR and redesign the output for jdeps so that it’ll be more 
useful for the users by doing what you suggest.

>  
> 
> A relevant implementation details:
> 
> jdeps is using its runtime environment to analyse the class dependencies.  
> The potential missing information when analyzing a MR jar is some JDK 
> internal APIs not present in the current runtime but exists in the older 
> release. jdeps maintains a small list of the removed sun.misc and sun.reflect 
> internal APIs to emit useful information since existing libraries may depend 
> on those removed types that already have replacement; otherwise, they will be 
> shown as not found which is accurate as CNFE may be thrown if that library is 
> running on JDK 9.
> 
> Mandy
> 

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

[Brent Christian]

On 6/13/16 4:20 PM, Brent Christian wrote:

On 13/06/2016 14:43, Naoto Sato wrote:


Also, the array index "2" to assume the language length is 2 is not
correct, as there are three letter language codes. So the code should
literally look for "-" instead.


Great, thanks.  I will fix that.


FYI, there will be a little more to this.  Some language IDs include a 
script ID: a four-character code separated from the main language 
designator by a '-'.  ("zh-Hans" for Simplified Chinese, for instance).

In this case, the '-' at index 2 should be left alone.  See [1].

-Brent

1. 
https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html

Re: Create java.util.stream.Stream from Iterator / Enumeration

[Paul Sandoz]

Hi Patrick,

Enumeration now has an asIterator method, that’s our attempt to bridge the old 
traversal world to the less old ( :-) ) world.

Bridging the gap between the less old world and the new world (streams) is more 
subtle, and we have been holding out on that.

We wanted to avoid providing simple methods to create a Stream from an 
Iterator, that might serve as an attractive nuisance e.g. 
Stream.of(arrayList.iterator()), rather than arrayList.stream(), and there are 
details of size, order etc for which any defaults might be poor or just wrong 
depending the Iterator’s source of elements.

For example, your helper method assumes that the Iterator is covering a 
structure that is both immutable and ordered, but what if the Iterator was 
obtained from a HashSet?

If we chose to provide such a helper method we would have to assume that the 
Iterator’s source of elements is of unknown size, order and mutability, 
essentially no Spliterator characteristics can be derived from the Iterator.

Paul.

> On 14 Jun 2016, at 01:13, Patrick Reinhart  wrote:
> 
> Hi there,
> 
> I know you are busy getting the latest release ready. Still I have question 
> according the java.util.stream.Stream's static helper methods. During my work 
> I ran into a couple places where creating a Stream out of a Iterator or 
> Enumeration directly would be quite handy.
> 
> At the moment I have made me two methods like this on a helper class in oder 
> to not duplicate the code:
> 
>  public static  Stream iterate(Iterator iterator) {
>Objects.requireNonNull(iterator);
>return StreamSupport.stream(Spliterators
>  .spliteratorUnknownSize(iterator, Spliterator.ORDERED | 
> Spliterator.IMMUTABLE), false);
>  }
> 
>  public static  Stream iterate(Enumeration enumeration) {
>Objects.requireNonNull(enumeration);
>final Iterator iterator = new Iterator() {
>  @Override
>  public boolean hasNext() {
>return enumeration.hasMoreElements();
>  }
> 
>  @Override
>  public T next() {
>return enumeration.nextElement();
>  }
>};
>return iterate(iterator);
>  }
> 
> 
> My question is now, if it would be worth while having something like this on 
> the Stream itself?
> 
> 
> Cheers
> 
> Patrick

RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

[Ramanand Patil]

Hi all,

May I request one more review for this bug fix.?

Thank you very much Daniel for your review.


Regards,
Ramanand.

-Original Message-
From: Daniel Fuchs 
Sent: Friday, June 10, 2016 7:47 PM
To: Ramanand Patil; Bernd Eckenfels; core-libs-dev@openjdk.java.net
Subject: Re: RFR: 8153955: java.util.logging.FileHandler can not create file 
synchronously over 101 access

Hi Ramanand,

Looks good to me now.

best regards,

-- daniel

On 10/06/16 14:47, Ramanand Patil wrote:
> Hi Daniel and Bernd,
> Thank you for your reviews.
> Here is the updated Webrev: 
> http://cr.openjdk.java.net/~rpatil/8153955/webrev.02/
>
> Bernd,
> Considering the information that "if the FileHandler tries to open the 
> filename and finds the file is currently in use by another process it will 
> increment the unique number field and try again" what you suggested looks 
> correct. But using concurrent/synchronous too should not make it wrong, 
> because at this time all the files are used simultaneously and any file which 
> is not in use will be opened and used by FileHandler. I think this should not 
> make a big difference, but as per your suggestion I have altered only that 
> section of logging.properties.
> Test is also updated with the suggested comment. Thank you.
>
> Daniel,
> 1. FileHandler.java: Changed the wordings as you suggested.
> 2. FileHandlerMaxLocksTest::main
>   - Now using "user.dir" in createLoggerDir(). I saw some tests(like 
> java/util/logging/FileHandlerPath.java) were already using user home or temp 
> directory, so thought that should not be a problem.
>   - Removed the WeekReference and using ArrayList for all the FileHandler 
> instances.
>   - Tested on Windows, Linux(Ubuntu14.04) and Solaris and test runs 
> fine(able to delete all the log files and loggerDir). Hopefully, test will 
> not have any issues on other platforms.(JPRT job is also passed).
>
>
> Regards,
> Ramanand.
>
> -Original Message-
> From: Bernd Eckenfels [mailto:e...@zusammenkunft.net]
> Sent: Thursday, June 09, 2016 11:16 PM
> To: Daniel Fuchs; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8153955: java.util.logging.FileHandler can not 
> create file synchronously over 101 access
>
> Hello,
>
> I find the "concurrent/synchronous" comment a bit confusing.
>
> How about:
>
> # Number of attempts to obtain lock file in FileHandler # Implemented 
> by incrementing the %u placeholder as documented # in FileHandler 
> Javadoc
>
> In the test I would add a comment
>
> "200 raises the default limit of 100, we try 102 times"
>
>
>
> Gruss
> Bernd
>
>
> Am Thu, 9 Jun 2016 07:31:25 +0100
> schrieb Daniel Fuchs :
>
>> Hi Ramanand,
>>
>> Thanks for the updated. I still have some remarks:
>>
>> FileHandler.java:
>>
>>98  *specifies the maximum number of concurrent locks hold
>> by 99  *FileHandler (defaults 100). 
>>
>> Is the verb form correct: hold => held ?
>>
>> logging.properties:
>>
>>42 # when the unique field %u is incremented as per the javadoc.
>>
>> "... as per the javadoc" => "... as per FileHandler API documentation"
>>
>> FileHandlerMaxLocksTest.java:
>>
>> - FileHandlerMaxLocksTest::createLoggerDir():
>>
>>75 String tmpDir = System.getProperty("java.io.tmpdir");
>>76 if (tmpDir == null) {
>>77 tmpDir = System.getProperty("user.home");
>>78 }
>>79 File tmpOrHomeDir = new File(tmpDir);
>>80 File loggerDir = new File(tmpOrHomeDir, LOGGER_DIR);
>>
>> The preferred place for a test to create file is the scratch 
>> directory that jtreg creates for the test. The scratch directory 
>> location is available from the "user.dir" system property.
>>
>> I suggest changing the code above to:
>>
>> String userDir =   System.getProperty("user.dir", ".");
>> File loggerDir = new File(userDir, LOGGER_DIR);
>>
>> - FileHandlerMaxLocksTest::main
>>
>> I am not sure what you try to achieve by using WeakReference there.
>> I would suggest to store all created FileHandler instances into a 
>> list, which would allow you to close them properly in the finally 
>> clause just before deleting LOGGER_DIR.
>>
>> Different operating systems might handle lock files differently.
>> I am afraid that some operating system might not let you delete a 
>> directory that contains a file which is still locked by the system.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 09/06/16 06:40, Ramanand Patil wrote:
>>> Hi,
>>>
>>> Please review the updated Webrev at:
>>> http://cr.openjdk.java.net/~rpatil/8153955/webrev.01/
>>>
>>> FileHander.java and logging.properties files are updated as per 
>>> Daniel's suggestion.
>>>
>>>
>>> Regards,
>>> Ramanand.
>>>
>>>
>>> -Original Message-
>>> From: Daniel Fuchs
>>> Sent: Wednesday, June 08, 2016 6:57 PM
>>> To: Ramanand Patil; core-libs-dev@openjdk.java.net
>>> Subject: Re: RFR: 8153955: java.util.logging.FileHandler can not 
>>> create file synchronously 

Re: RFR: 8153652 Update javap to be multi-release jar aware

[Paul Sandoz]

> On 13 Jun 2016, at 10:24, Steve Drach  wrote:
> 
> Hi,
> 
> Please review the following changeset that simply supplies the help 
> information for the already existing javap command line option, 
> -multi-release.
> 
> webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ 
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8153652 
> 
> 
> It turns out that javap forwards unrecognized command line options to the 
> JavaFileManager for processing.  One such option is -multi-release.  The 
> value that the -multi-release option is set to is used by JavaFileManager to 
> open multi-release jar files so that the appropriate versioned view is 
> presented to the client, javap in this case.  All this changeset does is add 
> a help message describing the existing -multi-release command line option.
> 
> The values that can be assigned to this option, and the corresponding 
> multi-release modes that the jar file is configured for are:
> 
> 9 -> JarFile.Release.VERSION_9
> runtime   -> JarFile.Release.RUNTIME
> all others -> JarFile.Release.BASE
> 
> If the option is not present, the jar file mode is JarFile.Release.Base.
> 

Code change looks ok to me.

+main.opt.multi-release=\
+\  -multi-release  Specify the release value for multi-release jar 
files.\n\
+\   The release value is either "runtime" or an 
integer greater\n\
+\   than or equal to 9.  When specified, javap will 
look for class\n\
+\   files in the corresponding versioned directory of 
the jar file.

I am not sure what language you are consistently using but perhaps consider:

  "Specify the Java platform release version for multi-release jar files….” ?

as that might be more descriptive.

I think you will also need a CCC for the new option.

I guess any documentation can be followed up later on (e.g. man pages?), but i 
am not sure how to follow up on that.

Paul.

Re: RFR[9] 8039955: jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError:

[Paul Sandoz]

> On 13 Jun 2016, at 03:44, shilpi.rast...@oracle.com wrote:
> 
> Gentle reminder!
> 
> 
>  Forwarded Message 
> Subject:  RFR[9] 8039955: jdk/lambda/LambdaTranslationTest1 - 
> java.lang.AssertionError:
> Date: Tue, 7 Jun 2016 14:58:47 +0530
> From: shilpi.rast...@oracle.com 
> To:   core-libs-dev 
> 
> 
> 
> Hi All,
> 
> Please review fix for
> https://bugs.openjdk.java.net/browse/JDK-8039955
> http://cr.openjdk.java.net/~srastogi/8039955/webrev.00/
> 

+1

Paul.

Re: JDK 9 RFR of JDK-8159330: Improve deprecation text for Class.newInstance

[Roger Riggs]

Hi Joe,

With the full method context, the proposed text is sufficient.

Thanks, Roger

On 6/13/2016 12:37 PM, joe darcy wrote:

Hi Roger,

On 6/13/2016 6:59 AM, Roger Riggs wrote:

Hi,

That example kind of glosses over the need to handle 3 new exceptions.
That's been my annoyance with this change.

throws InstantiationException, IllegalAccessException, 
InvocationTargetException


The patch sent to the list 
(http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041754.html), 
did note addition exception types are thrown by the replacement code. 
The proposed text with Max's improvement is


+ * The call
+ *
+ * {@code
+ * clazz.newInstance()
+ * }
+ *
+ * can be replaced by
+ *
+ * {@code
+ * clazz.getConstructor().newInstance()
+ * }
+ *
+ * The latter sequence of calls is inferred to be able to throw
+ * the additional exception types {@link
+ * InvocationTargetException} and {@link
+ * NoSuchMethodException}. Both of these exception types are
+ * subclasses of {@link ReflectiveOperationException}.
+ *

Class.newInstance is declared to throw InstantiationException and 
IllegalAccessException. Its implementation internally catches 
NoSuchMethodException and rethrows it as something else.


I considered adding more text to guide developers more explicitly to 
either use multi-catch


catch(InstantiationException  | IllegalAccessException e) =>
catch(InstantiationException  | IllegalAccessException | 
InvocationTargetException | NoSuchMethodException e)


or catching ReflectiveOperationException

catch(InstantiationException  | IllegalAccessException e) =>
catch(ReflectiveOperationException e) =>

With the more precise rethrow feature added in 7, catching 
ReflectiveOperationException and then rethrowing it doesn't lose any 
type information.


I was hesitant to add such text as to not overwhelm further the 
non-deprecated text of the method. However, if people think such 
guidance is warranted, I'll craft something.


Thanks,

-Joe




Roger



On 6/12/2016 11:43 PM, joe darcy wrote:


On 6/12/2016 7:21 PM, Wang Weijun wrote:

Why not just clazz.getConstructor().newInstance()?


That seems to work to and is much shorter; thanks :-)

-Joe




+ * can be replaced by
+ *
+ * {@code
+ * clazz.getConstructor(new 
Class[0]).newInstance((Object[])null);

+ * }

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Jan Lahoda]

Hi Alan,

On 14.6.2016 12:57, Alan Bateman wrote:

On 13/06/2016 17:12, Jan Lahoda wrote:


Hello,

There is:
https://bugs.openjdk.java.net/browse/JDK-8153362

which is about a new warning that should be produced by javac when
exported API refers to types not exported/accessible to the API clients.

I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/

Did you have a short list of names for the lint option before deciding
on "unexportedinapi"? If time has already been put into this and this is


I had a few (e.g. "publishingunexported"), but none of them particularly 
nice.



the best of a bad bunch then ignore my mail. I bring it up because it
feels more like a "potentiallynotaccessible" or "notaccessible" or
"leaksnotaccessible". For the cases where we have ended up with


I like "leaksnotaccessible". Unless there would be better ideas or 
objections, I'd go with that. Thanks for the ideas!



protected fields in public classes but the field type is package-private
then the field is never accessible. For the JSObject.getWindow case then
consumers will need to require java.desktop to use this method.

Related is the description:

javac.opt.Xlint.desc.unexportedinapi=\
 Warn about use of types not visible to clients in exported API

Shouldn't get say something about the type potentially not accessible
rather than visible?


Yes, it should. I'll fix that. Thanks for catching that.

Jan



-Alan

PS: You asked about the JVMCI classes in the hotspot repo. While this
might look strange then it is intentional. The "framework" uses the
reflective APIs to export the otherwise internal packages to the JVMCI
implementation when it is located and loaded.

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Jan Lahoda]

Hi Phil,

Thanks for the comments. I was preferring @SuppressWarnings over 
-Xlint:-unexportedinapi because it allows to disable the check only on 
selected elements (as opposed to disabling it for a whole module, where 
a newly added API might inadvertently still cause a new warning); and 
also because it would be slightly easier to phase the change in. But I 
have no problem with using -Xlint:-unexportedinapi, I'll work on that.


Thanks,
Jan

On 13.6.2016 19:59, Phil Race wrote:

Hmm .. given that the majority of the jdk changes are in client -
specifically
swing & accessibility -  including the swing mailing list would have
increased the
likelihood of the right people clicking on this webrev link.

IMO,  we should remove these unusable fields from the Swing API - where
we can - and I think some we can, and really it ought to be all.

So I suggest that you leave alone those files and submit
bugs against swing & accessibility and the area owner
can then make the decision as to the appropriate treatment.

You can keep the JDK buildable in the meanwhile by suppressing the
lint warnings on the desktop module.

-phil.


On 06/13/2016 09:12 AM, Jan Lahoda wrote:

Hello,

There is:
https://bugs.openjdk.java.net/browse/JDK-8153362

which is about a new warning that should be produced by javac when
exported API refers to types not exported/accessible to the API clients.

I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/

There are some warnings produced for existing code in the hotspot and
jdk repositories (see the end for the warnings), I was using these
patches to keep JDK buildable:
hotspot repository:
http://cr.openjdk.java.net/~jlahoda/8153362/hotspot.00/
jdk repository:
http://cr.openjdk.java.net/~jlahoda/8153362/jdk.00/

Any help with those (esp. those in the hotspot repository) would be
wholeheartedly welcome.

Any feedback on this is welcome!

Thanks,
   Jan

The warnings:
-hotspot repository:
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72:
warning: unexported type referenced in exported API
public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/services/JVMCICompilerFactory.java:72:
warning: unexported type referenced in exported API
public abstract JVMCICompiler createCompiler(JVMCIRuntime runtime);
 ^
error: warnings found and -Werror specified
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:54:
warning: unexported type referenced in exported API
public int getCompilationLevelAdjustment(HotSpotVMConfig config) {
 ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotJVMCICompilerFactory.java:73:
warning: unexported type referenced in exported API
public int adjustCompilationLevel(HotSpotVMConfig config, Class
declaringClass, String name, String signature, boolean isOsr, int
level) {
  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70:
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode
compiledCode) {
  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70:
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode
compiledCode) {

  ^
.../hotspot/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/services/HotSpotVMEventListener.java:70:
warning: unexported type referenced in exported API
public void notifyInstall(HotSpotCodeCacheProvider
hotSpotCodeCacheProvider, InstalledCode installedCode, CompiledCode
compiledCode) {

   ^
1 error
7 warnings

-jdk/java.desktop:
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:333:
warning: inaccessible type referenced in exported API
protected DefaultAction defaultPressAction;
  ^
.../jdk/src/java.desktop/share/classes/javax/swing/JRootPane.java:344:
warning: inaccessible type referenced in exported API
protected DefaultAction defaultReleaseAction;
  ^
error: warnings found and -Werror specified
.../jdk/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java:742:
warning: inaccessible type referenced in exported API
protected MetalBumps bumps = new MetalBumps( 10, 10,
  ^

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

[Alan Bateman]

On 13/06/2016 17:12, Jan Lahoda wrote:


Hello,

There is:
https://bugs.openjdk.java.net/browse/JDK-8153362

which is about a new warning that should be produced by javac when 
exported API refers to types not exported/accessible to the API clients.


I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
Did you have a short list of names for the lint option before deciding 
on "unexportedinapi"? If time has already been put into this and this is 
the best of a bad bunch then ignore my mail. I bring it up because it 
feels more like a "potentiallynotaccessible" or "notaccessible" or 
"leaksnotaccessible". For the cases where we have ended up with 
protected fields in public classes but the field type is package-private 
then the field is never accessible. For the JSObject.getWindow case then 
consumers will need to require java.desktop to use this method.


Related is the description:

javac.opt.Xlint.desc.unexportedinapi=\
Warn about use of types not visible to clients in exported API

Shouldn't get say something about the type potentially not accessible 
rather than visible?


-Alan

PS: You asked about the JVMCI classes in the hotspot repo. While this 
might look strange then it is intentional. The "framework" uses the 
reflective APIs to export the otherwise internal packages to the JVMCI 
implementation when it is located and loaded.

Create java.util.stream.Stream from Iterator / Enumeration

[Patrick Reinhart]

Hi there,

I know you are busy getting the latest release ready. Still I have 
question according the java.util.stream.Stream's static helper methods. 
During my work I ran into a couple places where creating a Stream out of 
a Iterator or Enumeration directly would be quite handy.


At the moment I have made me two methods like this on a helper class in 
oder to not duplicate the code:


  public static  Stream iterate(Iterator iterator) {
Objects.requireNonNull(iterator);
return StreamSupport.stream(Spliterators
  .spliteratorUnknownSize(iterator, Spliterator.ORDERED | 
Spliterator.IMMUTABLE), false);

  }

  public static  Stream iterate(Enumeration enumeration) {
Objects.requireNonNull(enumeration);
final Iterator iterator = new Iterator() {
  @Override
  public boolean hasNext() {
return enumeration.hasMoreElements();
  }

  @Override
  public T next() {
return enumeration.nextElement();
  }
};
return iterate(iterator);
  }


My question is now, if it would be worth while having something like 
this on the Stream itself?



Cheers

Patrick