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:
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
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
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
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
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
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
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,
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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
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
This is very minor. Browsing the jdk8b75 javadoc, I noticed these classes
are missing their @since tags.
ProcessBuilder.Redirect.Type
Formatter.BigDecimalLayoutForm
Paul
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
:
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
, 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
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
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
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
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.
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
+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
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
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
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
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
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
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
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
ArrayIterator's javadoc uses a smart apostrophe which translates into a
sequence of crazy ascii characters.
--
Cheers,
Paul
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
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:
Joe,
The class documentation currently has a nice chronological history of
Throwable's features:
* Prior to release 1.4, there were many throwables that had their own
non-standard exception chaining mechanisms...
* Further, as of release 1.4, many general purpose
* Also introduced in release
Do it as two commits (one for diamond, the other for line formatting)
that way you can keep the work separate. You may even want 2 Sun
tracking issue in case you need to do several commits under one issue.
Paul
On Thu, Dec 16, 2010 at 10:43 PM, Joe Darcy joe.da...@oracle.com wrote:
On
I once heard/read that Sun had a policy where JDK N had to built with
the JDK N-1 compiler. I suppose that's not true anymore?
Ulf, a previous email by Remi said only to invoke size() if the collection
is a Set.
Paul
On Thu, Dec 23, 2010 at 4:24 PM, Ulf Zibis ulf.zi...@gmx.de wrote:
Am 23.12.2010 22:24, schrieb Ulf Zibis:
Aren't the explanation comments from my last example clear enough and more
fluently readable?
Maybe you have a nonNull() that throws NPE, and a nonNullSafe() ?
On Thu, Jan 13, 2011 at 3:12 PM, Tom Hawtin tom.haw...@oracle.com wrote:
On 13/01/2011 20:06, Brian Goetz wrote:
Most of the other methods in this class are of the form do the right
thing if the object is null (or an array),
Alternatively, we could use the as prefix already established in the JDK
-- since this function is a kind of conversion.
asNonNull(Object o, Object fallbackObj)
Paul
On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain jeffh...@rocketmail.com wrote:
Hello.
As Ulf said, I think requireNonNull could be
not what's being
discussed.
On 1/26/2011 10:44 AM, Paul Benedict wrote:
Alternatively, we could use the as prefix already established in the
JDK -- since this function is a kind of conversion.
asNonNull(Object o, Object fallbackObj)
Paul
On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain jeffh
Joe, I like how you snuck a little tribute to Leslie Nielsen in the test:
Nothing to see here, move along
http://www.youtube.com/watch?v=5NNOrp_83RU
On Fri, Feb 18, 2011 at 5:55 PM, joe.da...@oracle.com wrote:
Changeset: 75e25df50873
Author:darcy
Date: 2011-02-18 15:55 -0800
URL:
To the community,
Is there any easily identifiable way to determine when IBM contributes
fixes/patches to the repositories? I know all Oracle employees have Oracle
email addresses. What about those from IBM? I was hoping to see what they
contribute since they joined OpenJDK.
Thanks!
Paul
organizational logistic issues which resulted in a slow start but
the pace can be expected to increase.
Mike
On Feb 25 2011, at 21:48 , Dr Andrew John Hughes wrote:
On 25 February 2011 20:15, Paul Benedict pbened...@apache.org wrote:
To the community,
Is there any easily identifiable way
is all a very
big and exciting experiment on large software development. So as I read the
patches as they go by, it's interesting to see who is contributing what.
Paul
On Tue, Mar 1, 2011 at 4:23 AM, Steve Poole spo...@linux.vnet.ibm.comwrote:
On Fri, 2011-02-25 at 14:15 -0600, Paul Benedict wrote
I've always found it a bit perplexing that java.lang was never chosen
for the parent package of the Dynamic API. Why is that? Dynamic types
are now part of the language as proven by spec itself and exotic
identifiers. Will this be reconsidered?
Paul
, Paul Benedict wrote:
I've always found it a bit perplexing that java.lang was never chosen
for the parent package of the Dynamic API. Why is that? Dynamic types
are now part of the language as proven by spec itself and exotic
identifiers. Will this be reconsidered?
[I'm forwarding
.
Paul
On Sun, Oct 4, 2009 at 6:34 PM, Stepan Koltsov y...@mx1.ru wrote:
On Sun, Oct 4, 2009 at 15:40, Rémi Forax fo...@univ-mlv.fr wrote:
Le 04/10/2009 11:39, Christian Thalinger a écrit :
On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
I've always found it a bit perplexing
Joe,
Here are a few more resources that you may want to investigate for
java.util.Objects:
*
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html
*
+1 for me.
+1 also for having the overloaded version that can accept a fallback string.
Paul
Joe,
I'm preparing the first round of java.util.Objects with the
single-argument static toString method return null for null for final
review.
Why would you choose to return null for any null object? Everyone
who has opined did disagree with replicating String.valueOf()
behavior. I don't see
Why would you choose to return null for any null object?
Because that is how the platform has always treated null in string
concatenation.
If you were defining new operations for String, StringBuilder, or
StringBuffer, I would agree with your choice. Since you are now
defining a global
Joe,
I think java.util.Objects could benefit from the final modifier.
Since its constructor always fails, there is no reason to subclass it
(i.e., super constructor always fails). I believe Josh's Effective
Java book makes such a point about static utility classes.
Paul
Joe,
Classes with only private constructors, like j.u.Objects, are effectively
final. Adding final is harmless but unnecessary in these cases.
Understood, but the keyword (pun) here is effectively. Why let a
developer wait until runtime to find out his code will fail? At least
by marking the
Thank you, Bob. I stand corrected.
On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee crazy...@crazybob.org wrote:
On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict pbened...@apache.org wrote:
Understood, but the keyword (pun) here is effectively. Why let a
developer wait until runtime to find out his code
the compiler will warn
about this issue (thank you Bob), the next consideration is for those
who are reading the docs online.
Paul
On Fri, Oct 9, 2009 at 9:07 PM, Bob Lee crazy...@crazybob.org wrote:
On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict pbened...@apache.org wrote:
Understood
Joe,
I am confused over this warning:
* bWarning: When a single object reference is supplied, the returned
* value does not equal the hash code of that object reference./b This
* value can be computed by calling {...@link #hashCode(Object)}.
I first looked into Arrays#deepHashCode and did not
Stephen,
My interpretation of Joe's email was that it would stay in j.u.Objects
unless someone (other than him) contributes the Validate class and
tests. Granting your point, his choice would otherwise stand and
re-factoring it after JDK 7 would be impossible.
I am interested in such a class and
I saw in the release notes the tickets regarding j.u.Objects, but I
don't see the class in the javadoc:
http://download.java.net/jdk7/docs/api/java/util/package-summary.html
Thoughts?
Paul
All the labels and titles on the API doc say its b74, so it must be
some generation problem.
On Fri, Oct 16, 2009 at 4:14 PM, Joseph D. Darcy joe.da...@sun.com wrote:
Paul Benedict wrote:
I saw in the release notes the tickets regarding j.u.Objects, but I
don't see the class in the javadoc
. j.u.Objects will be included in the next build TL
integrates into.
-Joe
Paul Benedict wrote:
All the labels and titles on the API doc say its b74, so it must be
some generation problem.
On Fri, Oct 16, 2009 at 4:14 PM, Joseph D. Darcy joe.da...@sun.com
wrote:
Paul Benedict wrote
I actually don't need closures to accomplish this. Now this solution I
wouldn't recommend for the JDK, but a subclass of Map could
automatically do the management of the inner collections for me.
Paul
Holmes - Sun Microsystems
david.hol...@sun.com wrote:
Paul,
Paul Benedict said the following on 11/15/09 11:28:
I would like to propose adding this method:
/**
* Selects the object if not {...@code null}; otherwise fallsback to the
* specified default object.
*
* @param object the object
Lance,
There is a small typo in the javadoc. For method
generatedKeyAlwaysReturned, indexe(s) should be index(es)
Paul
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
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) ||
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
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
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
+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
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
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
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,
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.
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,
> 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
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
1 - 100 of 131 matches
Mail list logo
