Hi,
Any feedback on the top-level repository changes?
http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/
Thanks!
Jan
On 13.9.2016 16:28, Jan Lahoda wrote:
Hello,
I've updated the patch to the current situation. The top-level
repository patch is here:
http://cr.openjdk.java.net/~jlahoda/8153362/top-level.03/
Langtools repository patch is here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.04-phase2/
Does this look OK?
Thanks,
Jan
On 17.6.2016 16:18, Jan Lahoda wrote:
Hi,
I've updated the patches, reflecting the feedback so far.
The langtools change is now split into two parts, one is only adding the
new lint key (but no checks are actually performed):
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase1/
And the second part is adding the checks:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.01-phase2/
We could push the first part first, and the second one together with
other changes later, so that the repositories don't have to be updated
in a lockstep.
In addition to the langtools changes, only the top-level repository
needs to be changed now, to disable the checks in some modules:
http://cr.openjdk.java.net/~jlahoda/8153362/top-level.01/
Any feedback is welcome!
Thanks,
Jan
On 14.6.2016 14:29, Jan Lahoda wrote:
Hi Alan,
On 14.6.2016 12:57, Alan Bateman wrote:
On 13/06/2016 17:12, Jan Lahoda wrote:
Hello,
There is:
https://bugs.openjdk.java.net/browse/JDK-8153362
which is about a new warning that should be produced by javac when
exported API refers to types not exported/accessible to the API
clients.
I've put my current javac change here:
http://cr.openjdk.java.net/~jlahoda/8153362/langtools.00/
Did you have a short list of names for the lint option before deciding
on "unexportedinapi"? If time has already been put into this and
this is
I had a few (e.g. "publishingunexported"), but none of them particularly
nice.
the best of a bad bunch then ignore my mail. I bring it up because it
feels more like a "potentiallynotaccessible" or "notaccessible" or
"leaksnotaccessible". For the cases where we have ended up with
I like "leaksnotaccessible". Unless there would be better ideas or
objections, I'd go with that. Thanks for the ideas!
protected fields in public classes but the field type is
package-private
then the field is never accessible. For the JSObject.getWindow case
then
consumers will need to require java.desktop to use this method.
Related is the description:
javac.opt.Xlint.desc.unexportedinapi=\
Warn about use of types not visible to clients in exported API
Shouldn't get say something about the type potentially not accessible
rather than visible?
Yes, it should. I'll fix that. Thanks for catching that.
Jan
-Alan
PS: You asked about the JVMCI classes in the hotspot repo. While this
might look strange then it is intentional. The "framework" uses the
reflective APIs to export the otherwise internal packages to the JVMCI
implementation when it is located and loaded.
