Re: jpackage --create-installer problem on Mac when installer-type is unspecified

[Lennart Börjeson]

OK.

May I hope that a fix for this will make its way to the early-access build soon?

(While I can build from source myself, it is much more convenient to use an EA 
in our CI cluster.)

/Lennart

> 11 mars 2019 kl. 18:04 skrev Andy Herrick :
> 
> Although we plan to remove the mac-app-store intaller type for the first 
> release (which will fix this instance the problem for now) I agree this is 
> not right for an exception in one install type to prevent the other types (if 
> there are any) from running.
> 
> I think instead though we should try to run them all, then log what succeeded 
> and then throw the exception if any failed.
> 
> /Andy
> 
> 
> 
> On 3/11/2019 7:55 AM, Lennart Börjeson wrote:
>> Looking into the code of Arguments.generateBundle(Map params), I believe 
>> it's a bug to immediately throw an error when a bundler has configuration 
>> problems.
>> 
>> Instead, that bundler should be removed from the platformBundlers List. 
>> Quick-and-dirty solution:
>> 
>> 
>> diff -r e11f3bf34083 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
>> --- a/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
>>Fri Mar 01 08:27:51 2019 -0500
>> +++ b/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
>>Mon Mar 11 12:37:43 2019 +0100
>> @@ -37,6 +37,7 @@
>>  import java.util.HashMap;
>>  import java.util.HashSet;
>>  import java.util.List;
>> +import java.util.ListIterator;
>>  import java.util.Map;
>>  import java.util.Set;
>>  import java.util.Properties;
>> @@ -655,7 +656,10 @@
>>  // clean these extra (and unneeded) temp directories.
>>  StandardBundlerParam.BUILD_ROOT.fetchFrom(params);
>>  -for (jdk.jpackage.internal.Bundler bundler : 
>> getPlatformBundlers()) {
>> +List platformBundlers = 
>> getPlatformBundlers();
>> +ListIterator platformBundleIterator 
>> = platformBundlers.listIterator();
>> +while (platformBundleIterator.hasNext()) {
>> +jdk.jpackage.internal.Bundler bundler = 
>> platformBundleIterator.next();
>>  Map localParams = new HashMap<>(params);
>>  try {
>>  if (bundler.validate(localParams)) {
>> @@ -677,18 +681,20 @@
>>  } catch (ConfigException e) {
>>  Log.debug(e);
>>  if (e.getAdvice() != null) {
>> -throw new PackagerException(e,
>> +Log.info(new PackagerException(e,
>>  "MSG_BundlerConfigException",
>> -bundler.getName(), e.getMessage(), 
>> e.getAdvice());
>> +bundler.getName(), e.getMessage(), 
>> e.getAdvice()).getMessage());
>>  } else {
>> -throw new PackagerException(e,
>> +Log.info(new PackagerException(e,
>> "MSG_BundlerConfigExceptionNoAdvice",
>> -bundler.getName(), e.getMessage());
>> +bundler.getName(), 
>> e.getMessage()).getMessage());
>>  }
>> +platformBundleIterator.remove();
>>  } catch (RuntimeException re) {
>>  Log.debug(re);
>> -throw new PackagerException(re, 
>> "MSG_BundlerRuntimeException",
>> -bundler.getName(), re.toString());
>> +Log.info(new PackagerException(re, 
>> "MSG_BundlerRuntimeException",
>> +bundler.getName(), re.toString()).getMessage());
>> +platformBundleIterator.remove();
>>  } finally {
>>  if (userProvidedBuildRoot) {
>>  Log.verbose(MessageFormat.format(
>> 
>> 
>> Best regards,
>> 
>> /Lennart Börjeson
>> 
>>> 11 mars 2019 kl. 09:40 skrev Lennart Börjeson :
>>> 
>>> I'm experimenting with jpackage from the current EA available at 
>>> https://jdk.java.net/jpackage/  
>>> >, for the 
>>> moment on Mac only.
>>> 
>>> I have an existing application which I have previously deployed on multiple 
>>> platforms using the then bundled javafxpackager.
>>> 
>>> With the current EA (build 17), I find I must specify the --installer-type 
>>> parameter, otherwise I get the following error:
>>> 
>>> $ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage 
>>> create-installer --overwrite --output 
>>> /Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui --app-image 
>>> /Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app
>>>  --icon BMF.icns --identifier com.cinnober.bmf.gui.Main --app-version 
>>> 1.6.10 --verbose
>>> jdk.jpackage.internal.PackagerException: Bundler Mac App Store Ready 
>>> Bundler skipped because of a configuration problem: Mac App Store apps must 
>>> be signed, and signing has been disabled by bundler configurati

Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Peter Levart]

Hi,

On 3/11/19 5:29 PM, Joe Darcy wrote:

Hello,

Always surprising how much discussion an (apparently) simple 
refactoring can generate!


Thanks to Tagir for spotting this issue.

For completeness, the two-argument forms of requireNonNull which takes 
a Supplier is not applicable to preserve the message behavior 
since the loop counter i is not final or effectively final:


    Objects.requireNonNull(defensiveCopy[i],  () -> "stackTrace[" + i 
+ "]");


...and even if it were effectively final, the use of that method would 
not help in preventing the construction of garbage. It would just 
replace one type of garbage (StringBuilder(s) and concatenated 
String(s)) with another type (capturing lambda instances).


So this is best left as is.

+1

Peter



Therefore, I'll revert this use of requireNonNull in Throwable but 
keep the other three:


diff -r 289fd6cb7480 src/java.base/share/classes/java/lang/Throwable.java
--- a/src/java.base/share/classes/java/lang/Throwable.java    Mon Mar 
11 15:34:16 2019 +0100
+++ b/src/java.base/share/classes/java/lang/Throwable.java    Mon Mar 
11 09:28:51 2019 -0700

@@ -914,8 +914,7 @@
 for (Throwable t : suppressedExceptions) {
 // Enforce constraints on suppressed exceptions in
 // case of corrupt or malicious stream.
-    if (t == null)
-    throw new 
NullPointerException(NULL_CAUSE_MESSAGE);

+    Objects.requireNonNull(t, NULL_CAUSE_MESSAGE);
 if (t == this)
 throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);

 suppressed.add(t);
@@ -942,8 +941,7 @@
 stackTrace = null;
 } else { // Verify stack trace elements are non-null.
 for(StackTraceElement ste : stackTrace) {
-    if (ste == null)
-    throw new NullPointerException("null 
StackTraceElement in serial stream. ");
+    Objects.requireNonNull(ste, "null 
StackTraceElement in serial stream.");

 }
 }
 } else {
@@ -1034,8 +1032,7 @@
 if (exception == this)
 throw new 
IllegalArgumentException(SELF_SUPPRESSION_MESSAGE, exception);


-    if (exception == null)
-    throw new NullPointerException(NULL_CAUSE_MESSAGE);
+    Objects.requireNonNull(exception, NULL_CAUSE_MESSAGE);

 if (suppressedExceptions == null) // Suppressed exceptions 
not recorded

 return;

Thanks,

-Joe

On 3/10/2019 4:21 AM, Remi Forax wrote:

- Mail original -

De: "Martin Buchholz" 
À: "Tagir Valeev" 
Cc: "core-libs-dev" 
Envoyé: Vendredi 8 Mars 2019 21:35:59
Objet: Re: JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable 
to use Objects.requireNonNull

On Fri, Mar 8, 2019 at 3:57 AM Tagir Valeev  wrote:


Hello!

diff -r 274361bd6915 
src/java.base/share/classes/java/lang/Throwable.java

--- a/src/java.base/share/classes/java/lang/Throwable.java Thu Mar 07
10:22:19 2019 +0100
+++ b/src/java.base/share/classes/java/lang/Throwable.java Fri Mar 08
02:06:42 2019 -0800
@@ -874,8 +874,7 @@
   // Validate argument
   StackTraceElement[] defensiveCopy = stackTrace.clone();
   for (int i = 0; i < defensiveCopy.length; i++) {
-    if (defensiveCopy[i] == null)
-    throw new NullPointerException("stackTrace[" + i 
+ "]");
+    Objects.requireNonNull(defensiveCopy[i], 
"stackTrace[" + i

+ "]");

Won't it produce unnecessary garbage due to string concatenation on
the common case when all frames are non-null?

I share Tagir's doubts.  I avoid this construction in performance 
sensitive

code.
Java doesn't offer syntactic abstraction (can I haz macros?) so the 
Java

Way is to write the explicit if.

Logging frameworks have the same trouble.
https://github.com/google/flogger


No, they don't if the API use the pattern described by Peter
https://github.com/forax/beautiful_logger

Perhaps hotspot's improved automatic NPE reporting makes the message 
detail

here obsolete?
anyway, i agree with what's Martin and Tagir said, requireNonNull() 
should not be used in this particular case.


Rémi

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Peter Levart]

Hi John,

On 3/12/19 12:07 AM, John Rose wrote:

public static void main(String[] args) {
  for(int i : range(0, 100)) {
System.out.println(i);
  }
}

It correctly compiles and prints numbers from 0 to 99. As IntStream
extends BaseStream and BaseStream> defines Iterator iterator(), it would be no
problem with using IntStream.range in such code pattern were
BaseStream extends IterableOnce.

Of course this produces unnecessary garbage, as I said.

This is a relatively simple kind of garbage to remove, because
it is made (by calls to Integer.valueOf) at the adapted boundaries
of the iterator, which are readily inlined into the loop.  The deeper
internal logic of the range function is box-free, as is the loop itself,
so the garbage is relatively easy to remove.

That said, "out of the box" there is lots of garbage created unless
-XX:+AggressiveUnboxing is turned on.  I assume Graal does a good
job on it, even without this switch.

If we ever succeed in suppressing the identity of java.lang.Integer,
and/or after making functions like range into reified generics, the
boxing will go away even more directly and simply.

So, from the JIT engineering point of view, I would classify this
particular boxing problem as relatively short-lived.

— John


What I have observed (some time ago) is that Integer instances obtained 
by Integer.valueOf() are never found to "not escape" the JIT compilation 
unit and are therefore never scalarized by JIT because of the "feature" 
that was designed to actually prevent the continuous allocation of some 
"values" of Integer(s) - namely the caching of Integer instances in the 
Integer.IntegerCache.cache array for values in range [-128, 127]. So the 
feature designed to prevent continuous allocation is actually working 
against the desired goal. The code of Integer.valueOf is:


    public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
    return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
    }

...so JIT would have to create two specializations of code: one for 
cached Integer instances which are always real objects and the other for 
scalarized Integer(s) created by constructor. Last time I experimented 
with this was in JDK 8. Is HotSpot in JDK 12+ smarter now and can do 
this? Perhaps the @HotSpotIntrinsicCandidate annotation on this method 
is a clue that it is treated in a special way by the JIT?



Regards, Peter

(trivial doc fix) RFR: 8220262: fix headings in java.logging

[Daniel Fuchs]

Hi,

Please find below a trivial doc fix for:

8220262: fix headings in java.logging
https://bugs.openjdk.java.net/browse/JDK-8220262

The change is just:
- * LogManager Configuration
+ * LogManager Configuration

full patch below.

best regards,

-- daniel

=
diff --git 
a/src/java.logging/share/classes/java/util/logging/LogManager.java 
b/src/java.logging/share/classes/java/util/logging/LogManager.java

--- a/src/java.logging/share/classes/java/util/logging/LogManager.java
+++ b/src/java.logging/share/classes/java/util/logging/LogManager.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -64,7 +64,7 @@
  * At startup the LogManager class is located using the
  * java.util.logging.manager system property.
  *
- * LogManager Configuration
+ * LogManager Configuration
  *
  * A LogManager initializes the logging configuration via
  * the {@link #readConfiguration()} method during LogManager 
initialization.

=

Re: (trivial doc fix) RFR: 8220262: fix headings in java.logging

[Lance Andersen]

+1

--

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Sent from my iPhone

> On Mar 12, 2019, at 8:06 AM, Daniel Fuchs  wrote:
> 
> Hi,
> 
> Please find below a trivial doc fix for:
> 
> 8220262: fix headings in java.logging
> https://bugs.openjdk.java.net/browse/JDK-8220262
> 
> The change is just:
> - * LogManager Configuration
> + * LogManager Configuration
> 
> full patch below.
> 
> best regards,
> 
> -- daniel
> 
> =
> diff --git a/src/java.logging/share/classes/java/util/logging/LogManager.java 
> b/src/java.logging/share/classes/java/util/logging/LogManager.java
> --- a/src/java.logging/share/classes/java/util/logging/LogManager.java
> +++ b/src/java.logging/share/classes/java/util/logging/LogManager.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
> reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -64,7 +64,7 @@
>  * At startup the LogManager class is located using the
>  * java.util.logging.manager system property.
>  *
> - * LogManager Configuration
> + * LogManager Configuration
>  *
>  * A LogManager initializes the logging configuration via
>  * the {@link #readConfiguration()} method during LogManager initialization.
> =

Re: (trivial doc fix) RFR: 8220262: fix headings in java.logging

[Gary Adams]

Doesn't the generated javadoc include an h2 for Class LogManager?

That would make the h3 for LogManager Configuration the correct nesting 
level,

even though it does not appear in the individual source file.

On 3/12/19, 8:06 AM, Daniel Fuchs wrote:

Hi,

Please find below a trivial doc fix for:

8220262: fix headings in java.logging
https://bugs.openjdk.java.net/browse/JDK-8220262

The change is just:
- * LogManager Configuration
+ * LogManager Configuration

full patch below.

best regards,

-- daniel

=
diff --git 
a/src/java.logging/share/classes/java/util/logging/LogManager.java 
b/src/java.logging/share/classes/java/util/logging/LogManager.java

--- a/src/java.logging/share/classes/java/util/logging/LogManager.java
+++ b/src/java.logging/share/classes/java/util/logging/LogManager.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights 
reserved.

  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -64,7 +64,7 @@
  * At startup the LogManager class is located using the
  * java.util.logging.manager system property.
  *
- * LogManager Configuration
+ * LogManager Configuration
  *
  * A LogManager initializes the logging configuration via
  * the {@link #readConfiguration()} method during LogManager 
initialization.

=

Re: (trivial doc fix) RFR: 8220262: fix headings in java.logging

[Daniel Fuchs]

Hi Gary,

On 12/03/2019 12:16, Gary Adams wrote:

Doesn't the generated javadoc include an h2 for Class LogManager?

That would make the h3 for LogManager Configuration the correct nesting 
level,

even though it does not appear in the individual source file.


No, it used to, but now it doesn't. See
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html

The previous header tag is now an  for the class declaration.

best regards,

-- daniel

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Remi Forax]

- Mail original -
> De: "Peter Levart" 
> À: "John Rose" , "Tagir Valeev" 
> Cc: "core-libs-dev" 
> Envoyé: Mardi 12 Mars 2019 11:29:22
> Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

> Hi John,
> 
> On 3/12/19 12:07 AM, John Rose wrote:
>>> public static void main(String[] args) {
>>>   for(int i : range(0, 100)) {
>>> System.out.println(i);
>>>   }
>>> }
>>>
>>> It correctly compiles and prints numbers from 0 to 99. As IntStream
>>> extends BaseStream and BaseStream>> BaseStream> defines Iterator iterator(), it would be no
>>> problem with using IntStream.range in such code pattern were
>>> BaseStream extends IterableOnce.
>>>
>>> Of course this produces unnecessary garbage, as I said.
>> This is a relatively simple kind of garbage to remove, because
>> it is made (by calls to Integer.valueOf) at the adapted boundaries
>> of the iterator, which are readily inlined into the loop.  The deeper
>> internal logic of the range function is box-free, as is the loop itself,
>> so the garbage is relatively easy to remove.
>>
>> That said, "out of the box" there is lots of garbage created unless
>> -XX:+AggressiveUnboxing is turned on.  I assume Graal does a good
>> job on it, even without this switch.
>>
>> If we ever succeed in suppressing the identity of java.lang.Integer,
>> and/or after making functions like range into reified generics, the
>> boxing will go away even more directly and simply.
>>
>> So, from the JIT engineering point of view, I would classify this
>> particular boxing problem as relatively short-lived.
>>
>> — John
> 
> What I have observed (some time ago) is that Integer instances obtained
> by Integer.valueOf() are never found to "not escape" the JIT compilation
> unit and are therefore never scalarized by JIT because of the "feature"
> that was designed to actually prevent the continuous allocation of some
> "values" of Integer(s) - namely the caching of Integer instances in the
> Integer.IntegerCache.cache array for values in range [-128, 127]. So the
> feature designed to prevent continuous allocation is actually working
> against the desired goal. The code of Integer.valueOf is:
> 
>     public static Integer valueOf(int i) {
>     if (i >= IntegerCache.low && i <= IntegerCache.high)
>     return IntegerCache.cache[i + (-IntegerCache.low)];
>     return new Integer(i);
>     }
> 
> ...so JIT would have to create two specializations of code: one for
> cached Integer instances which are always real objects and the other for
> scalarized Integer(s) created by constructor. Last time I experimented
> with this was in JDK 8. Is HotSpot in JDK 12+ smarter now and can do
> this? Perhaps the @HotSpotIntrinsicCandidate annotation on this method
> is a clue that it is treated in a special way by the JIT?

this has been fixed very recently
https://bugs.openjdk.java.net/browse/JDK-8075052

> 
> 
> Regards, Peter

regards,
Rémi

Re: jpackage --create-installer problem on Mac when installer-type is unspecified

[Andy Herrick]

Yes  expect the next EA by next week.

/Andy


On 3/12/2019 3:40 AM, Lennart Börjeson wrote:

OK.

May I hope that a fix for this will make its way to the early-access 
build soon?


(While I can build from source myself, it is much more convenient to 
use an EA in our CI cluster.)


/Lennart

11 mars 2019 kl. 18:04 skrev Andy Herrick >:


Although we plan to remove the mac-app-store intaller type for the 
first release (which will fix this instance the problem for now) I 
agree this is not right for an exception in one install type to 
prevent the other types (if there are any) from running.


I think instead though we should try to run them all, then log what 
succeeded and then throw the exception if any failed.


/Andy



On 3/11/2019 7:55 AM, Lennart Börjeson wrote:
Looking into the code of Arguments.generateBundle(Map params), I 
believe it's a bug to immediately throw an error when a bundler has 
configuration problems.


Instead, that bundler should be removed from the platformBundlers 
List. Quick-and-dirty solution:



diff -r e11f3bf34083 
src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
--- 
a/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java 
  Fri Mar 01 08:27:51 2019 -0500
+++ 
b/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java 
  Mon Mar 11 12:37:43 2019 +0100

@@ -37,6 +37,7 @@
 import java.util.HashMap;
 import java.util.HashSet;
 import java.util.List;
+import java.util.ListIterator;
 import java.util.Map;
 import java.util.Set;
 import java.util.Properties;
@@ -655,7 +656,10 @@
 // clean these extra (and unneeded) temp directories.
 StandardBundlerParam.BUILD_ROOT.fetchFrom(params);
 -    for (jdk.jpackage.internal.Bundler bundler : 
getPlatformBundlers()) {
+    List platformBundlers = 
getPlatformBundlers();
+    ListIterator 
platformBundleIterator = platformBundlers.listIterator();

+    while (platformBundleIterator.hasNext()) {
+    jdk.jpackage.internal.Bundler bundler = 
platformBundleIterator.next();
 Map localParams = new 
HashMap<>(params);

 try {
 if (bundler.validate(localParams)) {
@@ -677,18 +681,20 @@
 } catch (ConfigException e) {
 Log.debug(e);
 if (e.getAdvice() != null) {
-    throw new PackagerException(e,
+ Log.info (new PackagerException(e,
 "MSG_BundlerConfigException",
-    bundler.getName(), e.getMessage(), 
e.getAdvice());
+    bundler.getName(), e.getMessage(), 
e.getAdvice()).getMessage());

 } else {
-    throw new PackagerException(e,
+ Log.info (new PackagerException(e,
"MSG_BundlerConfigExceptionNoAdvice",
-    bundler.getName(), e.getMessage());
+    bundler.getName(), 
e.getMessage()).getMessage());

 }
+    platformBundleIterator.remove();
 } catch (RuntimeException re) {
 Log.debug(re);
-    throw new PackagerException(re, 
"MSG_BundlerRuntimeException",

-    bundler.getName(), re.toString());
+ Log.info (new PackagerException(re, 
"MSG_BundlerRuntimeException",
+    bundler.getName(), 
re.toString()).getMessage());

+    platformBundleIterator.remove();
 } finally {
 if (userProvidedBuildRoot) {
 Log.verbose(MessageFormat.format(


Best regards,

/Lennart Börjeson

11 mars 2019 kl. 09:40 skrev Lennart Börjeson >:


I'm experimenting with jpackage from the current EA available 
athttps://jdk.java.net/jpackage/, 
for the moment on Mac only.


I have an existing application which I have previously deployed on 
multiple platforms using the then bundled javafxpackager.


With the current EA (build 17), I find I must specify the 
--installer-type parameter, otherwise I get the following error:


$ /Users/lennartb/Downloads/jdk-13.jdk/Contents/Home/bin/jpackage 
create-installer --overwrite --output 
/Users/lennartb/RaT/git/BMF/GUI/build/jpackage --name bmfgui 
--app-image 
/Users/lennartb/RaT/git/BMF/GUI/build/jpackage/BMFGraphicalUserInterface.app 
--icon BMF.icns --identifier com.cinnober.bmf.gui.Main 
--app-version 1.6.10 --verbose
jdk.jpackage.internal.PackagerException: Bundler Mac App Store 
Ready Bundler skipped because of a configuration problem: Mac App 
Store apps must be signed, and signing has been disabled by bundler 
configuration.

Advice to fix: Either unset 'signBundle' or set 'signBundle' to true.
at 
jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:726)
at 
jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argum

Re: JDK 12's String::transform vs F#'s |> operator

[Brian Goetz]

On 3/8/2019 3:47 PM, Lukas Eder wrote:

Hello,

I've recently learned about JDK 12's new String::transform method:
https://bugs.openjdk.java.net/browse/JDK-8203703

Obviously, this is useful. And obviously, this would be far more useful as
a general pattern than just something for String. E.g. why not also for any
Number subtype. For Boolean. For java.time types. Etc.


Yes, that's the plan -- to add this method more widely.

Yes, we could go bigger, and add the |> operator, but that's not in the 
current plan.

RFR [doc] 8220237: ProcessBuilder API documentation typo

[Roger Riggs]

Please review a doc fix to refer to the correct method reading from the 
process.


diff --git a/src/java.base/share/classes/java/lang/ProcessBuilder.java 
b/src/java.base/share/classes/java/lang/ProcessBuilder.java

--- a/src/java.base/share/classes/java/lang/ProcessBuilder.java
+++ b/src/java.base/share/classes/java/lang/ProcessBuilder.java
@@ -89,7 +89,7 @@ import sun.security.action.GetPropertyAc
  * a destination for standard output
  * and standard error.  By default, the subprocess writes 
standard

  * output and standard error to pipes.  Java code can access these pipes
- * via the input streams returned by {@link Process#getOutputStream()} and
+ * via the input streams returned by {@link Process#getInputStream()} and
  * {@link Process#getErrorStream()}.  However, standard output and
  * standard error may be redirected to other destinations using
  * {@link #redirectOutput(Redirect) redirectOutput} and

Issue: https://bugs.openjdk.java.net/browse/JDK-8220237

Thanks, Roger

RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

[Lindenmaier, Goetz]

Hi Peter, 

>    56 private static final String MESSAGE_PLACEHOLDER =
> "NPE_MESSAGE_PLACEHOLDER";
> Here, the initializer of that constant should create a private instance
> of String:
... 
>      private static final String MESSAGE_PLACEHOLDER = new String();
Ok, I understand.

>    81 public String getMessage() {
>    82 String message = super.getMessage();
>    83 if (message == MESSAGE_PLACEHOLDER) {
>    84 message = getExtendedNPEMessage();
>    85 setMessage(message);
>    86 }
>    87 return super.getMessage();
>    88 }
> 
> Why not simply returning 'message' local variable here?
As I removed the synchronization, this would reduce the chance to 
get different objects in case of a race.  Highly unlikely though.

I changed the webrev with this solution to include these your remarks:
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03-PeterLevart/
(updated in-place).

Nevertheless, I think I will follow Roger's demand to not modify the 
defaultMessage
field.

Best regards,
  Goetz.


> 
> 
> Regards, Peter
> 
> On 2/14/19 5:35 PM, Lindenmaier, Goetz wrote:
> > Hi Roger,
> >
> >> Maybe 10 years ago, when native was the only solution.
> >> Now there are tools to analyze bytecode in java.
> > I'm working on a Java implementation.
> >
> >>> Peter Levart proposed to initialize the message with a sentinel instead.
> >>> I'll implement this as a proposal.
> >> That's an extra overhead too, any assignment is.
> > Yes, any code requires some run time. But I think this really is negligible
> > in comparison to generating the backtrace, which happens on every
> > exception.  But I'm fine with the 'always recompute, no serialization'
> > solution. If it turns out to be limited, it still can be changed easily.
> >
> >>> I guess we can go without.
> >>> It would be possible to construct a case where two threads
> >>> do getMessage() on the same NPE Object but the string is not
> >>> the same.
> >> Really!, if the bci is the same, the bytecode is the same, what could be
> different
> >> that would change the data used to create the exception?
> > e.getMessage().equals(e.getMessage()) will hold, but
> > e.getMessage() != e.getMessage().
> >
> > I just implemented the two variants of computing the message, they
> > basically differ in NullPointerException.java:
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/03-
> PeterLevart/
> > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/04-
> RogerRiggs/
> >
> > I also cleaned up the parameters passed as proposed.
> >
> >>> We uses this code since 2006, it needed only few changes.  I would like to
> >>> contribute a follow up for hidden frames of lambdas.
> >> Valhalla and evolution of the byte code needs to be considered.
> >> Just because its worked for years does not mean it's the best approach
> >> today.  Dropping it in now means maintaining it in its current form
> >> or needing to re-write it later.
> > Well, yes, that is true. For any change.  For any project.  We have heard
> > this argument for many of our changes. I don't really think it's a good
> > argument. As I understand Valhalla is not targeted for jdk13, and
> > holding up changes for some future projects not really is the process
> > of OpenJDK, is it?
> >
>  The change to the jtreg/vmTestbase/jit/t/t104/t104.gold file raises a
>  question
>  about how useful the information is,  developers should not need to know
>  about "slot 1".
> >>> Developers should work with class files with debug information and then
> >>> they would get the name printed. If exceptions are thrown in production
> >>> code, any information is helpful.  Should I just write "a local"?
> >> Go back to who you think is going to benefit from it, it seems targeted
> >> at a fairly novice developer, so exposing low level details may be more
> >> confusing that just giving a line number and NPE.
> > Especially on our improved NPE messages we always got good feedback
> > from the developers within SAP. And there are quite some experienced
> > people.  Any message requires some background to be helpful.  And I
> > like to get any information I can have in first place. Attaching the
> > debugger often is a big overhead. E.g., I look at about 50 failing jtreg
> > tests every day, I don't want to get each into the debugger every time
> > in the setup where it was running to see what is wrong ...
> >
> > E.g., com/sun/java/swing/plaf/windows/AltFocusIssueTest.java
> > is failing in a headless environment with an NPE on this line:
> >  SwingUtilities.invokeAndWait(() -> frame.dispose());
> > With this change it said "while trying to invoke the method
> javax.swing.JFrame.dispose(()V) of a null object loaded from static field
> AltFocusIssueTest.frame" and I figured it's the fact we run headless that
> > makes the test fail without even looking at the code.
> >
> > Best regards,
> >Goetz
> >
> >
> >
> >
> >
> >
> >
> >
> > From:

Re: RFR [doc] 8220237: ProcessBuilder API documentation typo

[Daniel Fuchs]

Looks good to me Roger.

It's kind of unfortunate that the process output
is returned by a method named getInputStream(),
even though I understand that's a mirror effect...

best regards,

-- daniel

On 12/03/2019 15:32, Roger Riggs wrote:
Please review a doc fix to refer to the correct method reading from the 
process.


diff --git a/src/java.base/share/classes/java/lang/ProcessBuilder.java 
b/src/java.base/share/classes/java/lang/ProcessBuilder.java

--- a/src/java.base/share/classes/java/lang/ProcessBuilder.java
+++ b/src/java.base/share/classes/java/lang/ProcessBuilder.java
@@ -89,7 +89,7 @@ import sun.security.action.GetPropertyAc
   * a destination for standard output
   * and standard error.  By default, the subprocess writes 
standard

   * output and standard error to pipes.  Java code can access these pipes
- * via the input streams returned by {@link Process#getOutputStream()} and
+ * via the input streams returned by {@link Process#getInputStream()} and
   * {@link Process#getErrorStream()}.  However, standard output and
   * standard error may be redirected to other destinations using
   * {@link #redirectOutput(Redirect) redirectOutput} and

Issue: https://bugs.openjdk.java.net/browse/JDK-8220237

Thanks, Roger

RFR: 8219197: ThreadGroup.enumerate() may return wrong value

[Daniel Fuchs]

Hi,

Please find below a simple fix for
8219197: ThreadGroup.enumerate() may return wrong value

http://cr.openjdk.java.net/~dfuchs/webrev_8219197/webrev.00/

This is a bug in the implementation of the recursion,
as enumerate(list, n, recurse) should never have returned
a value < n.

The test passes with the fix and fails 'often enough' without
it (~ 1 times out of 2 or 3).

best regards,

-- daniel

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Brian Goetz]

No.  You have the LSP backwards (though this is easy to do.)

IterableOnce means "*must throw* on subsequent use"; under this spec, an 
arbitrary Iterable is most certainly *not* an IterableOnce, and 
therefore an LSP violation.


It sounds like you are suggesting that we instead spec 
IterableAtLeastOnce, of which Iterable *would* be a credible subtype -- 
but due to how Iterable is specified now, the problem is that Iterable 
*already is* really "iterable at least once."  So there would be no 
point in introducing this type; we already have it.


If we were doing this from scratch, we might choose a different path, 
but that option is not open to us.  As several have already noted, this 
proposal is not ideal, but due to the corner we're painted into by 
Iterable's current spec, there is not going to be an ideal outcome -- 
and the current strategy (do nothing) is also not ideal and makes many 
people unhappy.  So the game here is finding the least-bad solution that 
is compatible with the constraints we have, which I think Stuart has 
done exactly. (Also, he did a very nice job of writing up all the 
alternatives, to avoid (or at least reduce) the torrent of "have you 
thought about ".)


On 3/6/2019 10:50 AM, Peter Levart wrote:


In this respect Iterable should be a subtype of IterableOnce and 
foreach loop should be retrofitted to work with IterableOnce.

RFR: 8220505: Allow building available installers when --installer-type not specified

[Andy Herrick]

Please review the jpackage fix for bug [1] at [2].


This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8220505

[2] http://cr.openjdk.java.net/~herrick/8220505/

/Andy

Re: RFR [doc] 8220237: ProcessBuilder API documentation typo

[Roger Riggs]

Thanks Daniel,

yes, the method naming ship has sailed.


On 03/12/2019 11:44 AM, Daniel Fuchs wrote:

Looks good to me Roger.

It's kind of unfortunate that the process output
is returned by a method named getInputStream(),
even though I understand that's a mirror effect...

best regards,

-- daniel

On 12/03/2019 15:32, Roger Riggs wrote:
Please review a doc fix to refer to the correct method reading from 
the process.


diff --git 
a/src/java.base/share/classes/java/lang/ProcessBuilder.java 
b/src/java.base/share/classes/java/lang/ProcessBuilder.java

--- a/src/java.base/share/classes/java/lang/ProcessBuilder.java
+++ b/src/java.base/share/classes/java/lang/ProcessBuilder.java
@@ -89,7 +89,7 @@ import sun.security.action.GetPropertyAc
   * a destination for standard 
output
   * and standard error.  By default, the subprocess 
writes standard
   * output and standard error to pipes.  Java code can access these 
pipes
- * via the input streams returned by {@link 
Process#getOutputStream()} and
+ * via the input streams returned by {@link 
Process#getInputStream()} and

   * {@link Process#getErrorStream()}.  However, standard output and
   * standard error may be redirected to other destinations using
   * {@link #redirectOutput(Redirect) redirectOutput} and

Issue: https://bugs.openjdk.java.net/browse/JDK-8220237

Thanks, Roger

RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out

[Lance Andersen]

Hi all,

Please review this addition to the ProblemList.txt  as this tests times out 
from time to time


$ hg diff test/jdk/ProblemList.txt 
diff -r 687e10fefa11 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt  Mon Mar 11 13:37:56 2019 -0400
+++ b/test/jdk/ProblemList.txt  Tue Mar 12 13:27:35 2019 -0400
@@ -840,6 +840,8 @@
 
 # jdk_util
 
+java/util/Arrays/TimSortStackSize2.java 8220005 
generic-all
+
 
 
 # jdk_instrument
$



 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Peter Levart]

On 3/12/19 5:04 PM, Brian Goetz wrote:

No. You have the LSP backwards (though this is easy to do.)

IterableOnce means "*must throw* on subsequent use"; under this spec, 
an arbitrary Iterable is most certainly *not* an IterableOnce, and 
therefore an LSP violation.


It sounds like you are suggesting that we instead spec 
IterableAtLeastOnce, of which Iterable *would* be a credible subtype 
-- but due to how Iterable is specified now, the problem is that 
Iterable *already is* really "iterable at least once."  So there would 
be no point in introducing this type; we already have it.


Due to how Iterable is specified now it does not promise multiple 
iterations, but due to how most (all that I know of except 
DirectoryStream or some 3rd party) Iterables are implemented now, the 
common expectation is that it does. By implementing more Iterable(s) 
that don't support multiple iteration (regardless of whether they 
implement this new sub-type or not), this expectation will be less and 
less honored. Perhaps this is not so bad. At various occasions the 
specification has been changed to accommodate the long-standing behavior 
or expectation of behavior, but this seems not to be one of them.


Let's pretend for a moment that Iterable specification was changed to 
guarantee multi-pass iteration. In that case the IterableAtLeastOnce as 
a supertype of multi-pass Iterable would make much more sense, wouldn't it?


But as there could be Iterables out there that by current spec are 
perfectly valid and don't support multi-pass iteration, such spec change 
would make them non-conformant and is therefore not allowed. So I'm 
convinced now that this is the least-bad solution.


Regards, Peter




If we were doing this from scratch, we might choose a different path, 
but that option is not open to us.  As several have already noted, 
this proposal is not ideal, but due to the corner we're painted into 
by Iterable's current spec, there is not going to be an ideal outcome 
-- and the current strategy (do nothing) is also not ideal and makes 
many people unhappy.  So the game here is finding the least-bad 
solution that is compatible with the constraints we have, which I 
think Stuart has done exactly. (Also, he did a very nice job of 
writing up all the alternatives, to avoid (or at least reduce) the 
torrent of "have you thought about extensively>".)


On 3/6/2019 10:50 AM, Peter Levart wrote:


In this respect Iterable should be a subtype of IterableOnce and 
foreach loop should be retrofitted to work with IterableOnce.

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Brian Goetz]

Due to how Iterable is specified now it does not promise multiple 
iterations, but due to how most (all that I know of except 
DirectoryStream or some 3rd party) Iterables are implemented now, the 
common expectation is that it does. By implementing more Iterable(s) 
that don't support multiple iteration (regardless of whether they 
implement this new sub-type or not), this expectation will be less and 
less honored. Perhaps this is not so bad. At various occasions the 
specification has been changed to accommodate the long-standing 
behavior or expectation of behavior, but this seems not to be one of 
them.


Correct.  But, with separate Iterable and IterableOnce, the spec for 
Iterable can say "If you don't support multiple iteration, you should 
implement IO."  Which is OK, because at least those classes are being 
explicit.


Let's pretend for a moment that Iterable specification was changed to 
guarantee multi-pass iteration. In that case the IterableAtLeastOnce 
as a supertype of multi-pass Iterable would make much more sense, 
wouldn't it?


Then we couldn't use Stream in foreach without a language change, which 
is the whole point of this exercise.

Re: RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out

[Brent Christian]

+1

-Brent

On 3/12/19 10:30 AM, Lance Andersen wrote:

Hi all,

Please review this addition to the ProblemList.txt  as this tests times out 
from time to time


$ hg diff test/jdk/ProblemList.txt
diff -r 687e10fefa11 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt  Mon Mar 11 13:37:56 2019 -0400
+++ b/test/jdk/ProblemList.txt  Tue Mar 12 13:27:35 2019 -0400
@@ -840,6 +840,8 @@
  
  # jdk_util
  
+java/util/Arrays/TimSortStackSize2.java 8220005 generic-all

+
  
  
  # jdk_instrument

$



  
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Stuart Marks]

Hi Remi,


Stream.iterator() can be really really slow, it uses a pull semantics while
the whole Stream push values. When designing it, the lambda EG saw it as an
"escape hatch" in order to interropt with a legacy code than require an
Iterator and not more.


If Stream.iterator() is slow, then perhaps it needs to be optimized. Tagir had 
some ideas for how to do that. Of course, I don't know if that's exactly the 
right way; some additional investigation should be done. But poor performance 
relative to Spliterator.tryAdvance() or forEachRemaining() shouldn't be an 
argument against doing this. People repeatedly bump into the gap in the 
programming model between streams and the enhanced-for loop, and it's time to 
fill it in.



This proposal has the side effect of making Stream more different from its
primitive counterpart IntStream, LongStream and DoubleStream which may be
problematic because we are trying to introduce reified generics as part of
Valhalla (there is a recent mail of Brian about not adding methods to
OptionalInt for the same reason).


Well, yes, I think that it means that Stream evolves somewhat independently of 
Int/Long/DoubleStream, but I don't see that this imposes an impediment on 
generic specialization in Valhalla. In that world, Stream should (mostly) 
just work. It may also be possible in a specialized world to add the specific 
things from IntStream (such as sum() and max()) to Stream.



And, the real issue is how to deal with checked exceptions inside the Stream
API, i would prefer to fix that issue instead of trying to find a way to
workaround it.


Well I'd like to have a solution for checked exceptions as well, but there 
doesn't appear to be one on the horizon. I mean, there are some ideas floating 
around, but nobody is working on them as far as I know.


But checked exceptions aren't the only reason to prefer iteration in some cases; 
loops offer more flexible control flow (break/continue) and easier handling of 
side effects. The Streams+IterableOnce feature benefits these cases as well as 
exception handling.


s'marks

Re: RFR: 8220505: Allow building available installers when --installer-type not specified

[Alexander Matveev]

Hi Andy,

Looks good.

Thanks,
Alexander

On 3/12/2019 9:46 AM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].


This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


[1] https://bugs.openjdk.java.net/browse/JDK-8220505

[2] http://cr.openjdk.java.net/~herrick/8220505/

/Andy

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Stuart Marks]

Hi Stephen,


My slight concern is that the terminal operation is hidden and not
immediately visible, which could be surprising. I do note that streams
throw a clear exception if a terminal operation is called a second
time which mitigates this to some degree.


Yes, this is certainly a possibility.

I'll note that even though my example does it, I think that storing a stream in 
a local variable is a bit of a code smell. It has to be done for 
try-with-resources, but storing the head of a pipeline in a local variable so 
that it can be iterated over does introduce the possibility of accidental reuse.


I suspect that most cases (aside from try-with-resources) will call a method 
returning a fresh Stream that's then iterated over. For example,


for (var x : getSomeStream()) {
   // ...
}

In this case there's no possibility of accidental reuse.


The IterableOnce class-level Javadoc contradicts the method-level
Javadoc. The class-level say "It is recommended that" whereas the
method-level Javadoc mandates.


Oh yes, thanks. I'll fix this to make the behavior mandatory.

s'marks

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Stuart Marks]

Due to how Iterable is specified now it does not promise multiple iterations, 
but due to how most (all that I know of except DirectoryStream or some 3rd 
party) Iterables are implemented now, the common expectation is that it does. 
By implementing more Iterable(s) that don't support multiple iteration 
(regardless of whether they implement this new sub-type or not), this 
expectation will be less and less honored. Perhaps this is not so bad. At 
various occasions the specification has been changed to accommodate the 
long-standing behavior or expectation of behavior, but this seems not to be 
one of them.


Correct.  But, with separate Iterable and IterableOnce, the spec for Iterable 
can say "If you don't support multiple iteration, you should implement IO."  
Which is OK, because at least those classes are being explicit.


Right. This sort of clarification should be done as part of JDK-8186220.

s'marks

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

[Ivan Gerasimov]

Hello!

Just an observation.

If there were two new subtypes of Iterable introduced:  IterableOnce and 
IterableMultipleTimes, then all existing Iterables could be retrofitted 
to implement one of these.


It wouldn't *automatically* solve the problem of 3rd party API, which 
accepts an Iterable and iterates it multiple times, but would provide a 
means to change that API in a straightforward way.


Also, the static analysis tools could issue a suggestion for code that 
iterates Iterable more than once to switch to IterableMultipleTimes, so 
that it won't be possible to pass in an IterableOnce.


It would also allow to strengthen the specification for 
IterableMultipleTimes and state that all classes implementing it must 
make it possible to obtain multiple iterators.


With kind regards,
Ivan


On 2/28/19 6:43 PM, Stuart Marks wrote:

Hi all,

Please review and comment on this proposal to allow Stream instances 
to be used in enhanced-for ("for-each") loops.


Abstract

Occasionally it's useful to iterate a Stream using a conventional 
loop. However, the Stream interface doesn't implement Iterable, and 
therefore streams cannot be used with the enhanced-for statement. This 
is a proposal to remedy that situation by introducing a new interface 
IterableOnce that is a subtype of Iterable, and then retrofitting the 
Stream interface to implement it. Other JDK classes will also be 
retrofitted to implement IterableOnce.


Full Proposal:

http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html

Bug report:

https://bugs.openjdk.java.net/browse/JDK-8148917

Webrev:

http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/

Note, this changeset isn't ready to push yet. In particular, it has no 
tests yet. However, the implementation is so simple that I figured I 
should include it. Comments on the specification wording are also 
welcome.


Thanks,

s'marks



--
With kind regards,
Ivan Gerasimov

RFR 8220253: Fix Headings in java.sql.rowset

[Lance Andersen]

Hi all

Please review the fix for 8220253,  to address the javadoc header issues [1] in 
java.sql.rowset

The webrev can be found at: 
http://cr.openjdk.java.net/~lancea/8220253/webrev.00/

Best
Lance

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html
 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR 8220253: Fix Headings in java.sql.rowset

[Joe Darcy]

+1

Cheers,

-Joe

On 3/12/2019 5:01 PM, Lance Andersen wrote:

Hi all

Please review the fix for 8220253,  to address the javadoc header issues [1] in 
java.sql.rowset

The webrev can be found at: 
http://cr.openjdk.java.net/~lancea/8220253/webrev.00/

Best
Lance

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002671.html
  
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR 8220005: java/util/Arrays/TimSortStackSize2.java times out

[David Holmes]

Hi Lance,

On 13/03/2019 3:30 am, Lance Andersen wrote:

Hi all,

Please review this addition to the ProblemList.txt  as this tests times out 
from time to time


$ hg diff test/jdk/ProblemList.txt
diff -r 687e10fefa11 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt  Mon Mar 11 13:37:56 2019 -0400
+++ b/test/jdk/ProblemList.txt  Tue Mar 12 13:27:35 2019 -0400
@@ -840,6 +840,8 @@
  
  # jdk_util
  
+java/util/Arrays/TimSortStackSize2.java 8220005 generic-all


The bug number here is the bug that will be used to fix the test, not 
the bug used to add it to the ProblemList.


Thanks,
David
-


+
  
  
  # jdk_instrument

$



  
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com