Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Aleks Efimov wrote on 6/16/17 9:17 AM: > 3. MimetypesFileTypeMap.java: > - Are the Parens around lines 54-57 really needed? > > I think that the parens are not needed too. Removed them + also > removed > parens from MailcapCommandMap javadoc. > Bill, please, confirm if you thi

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Shouldn't the version information be in the manifest for the jar file containing the classes, accessed via java.lang.Package? Roman Grigoriadi wrote on 05/ 3/17 09:49 AM: > Hi, > > you can find new web rev here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ >

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

I got no response to this so I'm assuming everyone is happy now! :-) Bill Shannon wrote on 03/15/2017 03:20 PM: > Looks like I have a chance to tweak the comments for the JAF changes. > Any final comments before I apply these changes to all 4 copies of > this code?

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Looks like I have a chance to tweak the comments for the JAF changes. Any final comments before I apply these changes to all 4 copies of this code? $ diff -u MailcapCommandMap.java.orig MailcapCommandMap.java --- MailcapCommandMap.java.orig 2017-03-15 15:10:43.731176917 -0700 +++ MailcapCommandMap

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

Alan Bateman wrote on 03/12/17 08:14 AM: > In MailcapCommandMap then the following doesn't seem right for the class > description: > > 59 * (Where java.home is the value of the "java.home" System > property > 60 * and conf is the directory named "conf" if it exists, > 61 * otherwise the

Re: 8057795: Update of the mimestypes.default for JAF

The list of possible MIME type mappings is endless and it's not worth the effort to try to keep up. This one change just keeps the JDK in sync with the standalone version. Lance Andersen wrote on 02/ 7/17 12:01 PM: > Hi Brian, > > Thank you for the quick review. > > I will defer to Bill on whethe

Re: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail

Chris Hegarty wrote on 05/19/14 10:27: > Miran, > > The source change looks ok to me. Have you commented out the line adding the > handler because it may be reinstated, or as a reminder that it was > deliberately > omitted? Either way, the code could probably use a comment to explain why it's co

Re: RFR 8025003: Base64 should be less strict with padding

Alan Bateman wrote on 11/15/13 04:21: > On 14/11/2013 23:27, Bill Shannon wrote: >> : >> I'd prefer that all variants of the API report the error in a way that allows >> the users of the API to ignore the error, access the data that caused the >> error, >>

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/14/2013 11:20 AM: > On 11/14/2013 11:12 AM, Bill Shannon wrote: >> Alan Bateman wrote on 11/14/2013 06:18 AM: >>> On 13/11/2013 20:28, Xueming Shen wrote: >>>> Yes, the plan is to see what other implementations do. >>> I think we

Re: RFR 8025003: Base64 should be less strict with padding

Alan Bateman wrote on 11/14/2013 06:18 AM: > On 13/11/2013 20:28, Xueming Shen wrote: >> >> Yes, the plan is to see what other implementations do. > I think we've run out road on this for JDK 8. Even if we had agreement on > dealing with corrupt input then there is little/no time to get feedback an

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/13/13 12:28: > On 11/13/2013 11:37 AM, Bill Shannon wrote: >> Xueming Shen wrote on 11/13/13 11:11: >>> On 11/13/2013 10:41 AM, Bill Shannon wrote: >>>> >>>>> The other thought is the charset API where a charset decoder can be

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/13/13 11:11: > On 11/13/2013 10:41 AM, Bill Shannon wrote: >> >> >>> The other thought is the charset API where a charset decoder can be >>> configured >>> to ignore, replace or report then malformed or unmappable input. Having

Re: RFR 8025003: Base64 should be less strict with padding

Alan Bateman wrote on 11/13/13 08:51: > On 13/11/2013 04:21, Bill Shannon wrote: >> : >> There's really no error recovery possible, and certainly no program is >> going to attempt error recovery. As I said, there's only two reasonable >> things to do: 1) t

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/13/13 08:28: > On 11/12/13 11:44 PM, Bill Shannon wrote: >> Xueming Shen wrote on 11/12/2013 09:24 PM: >>> On 11/12/13 8:21 PM, Bill Shannon wrote: >>>> Xueming Shen wrote on 11/12/2013 04:25 PM: >>>>> On 11/12/2013 03:32 PM

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/12/2013 09:24 PM: > On 11/12/13 8:21 PM, Bill Shannon wrote: >> Xueming Shen wrote on 11/12/2013 04:25 PM: >>> On 11/12/2013 03:32 PM, Bill Shannon wrote: >>>> This still seems like an inconsistent, and inconvenient, approach to me. >

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 11/12/2013 04:25 PM: > On 11/12/2013 03:32 PM, Bill Shannon wrote: >> This still seems like an inconsistent, and inconvenient, approach to me. >> >> You've decided that some encoding errors (i.e., missing pad characters) >> can be ignored. Y

Re: RFR 8025003: Base64 should be less strict with padding

ery mechanism appears to work perfectly for your use > scenario:-) the "only" downside"/inconvenience is that you will need to > wrap your byte array input/output with the java.nio ByteBuffer (which is > out recommended replacement for byte[] + length + offset anyway). &

Re: RFR 8025003: Base64 should be less strict with padding

Have you had a chance to think about this? Can the MIME decoder be made more lenient, or can I get an option to control this? Bill Shannon wrote on 10/25/13 15:24: > Xueming Shen wrote on 10/25/13 15:19: >> On 10/25/13 2:19 PM, Bill Shannon wrote: >>> If I understand th

Re: RFR 8025003: Base64 should be less strict with padding

Xueming Shen wrote on 10/25/13 15:19: > On 10/25/13 2:19 PM, Bill Shannon wrote: >> If I understand this correctly, this proposes to remove the "lenient" >> option we've been discussing and just make it always lenient. Is that >> correct? > > Yes. O

Re: RFR 8025003: Base64 should be less strict with padding

If I understand this correctly, this proposes to remove the "lenient" option we've been discussing and just make it always lenient. Is that correct? Unfortunately, from what you say below, it's still not lenient enough. I'd really like a version that never, ever, for any reason, throws an excepti

Re: Codereview request for 6995537: different behavior in iso-2022-jp encoding between jdk131/140/141 and jdk142/5/6/7

hough. I think it's a correct fix, not a workaround, to create a filter stream to deal with stateful encodings with the java.io API. If it's OK to support only 1.4 and later, the java.nio.charset API should be used. Thanks, Masayoshi On 2/10/2012 4:12 AM, Xueming Shen wrote: CC

Re: Codereview request for 4153167: separate between ANSI and OEM code pages on Windows

Thanks for fixing this! The webrev is at http://cr.openjdk.java.net/~sherman/4153167/webrev You probably don't need to malloc 64 bytes for a string that's going to be less than 16 bytes. And shouldn't you use snprintf in any event? Unlike Unix, I assume Windows has no way to have multiple "