<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
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
&
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
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 <
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
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.
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
.
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
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
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
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
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
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
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
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
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
As subject line says. It's not present in 9b116
Cheers,
Paul
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
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
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
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
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
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:
>
> >
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
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
>>
>>
> 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
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
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
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,
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:
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
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
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
*)
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
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
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.
+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
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
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) ||
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
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
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
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
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
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
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
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,
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.
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 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
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
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
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
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
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,
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
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
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
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
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
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
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:
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
ArrayIterator's javadoc uses a smart apostrophe which translates into a
sequence of crazy ascii characters.
--
Cheers,
Paul
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
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
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
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
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
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
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 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.
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
, 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
:
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
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
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
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
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:
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
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 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
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
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
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
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
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 - 100 of 131 matches
Mail list logo