Re: Review request JDK-8004729: Parameter Reflection API

[Joe Darcy]

On 1/13/2013 9:30 AM, Eric McCorkle wrote:

On 01/12/13 13:36, Joe Darcy wrote:

Hi Eric,

On 1/11/2013 9:14 PM, Eric McCorkle wrote:

I got halfway through implementing a change that would synthesize
Parameter's for the static links (this for the inner classes), when it
occurred to me: is there really a case for allowing reflection on those
parameters.

Put another way,

public class Foo {
public class Bar {
  int baz(int qux) { }
}
}

Should baz.getParameters() return just qux, or should it expose
Foo.this?  On second thought, I can't think of a good reason why you
*want* to reflect on Foo.this.

You need to reflect on that parameter so you can call the constructor
properly using reflection :-)


Alright, I will make the logic changes and post for review.


Also, the logic is much simpler.  You just have to figure out how deep
you are in inner classes, store that information somewhere, and offset
by that much every time a Parameter calls back to its Executable to get
information.  The logic for synthesizing the this parameters is much
more complex.

Thoughts?

We may need some more help from javac to mark parameters as synthesized
or synthetic, which can be done as follow-up work.  For inner classes
that are members of types, the outer this parameters are required to be
a certain way by the platform specification to make linkage work.
*However*, local and anonymous classes only have to obey a compiler's
contract with itself and are not specified.  In particular, not all such
inner classes constructors even have an outer this parameter.  For
example, with javac the constructor of an anonymous class in a static
initializer will *not* have an other this parameter.


Is there any compelling reason that javac should generate information
about the link parameters?  They don't have a name, and have standard
modifiers (presumably final and synthesized).  It seems to me they ought
to be synthesized by the reflection API.


Not all class files come from Java compilers of course and since core 
reflection implicitly acts on a class file level model rather than a 
source-level model, generally it is preferable (and in keeping with past 
practice) for core reflection to not try to get too clever in inferring 
missing information.


-Joe

Re: --enable-sjavac not enabled in tl repo yet?

[Fredrik Öhrström]

18 jan 2013 kl. 03:07 skrev Weijun Wang:

> Just tried on a latest jdk8/tl clone and
> The makefile listed source 
> /space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java
>  was not calculated by the smart javac 


Ok, as the old saying goes, this works for me :-) So could you please tar 
up your build directory and email it to me?

As for the error message, since the build system has to handle building with 
javac as well as with sjavac, the logic for finding which java
files to compile, is implemented both in make and in java (sjavac). Sjavac has 
the option:
--compare-found-sources file_with_list_of_files
which is used to make sjavac compare its own calculated list of source files 
with the list supplied by make.
If they differ, you will get the error message
> was not calculated by the smart javac 


So why do we need to calculate the files to be compiled? Is it not just
compiling the required source roots? For example like this?

sjavac src/share/classes src/posix/classes src/linux/classes -d bin

Lets say, that we have an opportunity to organize the source in this way.
At the moment for example, when build the OpenJDK the snmp classes have to be 
excluded,
thus the compile command looks more like:
sjavac -x sun.management.snmp.* src/share/classes -d bin

(In make the same calculation is handled by find and grep and sed et al.)

The full filtering rules for compiling the main jdk looks like this:

sjavac -x com.sun.pept.* -x com.sun.tools.example.trace.* -x 
com.sun.tools.example.debug.bdi.* -x com.sun.tools.example.debug.event.* -x 
com.sun.tools.example.debug.gui.* -x sun.dc.* -x com.sun.jmx.snmp.* -x 
sun.management.snmp.* -x com.sun.script.* -x com.oracle.security.* -x 
sun.java2d.cmm.kcms.*  -xf *SolarisAclFileAttributeView.java -xf 
*SolarisFileStore.java -xf *SolarisFileSystem.java -xf 
*SolarisFileSystemProvider.java -xf *SolarisNativeDispatcher.java -xf 
*SolarisUserDefinedFileAttributeView.java -xf *SolarisWatchService.java -xf 
*SolarisAclFileAttributeView.java -xf *SolarisLoginModule.java -xf 
*SolarisSystem.java -xf *sun/nio/ch/DevPollArrayWrapper.java -xf 
*sun/nio/ch/DevPollSelectorImpl.java -xf 
*sun/nio/ch/DevPollSelectorProvider.java -xf 
*sun/nio/ch/EventPortSelectorImpl.java -xf 
*sun/nio/ch/EventPortSelectorProvider.java -xf 
*sun/nio/ch/EventPortWrapper.java -xf 
*sun/nio/ch/SolarisAsynchronousChannelProvider.java -xf 
*sun/nio/ch/SolarisEventPort.java -xf 
*sun/tools/attach/SolarisAttachProvider.java -xf 
*sun/tools/attach/SolarisVirtualMachine.java -xf *WrapperGenerator.java -xf 
*NTLoginModule.java -xf *NTSystem.java -xf 
*sun/nio/ch/BsdAsynchronousChannelProvider.java -xf *sun/nio/ch/KQueue.java -xf 
*sun/nio/ch/KQueuePort.java -xf *sun/nio/fs/BsdFileStore.java -xf 
*sun/nio/fs/BsdFileSystem.java -xf *sun/nio/fs/BsdFileSystemProvider.java -xf 
*sun/nio/fs/BsdNativeDispatcher.java -xf 
*sun/nio/fs/MacOSXFileSystemProvider.java -xf *sun/nio/fs/MacOSXFileSystem.java 
-xf *sun/nio/fs/MacOSXNativeDispatcher.java -xf 
*sun/tools/attach/BsdAttachProvider.java -xf 
*sun/tools/attach/BsdVirtualMachine.java -xf 
*sun/text/resources/BreakIteratorRules.java -xf 
*sun/text/resources/BreakIteratorRules_th.java -xf *sun/awt/AWTCharset.java -xf 
*sun/awt/X11/ScreenFormat.java -xf *sun/awt/X11/XArc.java -xf 
*sun/awt/X11/XChar2b.java -xf *sun/awt/X11/XCharStruct.java -xf 
*sun/awt/X11/XClassHint.java -xf *sun/awt/X11/XComposeStatus.java -xf 
*sun/awt/X11/XExtCodes.java -xf *sun/awt/X11/XFontProp.java -xf 
*sun/awt/X11/XFontSetExtents.java -xf *sun/awt/X11/XFontStruct.java -xf 
*sun/awt/X11/XGCValues.java -xf *sun/awt/X11/XHostAddress.java -xf 
*sun/awt/X11/XIMCallback.java -xf *sun/awt/X11/XIMHotKeyTrigger.java -xf 
*sun/awt/X11/XIMHotKeyTriggers.java -xf 
*sun/awt/X11/XIMPreeditCaretCallbackStruct.java -xf 
*sun/awt/X11/XIMPreeditDrawCallbackStruct.java -xf 
*sun/awt/X11/XIMPreeditStateNotifyCallbackStruct.java -xf 
*sun/awt/X11/XIMStatusDrawCallbackStruct.java -xf 
*sun/awt/X11/XIMStringConversionCallbackStruct.java -xf 
*sun/awt/X11/XIMStringConversionText.java -xf *sun/awt/X11/XIMStyles.java -xf 
*sun/awt/X11/XIMText.java -xf *sun/awt/X11/XIMValuesList.java -xf 
*sun/awt/X11/XImage.java -xf *sun/awt/X11/XKeyboardControl.java -xf 
*sun/awt/X11/XKeyboardState.java -xf *sun/awt/X11/XOMCharSetList.java -xf 
*sun/awt/X11/XOMFontInfo.java -xf *sun/awt/X11/XOMOrientation.java -xf 
*sun/awt/X11/XPoint.java -xf *sun/awt/X11/XRectangle.java -xf 
*sun/awt/X11/XSegment.java -xf *sun/awt/X11/XStandardColormap.java -xf 
*sun/awt/X11/XTextItem.java -xf *sun/awt/X11/XTextItem16.java -xf 
*sun/awt/X11/XTextProperty.java -xf *sun/awt/X11/XTimeCoord.java -xf 
*sun/awt/X11/XWindowChanges.java -xf *sun/awt/X11/XdbeSwapInfo.java -xf 
*sun/awt/X11/XmbTextItem.java -xf *sun/awt/X11/XwcTextItem.java -xf 
*sun/util/locale/AsciiUtil.java -xf *sun/nio/fs/PollingWatchService.java -xf 
*-linux-arm.java -xf *-linux-ppc.java -xf 
*javax/swing/plaf/nimbus/Interna

Re: Codereview request for 8003680: JSR 310: Date/Time API

[Xueming Shen]

Thanks Naoto!

We will see how many we can update tomorrow.

Regarding the Locale.ROOT vs Locale.US, it appears we are now using
Locale.US in j.u.Formatter for l==null case in existing. (Formatter is
earlier than the the 1.6 ROOT). So I may keep the US for now for the
consistency. It may be a good small Locale.US cleanup project later.

-Sherman

On 01/17/2013 03:55 PM, Naoto Sato wrote:

Hi Sherman,

Here are my comments on the 310 changes:


- java/util/Formatter.java

Line 4125: To do a locale neutral case mapping, use Locale.ROOT instead of 
Locale.US.

Line 4161-4169: Remove this as it is commented out. Also "import 
sun.util.locale.provider.TimeZoneNameUtility" is not needed either.

Line 4173, 4183, 4195: The code assumes Locale.US if "l == null." Is this 
correct? Should it be Locale.ROOT?


- java/time/DayOfWeek.java

Line 298-300: Maybe just me, but I thought the convention for "throws" was to consolidate 
conditions into a single "throws" line for the same exception.


- java/time/ZoneOffset.java

Line 214: @SuppressWarnings("fallthrough")?


- java/time/calendar/ChronoDateImpl.java:

In the example in the class description, "%n" should be "\n" for the new lines 
in the printf()s.


- java/time/calendar/HijrahDeviationReader.java

Line 224: Is it OK to catch all Exception here, and pretends as if nothing 
happened?


- java/time/calendar/JapaneseChrono.java

Line 166-172: How come it includes "Keio"? Isn't the era before "Meiji" 
"Seireki"?


- java/time/calendar/MinguoDate.java

Is it OK to NOT serialize "isoDate"? JapaneseDate.java has @serial on this 
field.

- java/time/calendar/ThaiBuddhistDate.java

Same as above MinguoDate.java

- java/time/format/DateTimeBuilder.java

There are several "TODO"s in here.

Line 357: It is commented that return value is for ZoneOffset/ZoneId. But since 
it is public, could this be safe? Can arbitrary app modify it maliciously?


- java/time/format/DateTimeFormatSymbols.java

Line 131: It should use the default locale for formatting, i.e, 
Locale.getDefault(Locale.Category.FORMAT)


- java/time/format/DateTimeFormatter.java

Line 411: DateTimeException needs to be described, as it is thrown in this 
method.

Line 486: The DateTimeException needs to be on @throws clause.


- java/time/format/DateTimeFormatterBuilder

Line 174: The type for "padNextChar" should be "int" to accommodate 
supplementary characters. Not only this particular instance, it looks like there are bunch of 
places that use ++/-- for character iteration. Are they OK?

Line 236: "sensitive" -> "insensitive"

Line 276: "strict" -> "lenient"

Line 1440: use Locale.getDefault(Locale.Category.FORMAT)


- java/time/format/DateTimeFormatters.java

Line 271, 294, 317, 340: Locale.getDefault() -> Locale.getDefault(Locale.Category), "default 
locale" -> "default FORMAT locale"


- java/time/format/DateTimeParseContext.java

Line 194, 195: Should those to[Lower/Upper]Case() take Locale.ROOT as an 
argument? Remember the Turkish 'i' case?


- java/time/overview.html

Should the contents here be moved to package.html? Should we continue to use 
"Threeten" name?


- java/time/temporal/Chrono.java

Line 102: "minguoDate" -> "thaiDate"

Line 212: The comment is kind of cryptic. Looks like not "removing" but 
"registering"


- java/time/zone/TzdbZoneRulesProvider.java

Line 171: Is it OK to catch all exceptions here and ignore?


- sun/tools/tzdb/*

Should the compile be moved under "make" directory, instead of "src"?


Naoto

On 1/15/13 4:13 PM, Xueming Shen wrote:

Hi,

The Threeten project [1] is planned to be integrated into OpenJDK8 M6
milestone.

Here is the webrev
http://cr.openjdk.java.net/~sherman/8003680/webrev

and the latest javadoc
http://cr.openjdk.java.net/~sherman/8003680/javadoc

Review comments can be sent to the threeten-dev email list [2] and/or
core-libs-dev email list[3].

Thanks,
Sherman

[1] http://openjdk.java.net/projects/threeten
[2] threeten-dev @ openjdk.java.net
[3] core-libs-dev @ openjdk.java.net

--enable-sjavac not enabled in tl repo yet?

[Weijun Wang]

Just tried on a latest jdk8/tl clone and

Building Java(TM) for target 'all' in configuration 
'/space/repos/jdk8/tl/build/linux-x86_64-sjavac'


## Starting langtools
Compiling 2 files for BUILD_TOOLS
Compiling 26 properties into resource bundles
Compiling 720 files for BUILD_BOOTSTRAP_LANGTOOLS
Creating langtools/dist/bootstrap/lib/javac.jar
Updating langtools/dist/lib/src.zip
Creating langtools/dist/bootstrap/lib/javah.jar
Creating langtools/dist/bootstrap/lib/javap.jar
Compiling BUILD_FULL_JAVAC
Creating langtools/dist/bootstrap/lib/javadoc.jar
The makefile listed source 
/space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/gensrc/com/sun/tools/doclint/resources/doclint.java 
was not calculated by the smart javac wrapper!
make[1]: *** 
[/space/repos/jdk8/tl/build/linux-x86_64-sjavac/langtools/classes/javac_state] 
Error 255

make[1]: *** Waiting for unfinished jobs
make: *** [langtools-only] Error 2

Thanks
Max

Re: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

[Weijun Wang]

Thanks. Most files end with a new line and having to trim() it before 
decoding would drive me crazy. Also, the old BASE64Decoder ignores it, 
so it would be nice to be compatible.


-Max

On 01/18/2013 01:03 AM, Xueming Shen wrote:

Hi,

Yes,  padding \n (and any non-base64 character) after base64 padding
character
'=' probably should be ignored, instead of exception in mime mode. The
behavior/
implementation is not consistent now for this case. Will file a cr and
address this,
probably after M6.

Thanks!
-Sherman

On 1/17/13 7:02 AM, Mark Sheppard wrote:

Hi Max,

The fact that the padding characters == and = appear before the
newline, leads to RFC2045 section 6.8 (pg 25) and how the
implementation interprets the processing for the pad character in the
encoding.

As per RFC2045 base64 encoding the occurrence of = indicates end of data.
That is to say, == or = is only used in the final unit of encoding
at the very end of the encoded data.
This raises a couple of questions:
So is it an error if there are data after these explicit "end of data"
markers, when they occur?
should a special case be made for line separators?
What about ignoring any data after == or = ?

The javadoc for Base64 Mime Encoder/Decoder alludes to the line
separator and characters
outside the base64 alphabet being ignored during decoding. This in
itself can be ambiguously
interpreted to mean anywhere in the stream, including after an end of
data indicator,
unless specific attention and interpretation is give to RFC2045.

Consider the fact that

Base64.getMimeDecoder().decode("AA==B") also throws an exception
this suggests that the decoder is interpreting data after the
end of data padding indication as an error.

Thus, a newline after = or == is reasonable interpreted as an error,
suggesting
that the exception is reasonable.

It can be noted that Base64.getMimeDecoder().decode("\n")
doesn't throw an exception.

regards
Mark


- Original Message -
From: weijun.w...@oracle.com
To: core-libs-dev@openjdk.java.net
Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain,
Ireland, Portugal
Subject: And Decoder (was Re: No newline at the end of
Base64.getMimeEncoder())

This time on the decoder side:

Base64.getMimeDecoder().decode("AA==\n")

throws an exception because the string ends with a newline. I would
prefer it be acceptable.

Thanks
Max

On 01/17/2013 05:12 PM, Weijun Wang wrote:

I noticed that the encoding output of Base64.getMimeEncoder() never ends
with a newline char. There is no right or wrong on this but it will be
nice to write the current behavior into the spec.

Thanks
Max

Re: Codereview request for 8003680: JSR 310: Date/Time API

[Naoto Sato]

Hi Sherman,

Here are my comments on the 310 changes:


- java/util/Formatter.java

Line 4125: To do a locale neutral case mapping, use Locale.ROOT instead 
of Locale.US.


Line 4161-4169: Remove this as it is commented out. Also "import 
sun.util.locale.provider.TimeZoneNameUtility" is not needed either.


Line 4173, 4183, 4195: The code assumes Locale.US if "l == null." Is 
this correct? Should it be Locale.ROOT?



- java/time/DayOfWeek.java

Line 298-300: Maybe just me, but I thought the convention for "throws" 
was to consolidate conditions into a single "throws" line for the same 
exception.



- java/time/ZoneOffset.java

Line 214: @SuppressWarnings("fallthrough")?


- java/time/calendar/ChronoDateImpl.java:

In the example in the class description, "%n" should be "\n" for the new 
lines in the printf()s.



- java/time/calendar/HijrahDeviationReader.java

Line 224: Is it OK to catch all Exception here, and pretends as if 
nothing happened?



- java/time/calendar/JapaneseChrono.java

Line 166-172: How come it includes "Keio"? Isn't the era before "Meiji" 
"Seireki"?



- java/time/calendar/MinguoDate.java

Is it OK to NOT serialize "isoDate"? JapaneseDate.java has @serial on 
this field.


- java/time/calendar/ThaiBuddhistDate.java

Same as above MinguoDate.java

- java/time/format/DateTimeBuilder.java

There are several "TODO"s in here.

Line 357: It is commented that return value is for ZoneOffset/ZoneId. 
But since it is public, could this be safe? Can arbitrary app modify it 
maliciously?



- java/time/format/DateTimeFormatSymbols.java

Line 131: It should use the default locale for formatting, i.e, 
Locale.getDefault(Locale.Category.FORMAT)



- java/time/format/DateTimeFormatter.java

Line 411: DateTimeException needs to be described, as it is thrown in 
this method.


Line 486: The DateTimeException needs to be on @throws clause.


- java/time/format/DateTimeFormatterBuilder

Line 174: The type for "padNextChar" should be "int" to accommodate 
supplementary characters. Not only this particular instance, it looks 
like there are bunch of places that use ++/-- for character iteration. 
Are they OK?


Line 236: "sensitive" -> "insensitive"

Line 276: "strict" -> "lenient"

Line 1440: use Locale.getDefault(Locale.Category.FORMAT)


- java/time/format/DateTimeFormatters.java

Line 271, 294, 317, 340: Locale.getDefault() -> 
Locale.getDefault(Locale.Category), "default locale" -> "default FORMAT 
locale"



- java/time/format/DateTimeParseContext.java

Line 194, 195: Should those to[Lower/Upper]Case() take Locale.ROOT as an 
argument? Remember the Turkish 'i' case?



- java/time/overview.html

Should the contents here be moved to package.html? Should we continue to 
use "Threeten" name?



- java/time/temporal/Chrono.java

Line 102: "minguoDate" -> "thaiDate"

Line 212: The comment is kind of cryptic. Looks like not "removing" but 
"registering"



- java/time/zone/TzdbZoneRulesProvider.java

Line 171: Is it OK to catch all exceptions here and ignore?


- sun/tools/tzdb/*

Should the compile be moved under "make" directory, instead of "src"?


Naoto

On 1/15/13 4:13 PM, Xueming Shen wrote:

Hi,

The Threeten project [1] is planned to be integrated into OpenJDK8 M6
milestone.

Here is the webrev
http://cr.openjdk.java.net/~sherman/8003680/webrev

and the latest javadoc
http://cr.openjdk.java.net/~sherman/8003680/javadoc

Review comments can be sent to the threeten-dev email list [2] and/or
core-libs-dev email list[3].

Thanks,
Sherman

[1] http://openjdk.java.net/projects/threeten
[2] threeten-dev @ openjdk.java.net
[3] core-libs-dev @ openjdk.java.net

Re: Codereview request for 8003680: JSR 310: Date/Time API

[Naoto Sato]

Hi Sherman,

Here are my comments on the 310 changes:


- java/util/Formatter.java

Line 4125: To do a locale neutral case mapping, use Locale.ROOT instead 
of Locale.US.


Line 4161-4169: Remove this as it is commented out. Also "import 
sun.util.locale.provider.TimeZoneNameUtility" is not needed either.


Line 4173, 4183, 4195: The code assumes Locale.US if "l == null." Is 
this correct? Should it be Locale.ROOT?



- java/time/DayOfWeek.java

Line 298-300: Maybe just me, but I thought the convention for "throws" 
was to consolidate conditions into a single "throws" line for the same 
exception.



- java/time/ZoneOffset.java

Line 214: @SuppressWarnings("fallthrough")?


- java/time/calendar/ChronoDateImpl.java:

In the example in the class description, "%n" should be "\n" for the new 
lines in the printf()s.



- java/time/calendar/HijrahDeviationReader.java

Line 224: Is it OK to catch all Exception here, and pretends as if 
nothing happened?



- java/time/calendar/JapaneseChrono.java

Line 166-172: How come it includes "Keio"? Isn't the era before "Meiji" 
"Seireki"?



- java/time/calendar/MinguoDate.java

Is it OK to NOT serialize "isoDate"? JapaneseDate.java has @serial on 
this field.


- java/time/calendar/ThaiBuddhistDate.java

Same as above MinguoDate.java

- java/time/format/DateTimeBuilder.java

There are several "TODO"s in here.

Line 357: It is commented that return value is for ZoneOffset/ZoneId. 
But since it is public, could this be safe? Can arbitrary app modify it 
maliciously?



- java/time/format/DateTimeFormatSymbols.java

Line 131: It should use the default locale for formatting, i.e, 
Locale.getDefault(Locale.Category.FORMAT)



- java/time/format/DateTimeFormatter.java

Line 411: DateTimeException needs to be described, as it is thrown in 
this method.


Line 486: The DateTimeException needs to be on @throws clause.


- java/time/format/DateTimeFormatterBuilder

Line 174: The type for "padNextChar" should be "int" to accommodate 
supplementary characters. Not only this particular instance, it looks 
like there are bunch of places that use ++/-- for character iteration. 
Are they OK?


Line 236: "sensitive" -> "insensitive"

Line 276: "strict" -> "lenient"

Line 1440: use Locale.getDefault(Locale.Category.FORMAT)


- java/time/format/DateTimeFormatters.java

Line 271, 294, 317, 340: Locale.getDefault() -> 
Locale.getDefault(Locale.Category), "default locale" -> "default FORMAT 
locale"



- java/time/format/DateTimeParseContext.java

Line 194, 195: Should those to[Lower/Upper]Case() take Locale.ROOT as an 
argument? Remember the Turkish 'i' case?



- java/time/overview.html

Should the contents here be moved to package.html? Should we continue to 
use "Threeten" name?



- java/time/temporal/Chrono.java

Line 102: "minguoDate" -> "thaiDate"

Line 212: The comment is kind of cryptic. Looks like not "removing" but 
"registering"



- java/time/zone/TzdbZoneRulesProvider.java

Line 171: Is it OK to catch all exceptions here and ignore?


- sun/tools/tzdb/*

Should the compile be moved under "make" directory, instead of "src"?


Naoto

On 1/15/13 4:13 PM, Xueming Shen wrote:

Hi,

The Threeten project [1] is planned to be integrated into OpenJDK8 M6
milestone.

Here is the webrev
http://cr.openjdk.java.net/~sherman/8003680/webrev

and the latest javadoc
http://cr.openjdk.java.net/~sherman/8003680/javadoc

Review comments can be sent to the threeten-dev email list [2] and/or
core-libs-dev email list[3].

Thanks,
Sherman

[1] http://openjdk.java.net/projects/threeten
[2] threeten-dev @ openjdk.java.net
[3] core-libs-dev @ openjdk.java.net

hg: jdk8/tl/jdk: 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times

[stuart . marks]

Changeset: 79fed1733d4a
Author:jgish
Date:  2013-01-17 15:09 -0500
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79fed1733d4a

8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't 
retry enough times
Summary: Increase number of retries to twice the number of ports in the 
reserved range
Reviewed-by: mduigou

! test/java/rmi/testlibrary/TestLibrary.java

hg: jdk8/tl/langtools: 8004658: Add internal smart javac wrapper to solve JEP 139

[fredrik . ohrstrom]

Changeset: 22e417cdddee
Author:ohrstrom
Date:  2013-01-18 00:16 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/22e417cdddee

8004658: Add internal smart javac wrapper to solve JEP 139
Reviewed-by: jjg

! make/build.properties
! make/build.xml
+ src/share/classes/com/sun/tools/sjavac/BuildState.java
+ src/share/classes/com/sun/tools/sjavac/CleanProperties.java
+ src/share/classes/com/sun/tools/sjavac/CompileChunk.java
+ src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java
+ src/share/classes/com/sun/tools/sjavac/CompileProperties.java
+ src/share/classes/com/sun/tools/sjavac/CopyFile.java
+ src/share/classes/com/sun/tools/sjavac/JavacState.java
+ src/share/classes/com/sun/tools/sjavac/Log.java
+ src/share/classes/com/sun/tools/sjavac/Main.java
+ src/share/classes/com/sun/tools/sjavac/Module.java
+ src/share/classes/com/sun/tools/sjavac/Package.java
+ src/share/classes/com/sun/tools/sjavac/ProblemException.java
+ src/share/classes/com/sun/tools/sjavac/Source.java
+ src/share/classes/com/sun/tools/sjavac/Transformer.java
+ src/share/classes/com/sun/tools/sjavac/Util.java
+ src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java
+ src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java
+ src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java
+ src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java
+ src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java
+ src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java
+ src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java
+ src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java
+ src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java
+ src/share/classes/com/sun/tools/sjavac/server/JavacServer.java
+ src/share/classes/com/sun/tools/sjavac/server/PortFile.java
+ src/share/classes/com/sun/tools/sjavac/server/SysInfo.java
+ test/tools/sjavac/SJavac.java

hg: jdk8/tl/jdk: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

[kurchi . subhra . hazra]

Changeset: e8414d69692c
Author:khazra
Date:  2013-01-17 14:50 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8414d69692c

7171415: java.net.URI.equals/hashCode not consistent for some URIs
Summary: Rewrite URI.hashCode() to consider encoded characters, also reviewed 
by vita...@gmail.com, schlo...@gmail.com
Reviewed-by: chegar

! src/share/classes/java/net/URI.java
! test/java/net/URI/Test.java

Re: Review request JDK-8004729: Parameter Reflection API

[Eric McCorkle]

After (lengthy) examination, it seems that properly addressing the
synthesized parameters issue will require more changes to javac.  In
light of this, I think that the synthesized parameter logic should go in
a follow-up enhancement.  I have created JDK-8006345 to track this issue:

http://bugs.sun.com/view_bug.do?bug_id=8006345

Therefore, I've rolled back the changes I was making which would have
synthesized parameters in the reflection API itself, and updated the
webrev.  Please examine for any additional concerns.


On 01/11/13 13:27, Joe Darcy wrote:
> Hi Eric,
> 
> Taking another look at the code, some extra logic / checking is needed
> in cases where the number of source parameters (non-synthetic and
> non-synthesized) disagrees with the number of actual parameters at a
> class file level.
> 
> For example, if the single source parameter of an inner class
> constructor is annotated, the annotation should be associated with the
> *second* parameter since the first class file parameter is a synthesized
> constructor added by the compiler.  I think generally annotations should
> not be associated with synthesized or synthetic parameters.
> 
> -Joe
> 
> On 1/11/2013 9:03 AM, Eric McCorkle wrote:
>> Update should be visible now.
>>
>> On 01/11/13 11:54, Vitaly Davidovich wrote:
>>> Yes that's exactly what I'm looking for as well.
>>>
>>> Sent from my phone
>>>
>>> On Jan 11, 2013 11:25 AM, "Peter Levart" >> > wrote:
>>>
>>>  On 01/11/2013 04:54 PM, Eric McCorkle wrote:
>>>
>>>  The webrev has been updated again.
>>>
>>>  The multiple writes to parameters have been removed, and the
>>>  tests have
>>>  been expanded to look at inner classes, and to test modifiers.
>>>
>>>  Please look over it again.
>>>
>>>
>>>  Hello Eric,
>>>
>>>  You still have 2 reads of volatile even in fast path. I would do it
>>>  this way:
>>>
>>>
>>>  private Parameter[] privateGetParameters() {
>>>  Parameter[] tmp = parameters; // one and only read
>>>  if (tmp != null)
>>>  return tmp;
>>>
>>>  // Otherwise, go to the JVM to get them
>>>  tmp = getParameters0();
>>>
>>>  // If we get back nothing, then synthesize parameters
>>>  if (tmp == null) {
>>>  final int num = getParameterCount();
>>>  tmp = new Parameter[num];
>>>  for (int i = 0; i < num; i++)
>>>  // TODO: is there a way to synthetically derive the
>>>  // modifiers?  Probably not in the general case, since
>>>  // we'd have no way of knowing about them, but there
>>>  // may be specific cases.
>>>  tmp[i] = new Parameter("arg" + i, 0, this, i);
>>>  // This avoids possible races from seeing a
>>>  // half-initialized parameters cache.
>>>  }
>>>
>>>  parameters = tmp;
>>>
>>>  return tmp;
>>>  }
>>>
>>>
>>>  Regards, Peter
>>>
>>>
>>>  Test-wise, I've got a clean run on JPRT (there were some
>>> failures in
>>>  lambda stuff, but I've been seeing that for some time now).
>>>
>>>  On 01/10/13 21:47, Eric McCorkle wrote:
>>>
>>>  On 01/10/13 19:50, Vitaly Davidovich wrote:
>>>
>>>  Hi Eric,
>>>
>>>  Parameter.equals() doesn't need null check - instanceof
>>>  covers that already.
>>>
>>>  Removed.
>>>
>>>  Maybe this has been mentioned already, but personally
>>>  I'm not a fan of
>>>  null checks such as "if (null == x)" - I prefer the
>>> null
>>>  on the right
>>>  hand side, but that's just stylistic.
>>>
>>>  Changed.
>>>
>>>  Perhaps I'm looking at a stale webrev but
>>>  Executable.__privateGetParameters() reads and writes
>>>  from/to the volatile
>>>  field more than once.  I think Peter already mentioned
>>>  that it should
>>>  use one read into a local and one write to publish the
>>>  final version to
>>>  the field (it can return the temp as well).
>>>
>>>  You weren't.  From a pure correctness standpoint, there is
>>>  nothing wrong
>>>  with what is there.  getParameters0 is a constant
>>> function, and
>>>  parameters is writable only if null.  Hence, we only every
>>>  see one
>>>  nontrivial write to it.
>>>
>>>  But you are right, it should probably be reduced to a
>>> single
>>>  write, for
>>>  performance reasons (to avoid unnecessary memory barriers).
>>>   Therefore,
>>>  I changed it.
>>>
>>>  However, I won't be able to refresh the webrev until
>>> tomorrow.
>>>
>>>  T

Re: RFR: 8006534 CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times

[Mike Duigou]

Seems entirely reasonable.

On Jan 17 2013, at 12:18 , Jim Gish wrote:

> Please review 
> http://cr.openjdk.java.net/~jgish/Bug8006534-getUnusedRandomPort-retry-more/ 
> 
> 
> TestLibrary.getUnusedPort() attempts to retry getting an ephemeral port 10 
> times, which is the current number of ports in the reserved port range.  
> Debugging code added a few weeks back has revealed that intermittent failures 
> in tests using this method are caused when the underlying socket code first 
> returns the first number in the reserved port range.  Subsequent retries 
> result in incrementing the port number by one until reaching the max reserved 
> port number, which just happens to correspond to the 10th attempt, and the 
> code then quits trying.
> 
> The proposed fix (one of many possible alternatives, of course) simply 
> retries for twice the number of ports in the range.
> 
> Thanks,
>   Jim
> 
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.g...@oracle.com
> 

hg: jdk8/tl/jdk: 8006090: Formatter asserts with -esa

[xueming . shen]

Changeset: 787c7c1c210f
Author:sherman
Date:  2013-01-17 12:49 -0800
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/787c7c1c210f

8006090: Formatter asserts with -esa
Summary: removed the offending assert
Reviewed-by: alanb, darcy
Contributed-by: brian.burkhal...@oracle.com

! src/share/classes/java/util/Formatter.java
! test/ProblemList.txt

Re: Review Request : Java exe doesn't process args ending Back slash

[Kumar Srinivasan]

Hi Jayashree,

I have assigned a JBS issue to this: JDK-8006536, for your reference.
I have attached a modified patch to that issue.

There are other issues as well that needs to be resolved with \ parsing.
We will address this once we are done with our JDK8 Milestone feature
commitments.

Thanks
Kumar


On 16-01-2013 6:26 AM, Kumar Srinivasan wrote:

Hello Jayashree,

I see the issue, I have been busy with other things, I will revisit your
patch in the coming week.

Kumar


On 20-12-2012 12:07 AM, Kumar Srinivasan wrote:

Hello Jayashree,

a. you are referencing a bug which has already been fixed, is there a
new one for this ?

b. with regards to the fix, I don't quite understand the issue, 
could you please

provide a  use case ?

c. your regression test does not seem to be accurate it behaves the 
same with or
without your fix, also you will need to provide a C++ test case 
in cmdtoargs.c

as well see the bottom of that file.


Thanks
Kumar






Hi All,

Java.exe doesn't seems to process arguments ending with back slashes
well , in windows only .

I have added test scenario and changeset in the below webrev .

http://cr.openjdk.java.net/~jviswana/7188114/webrev.01/

This seems to be introduced after the bug fix for 7188114 has be made
into jdk8 .

Thanks and Regards,
Jayashree Viswanathan







Hi Kumar ,

a. I am referencing an old bug because , that bug fix has caused 
this regression .


b. The use case is when there are backslashes at the end args for a 
java command using say -Dtest.argEndingInBackslash=a


JavaVM args:
version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 5
option[ 0] = '-Dsun.java.launcher.diag=true'
option[ 1] = '-Djava.class.path=.'
option[ 2] = '-Dtest.argEndingInBackslash=a'
option[ 3] = '-Dsun.java.command=TestCmdLineParsing'
option[ 4] = '-Dsun.java.launcher=SUN_STANDARD'
74439 micro seconds to InitializeJVM
Main class is 'TestCmdLineParsing'
App's argc is 0
9182 micro seconds to load main class
_JAVA_LAUNCHER_DEBUG
value of test.argEndingInBackslash = a


c. Sorry , I seem to have missed something , the above test case 
should help you exhibit the problem .
 Can you please let me know where to find or add such C++ test cases 
, as In the test cases bucket I know off is jtreg or JCKs only at 
the moment .


Thanks and Regards,
Jayashree Viswanathan





Thanks for the response !

Regards,
Jayashree Viswanathan

RFR: 8006534 CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times

[Jim Gish]

Please review 
http://cr.openjdk.java.net/~jgish/Bug8006534-getUnusedRandomPort-retry-more/ 



TestLibrary.getUnusedPort() attempts to retry getting an ephemeral port 
10 times, which is the current number of ports in the reserved port 
range.  Debugging code added a few weeks back has revealed that 
intermittent failures in tests using this method are caused when the 
underlying socket code first returns the first number in the reserved 
port range.  Subsequent retries result in incrementing the port number 
by one until reaching the max reserved port number, which just happens 
to correspond to the 10th attempt, and the code then quits trying.


The proposed fix (one of many possible alternatives, of course) simply 
retries for twice the number of ports in the range.


Thanks,
   Jim

--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com

hg: jdk8/tl/langtools: 8005852: Treatment of '_' as identifier

[maurizio . cimadamore]

Changeset: 2d2b2be57c78
Author:mcimadamore
Date:  2013-01-17 18:15 +
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d2b2be57c78

8005852: Treatment of '_' as identifier
Summary: warn when '_' is found in an identifier position
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/tools/javac/lambda/LambdaParserTest.java

Re: RFR: 8006090 - Formatter asserts with -esa

[Xueming Shen]

On 1/17/13 10:00 AM, Alan Bateman wrote:


This looks fine to me.

Sherman - I suspect the same assert in the print method added by 
JSR-310 has the same issue.


Yes. That will be removed as well.



-Alan.

On 17/01/2013 17:36, Brian Burkhalter wrote:

The assert occurs in

private Appendable print(StringBuilder sb, Calendar t, char c,
  Locale l)

due to

assert(width == -1);

not being satisfied. The proposed fix is to remove this assert 
statement which appears to be vestigial. Regression and compatibility 
testing did not reveal any failures due to removing this statement.


--- old/src/share/classes/java/util/Formatter.java 2013-01-16 
12:22:55.0 -0800
+++ new/src/share/classes/java/util/Formatter.java 2013-01-16 
12:22:55.0 -0800

@@ -3827,7 +3827,6 @@
   Locale l)
  throws IOException
  {
-assert(width == -1);
  if (sb == null)
  sb = new StringBuilder();
  switch © {

Thanks,

Brian

Re: RFR: 8006090 - Formatter asserts with -esa

[Alan Bateman]

This looks fine to me.

Sherman - I suspect the same assert in the print method added by JSR-310 
has the same issue.


-Alan.

On 17/01/2013 17:36, Brian Burkhalter wrote:

The assert occurs in

private Appendable print(StringBuilder sb, Calendar t, char c,
  Locale l)

due to

assert(width == -1);

not being satisfied. The proposed fix is to remove this assert statement which 
appears to be vestigial. Regression and compatibility testing did not reveal 
any failures due to removing this statement.

--- old/src/share/classes/java/util/Formatter.java  2013-01-16 
12:22:55.0 -0800
+++ new/src/share/classes/java/util/Formatter.java  2013-01-16 
12:22:55.0 -0800
@@ -3827,7 +3827,6 @@
   Locale l)
  throws IOException
  {
-assert(width == -1);
  if (sb == null)
  sb = new StringBuilder();
  switch © {

Thanks,

Brian

Re: RFR: 8006090 - Formatter asserts with -esa

[Joe Darcy]

Look fine Brian.

Thanks,

-Joe

On 1/17/2013 9:36 AM, Brian Burkhalter wrote:

The assert occurs in

private Appendable print(StringBuilder sb, Calendar t, char c,
  Locale l)

due to

assert(width == -1);

not being satisfied. The proposed fix is to remove this assert statement which 
appears to be vestigial. Regression and compatibility testing did not reveal 
any failures due to removing this statement.

--- old/src/share/classes/java/util/Formatter.java  2013-01-16 
12:22:55.0 -0800
+++ new/src/share/classes/java/util/Formatter.java  2013-01-16 
12:22:55.0 -0800
@@ -3827,7 +3827,6 @@
   Locale l)
  throws IOException
  {
-assert(width == -1);
  if (sb == null)
  sb = new StringBuilder();
  switch © {

Thanks,

Brian

Re: RFR (M): JDK-8004967 - Default method cause java.lang.VerifyError: Illegal use of nonvirtual function call

[Karen Kinnear]

Change looks good give I don't know any way for the java library to get the 
internal method type information.

Can you please fix the spelling of "implementation" in the comment?

thanks,
Karen

p.s. And I think you are ensuring !abstract by doing an exact match of flags.
On Jan 16, 2013, at 1:35 PM, Bharadwaj Yadavalli wrote:

> Please review the change at 
> http://cr.openjdk.java.net/~bharadwaj/8004967/webrev/
> 
> Default interface methods are new in Java 8. VM creates overpass methods in 
> the vtable slots of classes to invoke a default method using invokespecial.
> 
> Consequently, invocation of default interface methods (i.e., overpass methods 
> in the VM) via invokespecial is legal and should not be flagged as illegal.
> 
> In short, this change allows invocation of default methods of Java 8 using 
> invokespecial.
> 
> I ran JCK (vm, lang, api) tests, runThese and vm.quicklist with no new 
> failures.
> 
> Thanks,
> 
> Bharadwaj
> 

RFR: 8006090 - Formatter asserts with -esa

[Brian Burkhalter]

The assert occurs in

private Appendable print(StringBuilder sb, Calendar t, char c,
 Locale l)

due to

assert(width == -1);

not being satisfied. The proposed fix is to remove this assert statement which 
appears to be vestigial. Regression and compatibility testing did not reveal 
any failures due to removing this statement.

--- old/src/share/classes/java/util/Formatter.java  2013-01-16 
12:22:55.0 -0800
+++ new/src/share/classes/java/util/Formatter.java  2013-01-16 
12:22:55.0 -0800
@@ -3827,7 +3827,6 @@
  Locale l)
 throws IOException
 {
-assert(width == -1);
 if (sb == null)
 sb = new StringBuilder();
 switch © {

Thanks,

Brian

Re: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

[Xueming Shen]

JDK-8006530 (including the request of explicitly documenting the no \n at
end behavior)

-Sherman

On 1/17/13 9:03 AM, Xueming Shen wrote:

Hi,

Yes,  padding \n (and any non-base64 character) after base64 padding 
character
'=' probably should be ignored, instead of exception in mime mode. The 
behavior/
implementation is not consistent now for this case. Will file a cr and 
address this,

probably after M6.

Thanks!
-Sherman

On 1/17/13 7:02 AM, Mark Sheppard wrote:

Hi Max,

The fact that the padding characters == and = appear before the
newline, leads to RFC2045 section 6.8 (pg 25) and how the
implementation interprets the processing for the pad character in the 
encoding.


As per RFC2045 base64 encoding the occurrence of = indicates end of 
data.

That is to say, == or = is only used in the final unit of encoding
at the very end of the encoded data.
This raises a couple of questions:
So is it an error if there are data after these explicit "end of 
data" markers, when they occur?

should a special case be made for line separators?
What about ignoring any data after == or = ?

The javadoc for Base64 Mime Encoder/Decoder alludes to the line 
separator and characters
outside the base64 alphabet being ignored during decoding. This in 
itself can be ambiguously
interpreted to mean anywhere in the stream, including after an end of 
data indicator,

unless specific attention and interpretation is give to RFC2045.

Consider the fact that

Base64.getMimeDecoder().decode("AA==B") also throws an exception
  this suggests that the decoder is interpreting data after the
end of data padding indication as an error.

Thus, a newline after = or == is reasonable interpreted as an error, 
suggesting

that the exception is reasonable.

It can be noted that Base64.getMimeDecoder().decode("\n")
doesn't throw an exception.

regards
Mark


- Original Message -
From: weijun.w...@oracle.com
To: core-libs-dev@openjdk.java.net
Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, 
Ireland, Portugal
Subject: And Decoder (was Re: No newline at the end of 
Base64.getMimeEncoder())


This time on the decoder side:

Base64.getMimeDecoder().decode("AA==\n")

throws an exception because the string ends with a newline. I would
prefer it be acceptable.

Thanks
Max

On 01/17/2013 05:12 PM, Weijun Wang wrote:
I noticed that the encoding output of Base64.getMimeEncoder() never 
ends

with a newline char. There is no right or wrong on this but it will be
nice to write the current behavior into the spec.

Thanks
Max

Re: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

[Xueming Shen]

Hi,

Yes,  padding \n (and any non-base64 character) after base64 padding 
character
'=' probably should be ignored, instead of exception in mime mode. The 
behavior/
implementation is not consistent now for this case. Will file a cr and 
address this,

probably after M6.

Thanks!
-Sherman

On 1/17/13 7:02 AM, Mark Sheppard wrote:

Hi Max,

The fact that the padding characters == and = appear before the
newline, leads to RFC2045 section 6.8 (pg 25) and how the
implementation interprets the processing for the pad character in the encoding.

As per RFC2045 base64 encoding the occurrence of = indicates end of data.
That is to say, == or = is only used in the final unit of encoding
at the very end of the encoded data.
This raises a couple of questions:
So is it an error if there are data after these explicit "end of data" markers, 
when they occur?
should a special case be made for line separators?
What about ignoring any data after == or = ?

The javadoc for Base64 Mime Encoder/Decoder alludes to the line separator and 
characters
outside the base64 alphabet being ignored during decoding. This in itself can 
be ambiguously
interpreted to mean anywhere in the stream, including after an end of data 
indicator,
unless specific attention and interpretation is give to RFC2045.

Consider the fact that

Base64.getMimeDecoder().decode("AA==B") also throws an exception
  
this suggests that the decoder is interpreting data after the

end of data padding indication as an error.

Thus, a newline after = or == is reasonable interpreted as an error, suggesting
that the exception is reasonable.

It can be noted that Base64.getMimeDecoder().decode("\n")
doesn't throw an exception.

regards
Mark


- Original Message -
From: weijun.w...@oracle.com
To: core-libs-dev@openjdk.java.net
Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, Ireland, 
Portugal
Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

This time on the decoder side:

Base64.getMimeDecoder().decode("AA==\n")

throws an exception because the string ends with a newline. I would
prefer it be acceptable.

Thanks
Max

On 01/17/2013 05:12 PM, Weijun Wang wrote:

I noticed that the encoding output of Base64.getMimeEncoder() never ends
with a newline char. There is no right or wrong on this but it will be
nice to write the current behavior into the spec.

Thanks
Max

Request for review: 8004698: Implement Core Reflection for Type Annotations

[Joel Borggrén-Franck]

Hi,

Here is a webrev for core reflection support for type annotations:

http://cr.openjdk.java.net/~jfranck/8004698/webrev.00/

This code is based on the tl/jdk repository, but in order to run the tests you 
need a javac with type annotations support and also a recent copy of the VM 
that includes this change set: 
http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35431a769282 (This also 
means this code can't be pushed until all supporting pieces are in place.)

Type annotations are still a bit of a moving target so there will be follow up 
work on this. There is no caching of annotations in this version and I am not 
sure how we want to do the space/time trade of for type annotations.

cheers
/Joel

Re: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

[Mark Sheppard]

Hi Max,

The fact that the padding characters == and = appear before the
newline, leads to RFC2045 section 6.8 (pg 25) and how the
implementation interprets the processing for the pad character in the encoding.

As per RFC2045 base64 encoding the occurrence of = indicates end of data. 
That is to say, == or = is only used in the final unit of encoding
at the very end of the encoded data.
This raises a couple of questions:
So is it an error if there are data after these explicit "end of data" markers, 
when they occur?
should a special case be made for line separators?
What about ignoring any data after == or = ?

The javadoc for Base64 Mime Encoder/Decoder alludes to the line separator and 
characters
outside the base64 alphabet being ignored during decoding. This in itself can 
be ambiguously
interpreted to mean anywhere in the stream, including after an end of data 
indicator,
unless specific attention and interpretation is give to RFC2045.

Consider the fact that

Base64.getMimeDecoder().decode("AA==B") also throws an exception
 
this suggests that the decoder is interpreting data after the
end of data padding indication as an error.

Thus, a newline after = or == is reasonable interpreted as an error, suggesting
that the exception is reasonable.

It can be noted that Base64.getMimeDecoder().decode("\n")
doesn't throw an exception.

regards
Mark


- Original Message -
From: weijun.w...@oracle.com
To: core-libs-dev@openjdk.java.net
Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, Ireland, 
Portugal
Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

This time on the decoder side:

   Base64.getMimeDecoder().decode("AA==\n")

throws an exception because the string ends with a newline. I would 
prefer it be acceptable.

Thanks
Max

On 01/17/2013 05:12 PM, Weijun Wang wrote:
> I noticed that the encoding output of Base64.getMimeEncoder() never ends
> with a newline char. There is no right or wrong on this but it will be
> nice to write the current behavior into the spec.
>
> Thanks
> Max

And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

[Weijun Wang]

This time on the decoder side:

  Base64.getMimeDecoder().decode("AA==\n")

throws an exception because the string ends with a newline. I would 
prefer it be acceptable.


Thanks
Max

On 01/17/2013 05:12 PM, Weijun Wang wrote:

I noticed that the encoding output of Base64.getMimeEncoder() never ends
with a newline char. There is no right or wrong on this but it will be
nice to write the current behavior into the spec.

Thanks
Max

Re: hg: jdk8/tl/jdk: 8006153: HTTP protocol handler authenication should use Base64 API

[Chris Hegarty]

On 01/17/2013 09:37 AM, Weijun Wang wrote:

NTLM auth still uses it. Codes in src/windows and src/solaris.


Thank you Max.

Yes, Mark just noticed these yesterday. He is preparing a patch and will 
send it for review shortly.


-Chris.



-Max

On 01/14/2013 06:14 AM, chris.hega...@oracle.com wrote:

Changeset: 7db04ae3378f
Author:chegar
Date:  2013-01-13 22:09 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7db04ae3378f

8006153: HTTP protocol handler authenication should use Base64 API
Reviewed-by: chegar, alanb
Contributed-by: Mark Sheppard 

! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
!
src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java

Re: hg: jdk8/tl/jdk: 8006153: HTTP protocol handler authenication should use Base64 API

[Weijun Wang]

NTLM auth still uses it. Codes in src/windows and src/solaris.

-Max

On 01/14/2013 06:14 AM, chris.hega...@oracle.com wrote:

Changeset: 7db04ae3378f
Author:chegar
Date:  2013-01-13 22:09 +
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7db04ae3378f

8006153: HTTP protocol handler authenication should use Base64 API
Reviewed-by: chegar, alanb
Contributed-by: Mark Sheppard 

! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java

No newline at the end of Base64.getMimeEncoder()

[Weijun Wang]

I noticed that the encoding output of Base64.getMimeEncoder() never ends 
with a newline char. There is no right or wrong on this but it will be 
nice to write the current behavior into the spec.


Thanks
Max

Re: JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries

[Peter Levart]

On 01/17/2013 07:58 AM, Remi Forax wrote:

On 01/16/2013 11:25 PM, Peter Levart wrote:


On 01/16/2013 05:58 PM, Joe Darcy wrote:

On 1/16/2013 8:32 AM, Florian Weimer wrote:

On 01/16/2013 05:27 PM, Brian Goetz wrote:

The primary purpose of this annotation is to *capture design 
intent*.  It is not required.  The compiler will help you enforce 
the design intent if you provide it.  The compiler will not 
synthesize this annotation, since that would be guessing at the 
design intent.  It is possible to create classfiles that subvert 
the design intent.


The point about other languages was simply to point out that the 
universe of tools that might usefully use this design intent is 
bigger than sometimes assumed.


I don't think run-time behavior should depend on optional 
annotations documenting design intent (like @Override).


Supporting the discovery of functional interfaces is a good idea. 
But a method like Class#isFunctionalInterface() would sever this 
purpose better than an entirely optional annotation.




A method like Class#isFunctionalInterface is planned too for later 
in JDK 8.
I can imagine that a method like that would be useful if also 
accompanied with a method like:


Class#getFunctionalInterfaceMethod()


this method may not exist.
Even if isFunctionalInterface() returns true? How? There might be more 
than one (if they can be implemented by a single method), but there 
might exist an algorithm to choose the most appropriate.


Regards, Peter




Regards, Peter



-Joe




Rémi