Re: RFE to re-purpose option --version:

<marti...@google.com> wrote: > > > On Wed, Aug 10, 2016 at 10:34 AM, Paul Benedict <pbened...@apache.org> > wrote: > >> Unfortunately, the "release" file is >> not available in my operating environment. The installed JDK/JRE images on >> my

Re: RFE to re-purpose option --version:

JDK and JRE image but not custom > image since the property is supplied by the jdk build. > > Mandy > > > On Aug 9, 2016, at 9:49 AM, Paul Benedict <pbened...@apache.org> wrote: > > > > No, I haven't considered that. Thank you, Mandy. Good tip. And I see &

Re: RFE to re-purpose option --version:

016, at 8:51 AM, Paul Benedict <pbened...@apache.org> wrote: > > > > However, I would like to propose bringing back the option with a > different > > purpose. I would like to use --version: as a validation check. I > > want Java to execute ONLY if the version s

Re: RFE to re-purpose option --version:

Kumar, thank you for that information. I find that useful too. Now with regard to this email's proposal, are there any further opinions? If this has merit, I would appreciate if someone could create a ticket for consideration? Cheers, Paul On Mon, Aug 8, 2016 at 4:20 PM, Kumar Srinivasan <

RFE to re-purpose option --version:

Dear Committers, In Java 9, the --version: has been deprecated. The error message returned to me is: Error: Specifying an alternate JDK/JRE version is no longer supported. The use of the flag '-version:' is no longer valid. Please download and execute the appropriate version. Unrecognized

Re: Question on MVJAR usage

Thank you Steve. I have only one follow-up then. If the platform version is *always* a major version, does that imply that minor versions will not add API? The big benefit of MRJAR :-) is that I can provide separate code for different targeted runtimes. If 9.1 wouldn't add new API, then I am good.

Question on MVJAR usage

I have some questions. I believe core-lib is the right place. If not please let me know. 1) Given a Java 9 runtime, is there any perceptible difference between a non-multiversion jar, and a versioned jar which has placed all its classes under /META-INF/versions/9 ? Pretend each jar has the same

Re: --dry-run description enhancement

. On Jul 11, 2016 9:41 PM, "Mandy Chung" <mandy.ch...@oracle.com> wrote: > > > On Jul 12, 2016, at 10:35 AM, Paul Benedict <pbened...@apache.org> > wrote: > > > > Mandy, can you please give a look to the first email in this thread and > see if you belie

Re: --dry-run description enhancement

Mandy, can you please give a look to the first email in this thread and see if you believe the enhanced message I suggested is helpful? I think it would be. On Jul 11, 2016 8:32 PM, "Mandy Chung" <mandy.ch...@oracle.com> wrote: > > > On Jul 12, 2016, at 6:13

Re: --dry-run description enhancement

Alan, I wish I found this before I responded to you, but, anyway, here you go: https://bugs.openjdk.java.net/browse/JDK-8160698 "java --dry-run should not cause main class be initialized" Cheers, Paul On Mon, Jul 11, 2016 at 5:09 PM, Paul Benedict <pbened...@apache.org> wro

Re: --dry-run description enhancement

ly just a "--no-main" but user code can still run. Cheers, Paul On Mon, Jul 11, 2016 at 4:39 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 11/07/2016 22:01, Paul Benedict wrote: > > The current help of --dry-run is this: >> "create VM but do not exec

--dry-run description enhancement

The current help of --dry-run is this: "create VM but do not execute main method" But I think it's pretty important to note that the class is also not even loaded. Not even static initializers will execute. Does anyone think this would would be a worthwhile tweak? Suggestion: "create VM but do

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

roup/entry/the_2015_leap_second_s Cheers, Paul On Thu, Jun 9, 2016 at 8:40 AM, Roger Riggs <roger.ri...@oracle.com> wrote: > Hi Paul, > > Right, java.time cannot represent time with that precision. > > Roger > > On 6/8/2016 6:37 PM, Paul Benedict wrote: > > So doe

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

of some slight > inaccuracy, some of which > is unavoidable anyway without high precision sources. > > Roger > > > > On 6/8/2016 5:12 PM, Paul Benedict wrote: > > I might be wrong on this issue, but I think 24 could be valid -- but when > (if ever) is the question

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

I might be wrong on this issue, but I think 24 could be valid -- but when (if ever) is the question. Google was the news for their 61 second minute [1] in their "leap minute" adventure. I am not sure how time corrections are always implemented, but if you can have a leap minute, couldn't you also

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

Hi Sean, I just have a few minor comments. Nearly all the new messages follow the message/colon/space/details format. There are a few missing the space between the colon and details: *) ImageHeader: "jimage header not the correct size:" *) JrtPath throw new ProviderMismatchException("path

outOfBoundsExceptionFormatter needs @since 9

As subject line says. It's not present in 9b116 Cheers, Paul

Re: RFR(m): 8140281 deprecate Optional.get()

Are you asking Brian to set up another survey monkey for the masses? I expect a happy silent majority and a raucous minority just based on past results. :-) On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" wrote: I've yet to hear one supporter on this thread besides yourself

Re: @Deprecated(since) and Javadoc

quire both. The language annotation, with the new attribute, is now expressive enough for generation needs. Asking the developer to do both is wasteful effort, I think. On Apr 21, 2016 4:54 PM, "Stuart Marks" <stuart.ma...@oracle.com> wrote: > On 4/21/16 9:51 AM, Paul Benedict wrote

@Deprecated(since) and Javadoc

Is there a requirement that the new "since" attribute on @j.l.Deprecated lead to an automatic JavaDoc @deprecated in the doc generation? It's a bona fide replacement, right? I'm just curious because I think, if that's true, @j.l.Deprecated should mention this tool coordination in its own JavaDoc

Re: Expecting Integer.valueOf(String) to accept Literal format ...

I think the argument for changing Integer.valueOf(String) hinges on the belief that the method is meant to parse JLS integer syntax. If it is, the Javadocs don't speak to that responsibility. If it's an omission from the docs, I would never have guessed. Regarding how it parses today, I wouldn't

Re: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported

Since getCallerClass will be removed in 10, @Deprecated should also have its condemned=true Cheers, Paul On Wed, Apr 13, 2016 at 12:43 PM, Mandy Chung wrote: > > > On Apr 13, 2016, at 10:28 AM, Chris Hegarty > wrote: > > > > Mandy, > > > > On

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

The onXXX prefix does have precedent as event handler callbacks, but this method does not fit that purpose. Thus, I agree dropping "on" is sensible. On Feb 23, 2016 8:48 PM, "Vitaly Davidovich" wrote: > On Tuesday, February 23, 2016, Doug Lea wrote: > > >

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

I believe the answer should be based on your viewpoint of what "is" a JAR. Do you consider the JAR to be a dumb ZIP container or an artifact of the Java runtime? If it's the former, then return everything because the version folder is meaningless in this perspective. Otherwise, treat the JAR

Re: JDK 9 RFR to problem list a failing test

Unless there's a reason not to, sun.misc.BASE64Encoder can replaced with its equivalent java.util.Base64. Cheers, Paul On Wed, Dec 16, 2015 at 4:00 PM, Xueming Shen wrote: > + 1 > > > On 12/16/15, 1:58 PM, joe darcy wrote: > >> Hello, >> >> The test >> >>

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> The credit/blame for the Cleaner doc is mine. > > On 12/15/2015 10:25 AM, Paul Benedict wrote: > > David, this needs editing. > > * The cleaning function is invoked after the object it is cleaning up > after it > * becomes phantom reachable, so it is important that the

Re: General question: sun package -> jdk package?

at 1:48 PM, <mark.reinh...@oracle.com> wrote: > 2015/12/15 7:09 -0800, Paul Benedict <pbened...@apache.org>: > > I have a general question prompted by the many classes moved from sun.* > to > > jdk.*. Once JDK 9 delivers on the Module System and internals are no > long

General question: sun package -> jdk package?

I have a general question prompted by the many classes moved from sun.* to jdk.*. Once JDK 9 delivers on the Module System and internals are no longer exposed, is it planned to eventually migrate away from the sun.* legacy namespace in later JDK versions? Cheers, Paul

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

David, this needs editing. * The cleaning function is invoked after the object it is cleaning up after it * becomes phantom reachable, so it is important that the references and values * it needs do not prevent the object from becoming phantom reachable. 1) The "after it" looks like a leftover

Re: RFR: JDK-8057804: AnnotatedType interfaces provide no way to get annotations on owner type

Joel, some comments on AnnotatedType#getAnnotatedOwnerType(): * Is it convention to use tags to describe the complexity of the return value vs. just explaining it all in the @return tag? * What is the convention for @see nowadays? Is it 1.9 or 9? Cheers, Paul On Mon, Dec 7, 2015 at 2:29 PM,

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Chris, you raise a good question. Example: JPA entities stored in an immutable list and the list belongs to a stateful EJB that gets passivated or clustered. Obviously, serialization would be occuring. Cheers, Paul On Wed, Nov 25, 2015 at 10:14 AM, Chris Hegarty wrote:

Re: RFR: 8085984 Add JDBC Sharding API

Some comments: General *) Shouldn't the javadocs be put mentions of null in {@code null} tags? *) Many methods are documented to throw SQLFeatureNotSupportedException when sharding isn't supported, but the error message actually says "XYZ not implemented". Well I think that places an immediate

Re: RFR: 8085984 Add JDBC Sharding API

ort this method", which is a different condition. That's why I think the examples could be misleading. Cheers, Paul On Tue, Nov 24, 2015 at 9:31 AM, Paul Benedict <pbened...@apache.org> wrote: > Some comments: > > General > *) Shouldn't the javadocs be put mentions of null i

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

My comments: *) List.of() says it returns "the newly created list" but it actually returns the same empty list regardless. I don't think you want to imply a new list is actually constructed for each call. *) Map.of() same comment as above *) Set.of() same comment as above *)

Re: RFC: draft API for JEP 269 Convenience Collection Factories

I don't think the statements "Creates an unmodifiable set containing X elements" is always true. Since sets cannot have duplicates, it's possible passing in X elements gives you less than that based on equality. I think the Set docs should say "...X possible elements if unique". Wordsmith

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

In the database world, the function is COALESCE. And it's not just two arguments but the first non-null argument of any items. I would go with firstNonNull(Object a, Object b) and then provide an overload for a vararg. Cheers, Paul On Tue, Oct 6, 2015 at 10:48 AM, Ivan Gerasimov

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

rent code, it should return the 2nd > value regardless of whether it is null or not. > > Roger > > > > > On 10/6/2015 9:56 AM, Paul Benedict wrote: > > It's quite possible for the second argument to be null. Is that your > intention? I am not sure it makes sense,

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

It's quite possible for the second argument to be null. Is that your intention? I am not sure it makes sense, but it's not harmful either. I recommend you can either (1) explicitly document that's a possibility and this method could still return null or (2) prevent it by calling requireNonNull.

Re: RFR 8135248: Add utility methods to check indexes and ranges

+1 for having check methods start with 'require' .. that's a nice and useful naming pattern. On Wed, Sep 30, 2015 at 9:13 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > > - Mail original - > > De: "Paul Benedict" <pbened...@apache.org> > > À: &qu

Re: RFR 8135248: Add utility methods to check indexes and ranges

Ah, I was going to write about "values" ... glad this was mentioned. With Valhalla working on value classes, it does raise the question if range-checking is particular to Objects. Clearly it won't be once values are introduced. PS: I am still in favor of using Objects at the time being though

Re: RFR 8135248: Add utility methods to check indexes and ranges

It would be nice to introduce a Preconditions class (although I am not opposed to continue maturing Objects). I was waiting for the right time for this to be mentioned again (as it was mentioned in the past). Checking indices aren't the only thing we could add; another thing would be a method that

Javadoc new tags not yet documented

The JDK 8 documentation did not include any documentation on the new tags (e.g., @apiNote, @implSpec and @implNote). It's neither here [1] nor there [2], but they should be. Can anyone look into this for 9 (or even fix 8)? The absence of documentation is probably why they haven't seen widespread

Re: JDK 9 RFR of 4026465: Provide more byte array constructors for BigInteger

Please add @since 1.9 to the new constructors. Cheers, Paul On Tue, Dec 30, 2014 at 8:15 PM, joe darcy joe.da...@oracle.com wrote: Hi Brian, The new changes generally look good. A few comments, for the new code like 291 } else if ((off 0) || (off val.length) || (len 0) ||

Properties::setProperty should document NPE?

I accidentally passed a null to setProperty() and got an NPE. Okay. The javadoc says this method relies on Hashtable, which, in turn, is documented to throw an NPE when put() key/value is null. So, since setProperty() bubbles up the exception, I think this method should gain a @throws tag to make

Fwd: No for each loop comment?

Open JDKers, I am forwarding an email to get some clarification. It's been a common understanding that foreach should perform no differently than the equivalent for-loop . However, some fellow developers claim there is a noticable difference in their microbenchmarking. Can you help explain what is

Re: Fwd: No for each loop comment?

a...@redhat.com wrote: On 09/29/2014 03:29 PM, Paul Benedict wrote: Open JDKers, I am forwarding an email to get some clarification. It's been a common understanding that foreach should perform no differently than the equivalent for-loop . However, some fellow developers claim

Re: JDK RFR of 8054720: Modifications of I/O methods for instrumentation purposes

I'd like to propose some sort of comment (non-javadoc) preceding the methods to explain the pattern. Without the institutional day-to-day knowledge, I don't think it is apparent to an outside reader why these methods are crafted as such. The comment can be as simple as: // wrap native call to

Re: please review draft JEP: Convenience Factory Methods for Collections

Regarding why you didn't choose a straight vararg solution, I prefer you do allow any number of key/values as long as you throw an exception if the array is not an even sized. Cheers, Paul On Wed, Jul 16, 2014 at 8:58 PM, Stuart Marks stuart.ma...@oracle.com wrote: On 7/16/14 6:03 PM, Remi

Re: JDK 9 RFR of JDK-8048014: Update java.lang.SafeVararags for private methods

Will there be another ticket to update the section (9.6.4.7.) in JLS 9? Cheers, Paul On Tue, Jun 24, 2014 at 12:27 PM, Lance Andersen lance.ander...@oracle.com wrote: +1 On Jun 24, 2014, at 1:13 PM, Joe Darcy joe.da...@oracle.com wrote: Hello, Please review the libraries update

Re: RFR: 8047721: @since should have JDK version

What's the rationale for removing the secondary version? Or I guess the question should really be: when are secondary versions useful? At least in the EE specs, the EE version plus the spec version are listed in many places like this. Cheers, Paul On Mon, Jun 23, 2014 at 3:50 PM, Henry Jen

RFR: 8047721: @since should have JDK version

Henry, I think JCE1.2 should get the space to be JCE 1.2 so it matches other secondary versions like JNDI 1.1 (last part of your patch). Or, you could make that another cleanup in itself. Cheers, Paul

Re: RFR: 8046443 : A few typos in JAXP JavaDoc

This thread is a good reference on JDK 8's lint enforcement of HTML in javadoc. You can see the reasons behind not allowing self-enclosing tags and enforcing HTML: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/thread.html#19269 Cheers, Paul On Mon, Jun 16, 2014 at 11:33 PM,

Re: RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo

I like seeing JDK as well... primarily because IDEs have the ability to show javadoc snippets when hovering over an element. It's good to see what product the version comes relates to. Yet, on the other hand, these Oracle APIs are not published under JDK branding but under the title Java SE.

Re: RFR 9: 8003488 Add Process.getPid

Looks good. Don't forget @since 1.9 in the javadoc Cheers, Paul On Thu, May 22, 2014 at 8:49 AM, roger riggs roger.ri...@oracle.com wrote: Hi, The webrev has been updated to more completely describe the pid: The native process id is an identification number that the operating system

Re: RFR 9: 8003488 Add Process.getPid

I was thinking about this ticket today. Regarding Alan Bateman's comment that the pid may not be representable as an int/long, I was expecting some sort of Pid-like-object to be returned. I'd rather see an abstraction that *might* be able to convert into an int/long ... or even a String, as Martin

Re: Remove redundant calls of toString()

I have to say that the expected NPE is quite hidden in the current code. I am actually surprised someone was able to catch that. The use of Objects.requreNonNull() is way more clear and I prefer that approach for the sake of clarity. On Mon, Apr 28, 2014 at 8:28 AM, Otávio Gonçalves de Santana

Question on the per-build release notes

Regarding: http://download.java.net/jdk9/changes/jdk9-b06.html?q=download/jdk9/changes/jdk9-b06.html Currently the release notes have all the bug tickets pointing to bugs.java.com. At least when I try, none of the tickets load; I think this may have something to do with the move to JIRA. So, my

Re: Implicit 'this' return for void methods

What about opting in? By that, I mean that these void methods must have a specific TYPE_USE annotation on them at compile time to allow chaining. This idea would require a JLS update to allow type annotations on void return values -- perhaps exclusive to this annotation. On Mon, Mar 31, 2014 at

Re: Implicit 'this' return for void methods

It would be nice to make this language change. In the past years, it's pretty clear many JSR EE spec leads have gone on to make their APIs return the same object because they strongly prefer to see object chaining in code. I sympathize with those designers, but I don't agree; I wouldn't affect my

Re: Javadoc in 9 seems to treat all interfaces with only one method as functional interfaces

It's a bug because it was an early decision in JDK 8 that got changed: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-November/002379.html And then the change: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-January/024165.html On Thu, Mar 20, 2014 at 2:51 PM,

Re: JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems

What about providing a shell script with JDK 9 with functions to encode names? Users can then just source the file into their scripts and helper functions available to them. Hopefully this would alleviate dealing with special characters. On Tue, Mar 11, 2014 at 8:22 AM, Alan Bateman

Re: JEP 193: Enhanced Volatiles

Language Summit that the commonly held belief about annotations, is not in fact true. Regards, Jeroen -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Wednesday, March 5, 2014 16:19 To: Christoph

Re: JDK 9 RFR of JDK-8035452: Fix serial lint warnings in core libs

Joe, I find it interesting that you suppressed the serial warning on an abstract class. I'd like to know more about that. Is this a universal rule? Are serial uids not important for abstract classes? On Thu, Feb 20, 2014 at 2:33 PM, Joe Darcy joe.da...@oracle.com wrote: Hello, Please review

Re: RFR 9: 8034903: Add Logging of Process.start arguments and resulting pid

Roger, I only have two suggested improvements: 1) solaris/../ProcessImpl.java should use Objects.toString() rather than the tenary operator for a string choice. You did this alright in /windows/../ProcessImpl.java 2) /windows/../ProcessImpl.java doesn't need to specify null for

RFR: 8028816: Add value-type notice to Optional* classes

Florian, it's an idea I also broached but did not receive any feedback: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-December/002585.html The only downside to adding the annotation is that it makes it the official way to denote a value type. Based on some JEPs and Lambda

JavaDoc is indenting multiple documented annotations

On 10/16, I wrote: If you look at the current classes (b111) that have documented annotations, the first annotation is correctly left-aligned but all others are indented by one space. If this is already reported, my apologies; if not, please confirm. Example:

Re: JavaDoc is indenting multiple documented annotations

No, I didn't know such a list existed. But I do now :-) Thanks. I will send the message there. On Mon, Nov 25, 2013 at 1:07 PM, Alan Bateman alan.bate...@oracle.comwrote: On 25/11/2013 15:43, Paul Benedict wrote: On 10/16, I wrote: If you look at the current classes (b111) that have

JavaDoc is indenting documented annotations

If you look at the current classes (b111) that have documented annotations, the first annotation is correctly left-aligned but all others are indented by one space. If this is already reported, my apologies; if not, please confirm. Example:

Re: Review: demos for jdk8

I think there may be a problem with Console::close(). Even though the Console instance will be disposed in a try-with-resources construct, that doesn't the reader and writer are guaranteed to close together. Currently, if the reader fails to close, the writer will be left dangling. What do you

Review: demo extension methods (it is illustrates the feature default method usage)

ArrayIterator's javadoc uses a smart apostrophe which translates into a sequence of crazy ascii characters. -- Cheers, Paul

JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions

Eric, Should MalformedParametersException save IAE as the root cause? Or is that an internal detail you don't want leaked? Webrev updated to address these issues. On 09/24/13 07:51, Joel Borggren-Franck wrote: 364 try { 365 tmp = getParameters0(); 366

JDK-8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions

MalformedParametersException should receive a @since tag. Additionally, the javadoc doesn't describe what it means for a parameter to be malformed. The answer doesn't need to be exhaustive, but I think some examples would help developers if they catch one and need to dig into class files. Or if

Re: Enum.valueOf(String)

AM, Paul Benedict pbened...@apache.org wrote: I have been working with classes that don't have javadoc attachments. The problem was I couldn't find the method in the source nor was the method part of the Enum class. So where did it materialize from? Now I know the answer: the compiler generates

Re: Enum.valueOf(String)

in JLS 7, section 8.9. In particular, see 8.9.2, Enum Body Declarations, beginning at the line In addition, if E is the name of an enum type, then that type has the following implicitly declared static methods: -- Jon On 08/20/2013 06:27 AM, Paul Benedict wrote: Jon, it's not a problem

Re: Enum.valueOf(String)

be added to the Enum javadoc class. I had to go on quite a goose hunt to find this fact. Paul On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman alan.bate...@oracle.comwrote: On 18/08/2013 05:07, Paul Benedict wrote: I think the generated method needs to be listed in the class javadoc at least. I

Re: Enum.valueOf(String)

as an abstract method on the base class. If it were, then there could be JavaDoc for it. Nick On Aug 16, 2013, at 11:30 PM, Paul Benedict wrote: I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's part of every enum. Is this an oversight or is there a good reason why it's

Enum.valueOf(String)

I noticed this method is not listed in the Javadocs for 5/6/7/8 but it's part of every enum. Is this an oversight or is there a good reason why it's not documented? -- Cheers, Paul

Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

If it is not possible in the remaining dev time for JDK8 to expose Reflection.getCallerClass() functionality through some public API, why must -Djdk.reflect.allowGetCallerClass be discontinued so soon? Why the hot potato? I don't see how impacting the many (most? or all?) open source logging

Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

+1 with Nick. There's no point in submitting a patch unless someone who is in charge of Core Libs Dev is willing to first offer technical direction. Where does Oracle want to go with the solution? There are no official responses -- it's been quiet on their front for sometime. I don't know if that

@CallerSensitive as public API ?

I find this issue tangentially related to some open source logging libraries. Some create a stack trace just so they can get the name of the calling Class instance. Example: Logger log = Logger.createLogger(); // for the current class Are there any thoughts to directly exposing

@CallerSensitive as public API ?

That's true David. I concur with your description. I was just more interested in the fact that Java has the calling Class available, but there's no API that exposes it. Many developers kind of groan they always have to explicitly specify the current class name through the language. private

RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator)

Mike, I know the description is pulled from the previous constructor, but both sound a bit awkward. Both can probably benefit from an improvement. Currently: Creates a {@code PriorityQueue} with the default initial capacity that orders its elements according to the specified comparator.

RFR: 8017513: Support for closeable streams

Brian, you wrote: It would be utterly criminal if someone were to restructure the above code into the below code because some IDE inspection complained about must call close or use TWR. I agree here. However, the inheritance of AutoCloseable is going to likely prompt some kind of action by

Re: RFR: 8017513: Support for closeable streams

, it must be closed. That's the expected behavior when using this type. On Sun, Jul 14, 2013 at 10:53 PM, David Holmes david.hol...@oracle.comwrote: On 12/07/2013 11:57 PM, Paul Benedict wrote: I see closeability as a postcondition. A subtype can't weaken it. The contract of AutoCloseable

Re: RFR: 8017513: Support for closeable streams

: On 12/07/2013 6:22 AM, Paul Benedict wrote: Paul S.'s said the negative of using AutoCloseable is it is no longer clear whether a stream should be closed or not (6/20). That's true because the semantics of AutoCloseable indicates you have a resource that requires closing. However, the choice

Re: RFR: 8017513: Support for closeable streams

Paul S.'s said the negative of using AutoCloseable is it is no longer clear whether a stream should be closed or not (6/20). That's true because the semantics of AutoCloseable indicates you have a resource that requires closing. However, the choice to make MayHoldCloseableResource a sub-interface

Re: RFR: 8012665: CharSequence.chars, CharSequence.codePoints

line looks like less nested than the three before, which IMHO is a clear mistake. -Ulf Am 25.04.2013 22:57, schrieb Paul Benedict: Henry, I believe the coding standards require curly braces for any if-statement and for-loop. Also the return statements exceed the 80 character limit

RFR: 8012665: CharSequence.chars, CharSequence.codePoints

Henry, I believe the coding standards require curly braces for any if-statement and for-loop. Also the return statements exceed the 80 character limit. It would be nice to have them formatted across several lines like the following because it's difficult to read going straight across: return

Re: RFR: JDK-8011917 (java.util.stream.Collectors)

Brian, this is low-hanging fruit, but all descriptions after @param and @return should start with lowercase per published JavaDoc conventions. On Wed, Apr 17, 2013 at 2:26 PM, Brian Goetz brian.go...@oracle.com wrote: Single new source file at:

Suggestion to improve profile/package in javadoc

I was looking at b85 javadocs, and saw this at the page's top for a class: compact1, compact2, compact3 java.lang I don't think it's clear what is being shown. I understand it -- but I am following the feature closely. I recommend prefixing the data because the package is no longer the sole

JDK 8 code review request for 8011800: Add java.util.Objects.requireNonNull(T, SupplierString)

If obj is null and the supplier is also null, you will not get an NPE with the expected message. Since it's kind of odd to get an NPE constructing an NPE, I think: @throws NullPointerException if {@code obj} is {@code null} should be changed to: @throws NullPointerException if {@code obj} or

RFR : 8010948 : Add conversion functional interfaces

Mike, It would be nice if the class javadocs would have @see tags to classes in the same family. For example, DoubleToIntFunction could have a @see to DoubleToLongFunction, etc. This way a developer viewing of one class can easily figure out which close cousins exist. Paul

Re: Spliterator flags as enum (was Initial java.util.Spliterator putback)

I think the use of EnumSet in a public API is superior to bit flags. Worrying about the number of bytes here is not important since they will all end up being garbage collected when the stream processing ends. On Thu, Mar 28, 2013 at 6:56 PM, Vitaly Davidovich vita...@gmail.comwrote: Enum and

Re: Code review request: JDK-8008670 (partial java.util.stream implementation)

My comments... 1) TerminalOp: When default methods are very simple (i.e., a one-liner), you are sometimes (not always) putting the body on a new line. I think you should use a consistent coding style and always start the body on the next line. 2) I find X_IN and X_OUT type parameters to be

Proposal: Put @Native and @GenerateNativeHeader in same package

Compare the two javadocs: @java.lang.annotation.Native: Indicates that a field defining a constant value may be referenced from native code. The annotation may be used as a hint by tools that generate native header files to determine whether a header file is required, and if so, what declarations

Re: Proposal: Put @Native and @GenerateNativeHeader in same package

AM, Alan Bateman alan.bate...@oracle.comwrote: On 05/03/2013 15:15, Paul Benedict wrote: : Both are hints for tools. Both discuss header files. So why divide them up? I think they should be in one package together. Personally, I think both are better suited to the javax.tools.annotation

Re: Proposal: Put @Native and @GenerateNativeHeader in same package

Alan, Ah, that makes lots more sense! Glad to know the latter is getting deleted. I don't know the particulars of Jon's plans, but if you want to achieve the same functionality of both annotations, I suggest allowing @Native to @Target(PACKAGE). Paul On Tue, Mar 5, 2013 at 9:49 AM, Alan Bateman

Should packages be opened by default in javadoc?

jdk8b78 makes profiles the default view in the javadoc. However, I find that very disruptive to my usage; 99% of the time I will not be looking for profiles but locating packages. Since this is a new feature, I am sure there's room to hear feedback on the decision. Thanks, Paul

Suggestion: Add the method isEmpty in the classes StringBuilder and StringBuffer

Do you want isEmpty() for bean access, or empty() like Collections? Since there isn't a getLength() but just length() (and size() for collections), I think the latter would be preferred. Paul

RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals

I am chiming in to agree with Stephen. About a year ago, I encountered the same issue and was extremely dissatisfied with the behavior. I was forced to create a utility method to check for 0 before passing it onto stripTrailingZeros(). The current behavior is useless; the spec is clear stripping

  1   2   >