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, mark.reinh...@oracle.com 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.
@Exported is quite good, and consistent with where this is likely
going.
Joe - what would you think of just running with this? I'm anxious
that we decide on this soon so that we don't run out of time in jdk8.
I don't object to using @Exported.
I like @Exported as well.
If we're framing it in terms of modules, I think it would make more
sense to have exporting be default and "hidden" be opt-in.
And, while we're at it, "hidden" really ought to apply at a package
level, not a class level.
In other words: don't make this about modularity.
To bring in some of the initial context, this feature is about
documenting and formalizing the historically unclear
exported-ness/supported-ness of types in the com.sun.* packages. Some
com.sun.* types are intended to be used outside of the JDK while others
are not.
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.
To bring clarity to this situation, I'd like to see each type and
package in com.sun.* either have an explicit @Exported(true) XOR
@Exported(false) annotation applied to it. This make a clear statement
around the intentions of the type and will allow better tooling to be
written.
"Plus one" for this, modulo a request to not use the term "Exported"
and/or not make this annotation part of the public API.
--
- DML
