Hi Jon,
thanks for your feedback.
Sorry for getting the javac/Javadoc wrong, I missed that.
The point is that the option implementation there does not have
the possibility to accept an option but not document it.
javac:
I'd like to propose to add -help again. javac else prints:
javac: inval
Hi Robert,
thanks for looking at my change.
I'm fine with listing the flags in a different order, but
it's ambiguous. Java itslef lists "-? -h --help" therefore
I chose this for most of the tools, too.
But just tell me how to put it.
Below, I list all the option help messages for the
tools on
I've had a longer think about how to integrate this. Its very tricky,
as the unicode extensions create complex conflicts.
In general, my view is that Locale is too complex and overloaded with
different levels of meaning. Perhaps a different class should have
been added for more complex localizatio
Hi Alan,
thanks for looking at my change.
Thanks for pointing to JEP 293. I see my change mostly
follows its ideas.
As Jon, I don't think asking for support of -help makes sense
as it's not according to the gnu style, and it's not that
hard to get it right anyways.
I'll remove the edits to the
Hi Max,
I think there are so many tools mixing both kinds of
options, that it's rather a gain if all at least document
the same, up to date help message, than if the documentation
is skipped for some.
After my change, all the help messages are quite similar.
I updated them to use the same wordi
On 20/11/2017 13:41, Lindenmaier, Goetz wrote:
:
The deprecated tools are
orbd,
wsgen
wsimport
schemagen
Is that correct?
Yes, plus xjc, idlj, servertool and tnameserv (the full list is in the
draft JEP that I linked to).
-Alan
On 17/11/2017 16:53, Xueming Shen wrote:
On 11/17/17, 3:35 AM, Alan Bateman wrote:
:
1. getRealName is very welcome but I think it should be a no-arg
method on JarEntry, not JarFile. That would make it easier to use and
also avoids the temptation to call JarFile.getRealName with an entry
i
Hi Goetz
I understand your intention.
If the reason is that one day every tool will switch to this new style, please
at least do not include kinit, klist and ktab. These Windows-only commands are
meant to emulate MIT krb5 tools with the same names and we need to keep the
option (and maybe the
On 17/11/2017 16:53, Xueming Shen wrote:
:
3. Is ZipFile.entryNameStream really needed? Just asking because
zf.stream().map(ZipEntry::getName) is possible today.
It's not a "must" for sure. The motivation behind this is that my
observation of most normal use scenario
inside JDK is that only
Hi Alan,
Here is the updated webrev with
(1) to move JarFile.getRealName into JarEntry
(2) to hide ZipFile.entryNameStream() from the public
(3) to reword the JarFile.versionedStream() to scope the "latest versined"
http://cr.openjdk.java.net/~sherman/8189611/webrev
thanks,
Sherman
On 11/20/1
> On 17 Nov 2017, at 17:18, Stuart Marks wrote:
>
> Hi Paul,
>
> The normative text about binding to the source and subsequent modifications
> to the source possibly not being reflected in the stream makes sense.
>
> I'm having trouble understanding the API note though. What does "optimal"
Hi,
The schedule of dynamic constants has been adjusted, the JEP is currently
proposed to target for 11.
There is risk to integrating a change such as constant dynamic this late in the
10 release schedule. Instead it's better, and more aligned with the new release
process, to integrate early o
2017/11/20 11:56:42 -0800, paul.san...@oracle.com:
> The schedule of dynamic constants has been adjusted, the JEP is
> currently proposed to target for 11.
>
> There is risk to integrating a change such as constant dynamic this
> late in the 10 release schedule. Instead it's better, and more align
https://bugs.openjdk.java.net/browse/JDK-8191516
http://cr.openjdk.java.net/~bpb/8191516/webrev.00/
Change OutputStream.write(byte[],int,int) to use the same three parameter
bounds checks used by InputStream.read(byte[],int,int) instead of the five
checks currently used. This change is covered b
Hi Stephen, please see my comments below.
On 11/20/17 5:27 AM, Stephen Colebourne wrote:
I've had a longer think about how to integrate this. Its very tricky,
as the unicode extensions create complex conflicts.
In general, my view is that Locale is too complex and overloaded with
different leve
> On 20 Nov 2017, at 10:27, Xueming Shen wrote:
>
> Hi Alan,
>
> Here is the updated webrev with
>
> (1) to move JarFile.getRealName into JarEntry
> (2) to hide ZipFile.entryNameStream() from the public
> (3) to reword the JarFile.versionedStream() to scope the "latest versined"
>
> http://c
> On 20 Nov 2017, at 16:53, Brian Burkhalter
> wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8191516
> http://cr.openjdk.java.net/~bpb/8191516/webrev.00/
>
> Change OutputStream.write(byte[],int,int) to use the same three parameter
> bounds checks used by InputStream.read(byte[],int,in
Thanks Paul!
Webrev has been updated as suggested.
http://cr.openjdk.java.net/~sherman/8189611/webrev
jdeps' VersionHelper.java still accesses the "getRealName()" via the
SharedSecrets.
Since jdeps is being compiled/built with the bootjdk, I'm leaving it
untouched for
now.
-
Hi everyone,
I haven't got any reply now for around three weeks and now i start to
wonder if I just missed it or if I should refine my approach to find a
sponsor or if it helped if I presented a ready patch or if noone
considers this important enough or anything else whatever. This is only
my
19 matches
Mail list logo
