On 11/09/2013 03:50, David M. Lloyd wrote:
I'm aware of that; however I guarantee you that if you try to munge
this functionality up with the concept of exported classes or packages
before the module system is realized, it's going to end up wrong and
we'll have yet more dead cruft in the API.
On 09/10/2013 06:26 PM, Joseph Darcy wrote:
On 9/10/2013 10:08 AM, David M. Lloyd wrote:
On 09/10/2013 11:54 AM, Mandy Chung wrote:
On 9/10/13 9:47 AM, Joe Darcy wrote:
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, [email protected] wrote:
:
Well, looking ahead to wh
On 9/10/2013 10:08 AM, David M. Lloyd wrote:
On 09/10/2013 11:54 AM, Mandy Chung wrote:
On 9/10/13 9:47 AM, Joe Darcy wrote:
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, [email protected] wrote:
:
Well, looking ahead to when the platform will be composed of modules,
On 9/10/13 9:47 AM, Joe Darcy wrote:
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, [email protected] wrote:
:
Well, looking ahead to when the platform will be composed of modules,
those modules will declare that they "export" some API elements, but
not others. An @Expo
On 09/10/2013 11:54 AM, Mandy Chung wrote:
On 9/10/13 9:47 AM, Joe Darcy wrote:
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, [email protected] wrote:
:
Well, looking ahead to when the platform will be composed of modules,
those modules will declare that they "export"
On 9/10/2013 6:28 AM, Alan Bateman wrote:
On 06/09/2013 04:23, [email protected] wrote:
:
Well, looking ahead to when the platform will be composed of modules,
those modules will declare that they "export" some API elements, but
not others. An @Exported annotation would help get people
On 06/09/2013 04:23, [email protected] wrote:
:
Well, looking ahead to when the platform will be composed of modules,
those modules will declare that they "export" some API elements, but
not others. An @Exported annotation would help get people used to
the expected future terminology.
@
On 9/5/2013 8:23 PM, [email protected] wrote:
2013/9/5 12:33 -0700, [email protected]:
IMO, the high order goal here should be getting the "is this API okay to
use" information encoded into the source code and class files. Given
that you've already compiled that information, I think th
2013/9/5 12:33 -0700, [email protected]:
> IMO, the high order goal here should be getting the "is this API okay to
> use" information encoded into the source code and class files. Given
> that you've already compiled that information, I think there is great
> value in going forward with this
On 9/5/2013 2:20 AM, Alan Bateman wrote:
On 20/03/2013 01:32, Joseph Darcy wrote:
Following up in the same thread, the JEP for this work is now
available for your reading pleasure at:
JEP 179: Document JDK API Support and Stability
http://openjdk.java.net/jeps/179
Joe - do you want t
On 20/03/2013 01:32, Joseph Darcy wrote:
Following up in the same thread, the JEP for this work is now
available for your reading pleasure at:
JEP 179: Document JDK API Support and Stability
http://openjdk.java.net/jeps/179
Joe - do you want to reboot this discussion? With the deadlin
On 3/14/2013 10:14 AM, Joe Darcy wrote:
FYI, I've submitted a JEP reviewed by Alan Bateman on "Capturing
support and stability information about JDK classes in source and
class files."
Following up in the same thread, the JEP for this work is now available
for your reading pleasure at:
2013/3/15 17:16 -0400, [email protected]:
> On 03/15/2013 02:12 PM, [email protected] wrote:
>> ...
>>
>> What I'm trying to understand is, for a JDK API that's @Supported(true)
>> in one or more releases, what's the recommended protocol for removing
>> it? Perhaps something like this?
That isn't at all what @deprecated means.
"Encouraged for new development" doesn't mean everything else is
@deprecated.
These are all part of the Java SE platform spec, and are documented as
such
and are fully supported .. a focus on compatibility is very important
to a lot
of our customers
That isn't at all what @deprecated means.
"Encouraged for new development" doesn't mean everything else is
@deprecated.
These are all part of the Java SE platform spec, and are documented as such
and are fully supported .. a focus on compatibility is very important to
a lot
of our customers,
1. I suspect that the percentage of deprecated APIs is less than 0.1 % ..
So removing 1 ouf every 1,000 methods is not exactly going to make
a huge difference here.
2. Some methods were deprecated at a time when the policy was to
encourage people to use "newer" API, even though there
1. I suspect that the percentage of deprecated APIs is less than 0.1 % ..
So removing 1 ouf every 1,000 methods is not exactly going to make
a huge difference here.
2. Some methods were deprecated at a time when the policy was to
encourage people to use "newer" API, even though there w
I'm continually surprised by developers I meet at conferences who
(sometimes angrily) demand that deprecated APIs be removed, so I think
the reality is a mixed bag -- not that it matters a great deal either
way.
Just a personal opinion as a developer. Java APIs are very big and
removing deprecate
On 03/15/2013 02:12 PM, [email protected] wrote:
2013/3/4 2:58 -0800, [email protected]:
On 02/28/2013 11:31 AM, [email protected] wrote:
2013/2/23 5:10 -0800, [email protected]:
Having Supported take a boolean value both allows the explicit statement
that an item is not su
2013/3/4 2:58 -0800, [email protected]:
> On 02/28/2013 11:31 AM, [email protected] wrote:
>> 2013/2/23 5:10 -0800, [email protected]:
>>> Having Supported take a boolean value both allows the explicit statement
>>> that an item is not supported as well as providing a possible transiti
FYI, I've submitted a JEP reviewed by Alan Bateman on "Capturing support
and stability information about JDK classes in source and class files."
-Joe
On 02/28/2013 11:31 AM, [email protected] wrote:
2013/2/23 5:10 -0800, [email protected]:
On 2/22/2013 3:04 PM, [email protected] wrote:
...
- The annotation isn't a simple marker annotation, which is what I
expected at first glance; it takes a boolean parameter. Does this
me
On 03/04/2013 02:28 AM, Alan Bateman wrote:
On 28/02/2013 19:31, [email protected] wrote:
:
[snip]
I did just notice that the annotation's source file is in the langtools
repo rather than the jdk repo. What's the rationale for that? I think
most JDK developers would expect to find
On 28/02/2013 19:31, [email protected] wrote:
:
If we're going to define a new annotation with this much visibility then
we should at least take the time to inventory the JDK-specific APIs that
we have, and those we reasonably expect to have in the near future, to
understand how many dist
Regarding if 2 or more levels are necessary, it can easily be solved by
introducing a family of annotations. I suggest abandoning the boolean
attribute in favor of (something like) @Supported, @NotSupported,
@Experimental, etc. You may likely find the need to express individual
attributes at each "
2013/2/23 5:10 -0800, [email protected]:
> On 2/22/2013 3:04 PM, [email protected] wrote:
>> ...
>>
>> - The annotation isn't a simple marker annotation, which is what I
>> expected at first glance; it takes a boolean parameter. Does this
>> mean that we have to go add "@Supported(false
On 2/22/2013 3:04 PM, [email protected] wrote:
I understand (deeply!) the problem that @Supported is trying to solve.
Martin has raised a number of good questions about it already. Here are
some additional concerns I'd like to see addressed before we use it any
further in our source code.
mailto:core-libs-dev-
> [email protected]] On Behalf Of Martin Buchholz
> Sent: Saturday, February 23, 2013 0:42
> To: [email protected]
> Cc: [email protected]
> Subject: Re: @Supported design issues
>
> One more thought. @Supported has RUNTIME retent
One more thought. @Supported has RUNTIME retention, and it will be
inevitable that some people will check the annotation at runtime. As a
practical matter, once the annotation is added, it will never be removed
(or removed only if the corresponding API is itself removed), (for fear of
breaking so
I understand (deeply!) the problem that @Supported is trying to solve.
Martin has raised a number of good questions about it already. Here are
some additional concerns I'd like to see addressed before we use it any
further in our source code. (I've been unable to find any earlier
discussion or co
30 matches
Mail list logo
