Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

On Mon, Nov 28, 2016 at 11:49 AM, Alan Bateman 
wrote:

> On 28/11/2016 10:36, Stéphane Nicoll wrote:
>
> Peter,
>>
>> Thanks a lot, that helped! [1]
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://github.com/spring-projects/spring-boot/commit/e15b3e
>> 463f312524495349673a16cb67cfaa2eae
>>
>> The reflection has come up a number of things so great that Peter tracked
> this down.
>
> So I'm curious why this code uses core reflection. Is it because it
> sometimes runs on the JRE that didn't have javac implementation (or
> jdk.compiler module in JDK 9).


Eclipse users usually use the eclipse compiler and the annotation processor
is supposed to kick in in the IDE as well. When you generate the meta-data
in eclipse, default values are not available which is annoying. Again,
we're not happy _at all_ with that code and would prefer to use some
standard contract from javax.lang.model.

I'll ask on compiler-dev if there is a better way.

Thanks!
S.



>
>
> -Alan
>

Re: Replacement for JDK8 APIs

[Alan Bateman]

On 28/11/2016 10:36, Stéphane Nicoll wrote:


Peter,

Thanks a lot, that helped! [1]

Cheers,
S.

[1]
https://github.com/spring-projects/spring-boot/commit/e15b3e463f312524495349673a16cb67cfaa2eae

The reflection has come up a number of things so great that Peter 
tracked this down.


So I'm curious why this code uses core reflection. Is it because it 
sometimes runs on the JRE that didn't have javac implementation (or 
jdk.compiler module in JDK 9).


-Alan

Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

Peter,

Thanks a lot, that helped! [1]

Cheers,
S.

[1]
https://github.com/spring-projects/spring-boot/commit/e15b3e463f312524495349673a16cb67cfaa2eae

On Mon, Nov 28, 2016 at 10:50 AM, Peter Levart 
wrote:

>
>
> On 11/28/2016 10:39 AM, Peter Levart wrote:
>
>> final class Trees extends ReflectionWrapper {
>>
>> private Trees(Object instance) {
>> super(com.sun.source.util.Trees.class, instance);
>> }
>>
>
> ...ah, you would probably want to use 
> Class.forName("com.sun.source.util.Trees")
> above...
>
> Peter
>
>

Re: Replacement for JDK8 APIs

[Peter Levart]

On 11/28/2016 10:39 AM, Peter Levart wrote:

final class Trees extends ReflectionWrapper {

private Trees(Object instance) {
super(com.sun.source.util.Trees.class, instance);
} 


...ah, you would probably want to use 
Class.forName("com.sun.source.util.Trees") above...


Peter

Re: Replacement for JDK8 APIs

[Peter Levart]

Hi Stephan,

I thin this is a classical problem with reflection access checking that 
existed before jigsaw, but is now encountered even more frequently. The 
problem is that your ReflectionWrapper, given an instnace of some 
object, takes its runtime Class and searches methods in that class. The 
runtime class of the object may not be accessible to the world (i.e. the 
ReflectionWrapper). When you search for a method in such class you may 
end up with a Method object that represents the method declared in such 
inaccessible class (in your example, this seems to be 
com.sun.tools.javac.api.JavacTrees::getTree(Element)). Access checks for 
such method then fail, because com.sun.tools.javac.api.JavacTrees is not 
publicly accessible (it is in a non-exported package).


I recommend that you modify your ReflectionWrapper so that it takes a 
"Class type" parameter in addition to the "Object instance" and then use 
this "type" (which should always represent some publicly accessible 
supertype of the runtime type of the instance) to search for methods...


ReflectionWrapper(Class type, Object instance) {
this.type = type;
this.instance = type.cast(instance);
}


And then:

final class Trees extends ReflectionWrapper {

private Trees(Object instance) {
super(com.sun.source.util.Trees.class, instance);
}

...


I think this should work.


Regards, Peter


On 11/28/2016 09:41 AM, Stéphane Nicoll wrote:

Jon,

We invoke `com.sun.source.util.Trees#instance(ProcessingEnvironment)`
reflectively[1] as this class may not be available. This gives us access to
`Tree` that we handle reflectively as well[2]. There is no reference
anywhere to com.sun.tools.javac.api.JavacTrees in our codebase so I guess
this exception is an attempt of us invoking that method reflectively?

In any case, that's what we ended up doing to retrieve the init value of
fields in an annotation processor. If there is any other way using a public
API, I am more happy than replace that code. Should I raise that question
on compiler-dev?

Thanks a lot,
S.




[1]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Trees.java#L41-L46
[2]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Tree.java


On Sun, Nov 27, 2016 at 4:57 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:


Stéphan,

You say you are using com.sun.tools.javac.api.JavacTrees. Although that
class is not exported from jdk.compiler, it is an implementation of the
interface com.sun.source.util.Trees, which is exported.  Is the interface
sufficient to your needs? If not, what methods are you calling?

-- Jon



On 11/27/16 1:16 AM, Stéphane Nicoll wrote:


Hey,

Thanks for all the feedback so far. Any idea about the annotation
processor
question? Is there a dedicated dev list for it maybe?

Thank you,
S.


On Thu, Nov 24, 2016 at 3:22 PM, Stéphane Nicoll 
wrote:

Hi,

I am working on the Spring Boot project[1] and I am trying to make sure
our codebase compiles with the current JDK9 build[2]. So far I've hit two
major issues:

We use "sun.misc.VMSupport" to retrieve the port being used by the Java
remote debugging. You can find the actual code in
RemoteDebugPortProvider[3]

We have an annotation processor that inspects all classes annotated with
@ConfigurationProperties and generates some meta-data about them. One
important piece of this is to extract the default value assigned to
fields.
Consider the following example

@ConfigurationProperties
public class Foo {

private static final String DEFAULT_NAME = "name";

private String name = DEFAULT_NAME;

private Integer counter = 42;

private List hosts = Collections.singletonList("localhost");


}

What we've build is a visitor that navigates to those elements and
extracts the default values assigned to each field, including navigating
to
parent element (the "name" constant there) or inferring value from method
parameters ("localhost"). The  current code relies on a feature of the
JDK
that is no longer exported[4]:


java.lang.IllegalAccessException: class org.springframework.boot.
configurationprocessor.fieldvalues.javac.Trees cannot access class
com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because
module jdk.compiler does not export com.sun.tools.javac.api to unnamed
module @5a7fe64


Does anybody has some insight as how we could migrate those two use
cases?
In particular, the second use case could be implemented with a contract
of
javax.lang.model but we haven't found how to do it.

Thank you,
S.



[1] https://github.com/spring-projects/spring-boot
[2] 

Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

Jon,

We invoke `com.sun.source.util.Trees#instance(ProcessingEnvironment)`
reflectively[1] as this class may not be available. This gives us access to
`Tree` that we handle reflectively as well[2]. There is no reference
anywhere to com.sun.tools.javac.api.JavacTrees in our codebase so I guess
this exception is an attempt of us invoking that method reflectively?

In any case, that's what we ended up doing to retrieve the init value of
fields in an annotation processor. If there is any other way using a public
API, I am more happy than replace that code. Should I raise that question
on compiler-dev?

Thanks a lot,
S.




[1]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Trees.java#L41-L46
[2]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Tree.java


On Sun, Nov 27, 2016 at 4:57 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:

> Stéphan,
>
> You say you are using com.sun.tools.javac.api.JavacTrees. Although that
> class is not exported from jdk.compiler, it is an implementation of the
> interface com.sun.source.util.Trees, which is exported.  Is the interface
> sufficient to your needs? If not, what methods are you calling?
>
> -- Jon
>
>
>
> On 11/27/16 1:16 AM, Stéphane Nicoll wrote:
>
>> Hey,
>>
>> Thanks for all the feedback so far. Any idea about the annotation
>> processor
>> question? Is there a dedicated dev list for it maybe?
>>
>> Thank you,
>> S.
>>
>>
>> On Thu, Nov 24, 2016 at 3:22 PM, Stéphane Nicoll 
>> wrote:
>>
>> Hi,
>>>
>>> I am working on the Spring Boot project[1] and I am trying to make sure
>>> our codebase compiles with the current JDK9 build[2]. So far I've hit two
>>> major issues:
>>>
>>> We use "sun.misc.VMSupport" to retrieve the port being used by the Java
>>> remote debugging. You can find the actual code in
>>> RemoteDebugPortProvider[3]
>>>
>>> We have an annotation processor that inspects all classes annotated with
>>> @ConfigurationProperties and generates some meta-data about them. One
>>> important piece of this is to extract the default value assigned to
>>> fields.
>>> Consider the following example
>>>
>>> @ConfigurationProperties
>>> public class Foo {
>>>
>>>private static final String DEFAULT_NAME = "name";
>>>
>>>private String name = DEFAULT_NAME;
>>>
>>>private Integer counter = 42;
>>>
>>>private List hosts = Collections.singletonList("localhost");
>>>
>>>
>>> }
>>>
>>> What we've build is a visitor that navigates to those elements and
>>> extracts the default values assigned to each field, including navigating
>>> to
>>> parent element (the "name" constant there) or inferring value from method
>>> parameters ("localhost"). The  current code relies on a feature of the
>>> JDK
>>> that is no longer exported[4]:
>>>
>>>
>>> java.lang.IllegalAccessException: class org.springframework.boot.
>>> configurationprocessor.fieldvalues.javac.Trees cannot access class
>>> com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because
>>> module jdk.compiler does not export com.sun.tools.javac.api to unnamed
>>> module @5a7fe64
>>> 
>>>
>>> Does anybody has some insight as how we could migrate those two use
>>> cases?
>>> In particular, the second use case could be implemented with a contract
>>> of
>>> javax.lang.model but we haven't found how to do it.
>>>
>>> Thank you,
>>> S.
>>>
>>>
>>>
>>> [1] https://github.com/spring-projects/spring-boot
>>> [2] https://github.com/spring-projects/spring-boot/issues/7226
>>> [3] https://github.com/spring-projects/spring-boot/blob/
>>> master/spring-boot-devtools/src/main/java/org/
>>> springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java
>>> [4] https://github.com/spring-projects/spring-boot/blob/
>>> master/spring-boot-tools/spring-boot-configuration-
>>> processor/src/main/java/org/springframework/boot/configurationprocessor/
>>> fieldvalues/javac/Trees.java
>>>
>>>
>>>
>>>
>>>
>>>
>

Re: Replacement for JDK8 APIs

[Jonathan Gibbons]

Stéphan,

You say you are using com.sun.tools.javac.api.JavacTrees. Although that 
class is not exported from jdk.compiler, it is an implementation of the 
interface com.sun.source.util.Trees, which is exported.  Is the 
interface sufficient to your needs? If not, what methods are you calling?


-- Jon


On 11/27/16 1:16 AM, Stéphane Nicoll wrote:

Hey,

Thanks for all the feedback so far. Any idea about the annotation processor
question? Is there a dedicated dev list for it maybe?

Thank you,
S.


On Thu, Nov 24, 2016 at 3:22 PM, Stéphane Nicoll  wrote:


Hi,

I am working on the Spring Boot project[1] and I am trying to make sure
our codebase compiles with the current JDK9 build[2]. So far I've hit two
major issues:

We use "sun.misc.VMSupport" to retrieve the port being used by the Java
remote debugging. You can find the actual code in RemoteDebugPortProvider[3]

We have an annotation processor that inspects all classes annotated with
@ConfigurationProperties and generates some meta-data about them. One
important piece of this is to extract the default value assigned to fields.
Consider the following example

@ConfigurationProperties
public class Foo {

   private static final String DEFAULT_NAME = "name";

   private String name = DEFAULT_NAME;

   private Integer counter = 42;

   private List hosts = Collections.singletonList("localhost");


}

What we've build is a visitor that navigates to those elements and
extracts the default values assigned to each field, including navigating to
parent element (the "name" constant there) or inferring value from method
parameters ("localhost"). The  current code relies on a feature of the JDK
that is no longer exported[4]:


java.lang.IllegalAccessException: class org.springframework.boot.
configurationprocessor.fieldvalues.javac.Trees cannot access class
com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because
module jdk.compiler does not export com.sun.tools.javac.api to unnamed
module @5a7fe64


Does anybody has some insight as how we could migrate those two use cases?
In particular, the second use case could be implemented with a contract of
javax.lang.model but we haven't found how to do it.

Thank you,
S.



[1] https://github.com/spring-projects/spring-boot
[2] https://github.com/spring-projects/spring-boot/issues/7226
[3] https://github.com/spring-projects/spring-boot/blob/
master/spring-boot-devtools/src/main/java/org/
springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java
[4] https://github.com/spring-projects/spring-boot/blob/
master/spring-boot-tools/spring-boot-configuration-
processor/src/main/java/org/springframework/boot/configurationprocessor/
fieldvalues/javac/Trees.java

Re: Replacement for JDK8 APIs

[Alan Bateman]

On 27/11/2016 09:16, Stéphane Nicoll wrote:

Hey,

Thanks for all the feedback so far. Any idea about the annotation processor
question? Is there a dedicated dev list for it maybe?


compiler-dev is the place to bring it up.

-Alan

Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

Hey,

Thanks for all the feedback so far. Any idea about the annotation processor
question? Is there a dedicated dev list for it maybe?

Thank you,
S.


On Thu, Nov 24, 2016 at 3:22 PM, Stéphane Nicoll  wrote:

> Hi,
>
> I am working on the Spring Boot project[1] and I am trying to make sure
> our codebase compiles with the current JDK9 build[2]. So far I've hit two
> major issues:
>
> We use "sun.misc.VMSupport" to retrieve the port being used by the Java
> remote debugging. You can find the actual code in RemoteDebugPortProvider[3]
>
> We have an annotation processor that inspects all classes annotated with
> @ConfigurationProperties and generates some meta-data about them. One
> important piece of this is to extract the default value assigned to fields.
> Consider the following example
>
> @ConfigurationProperties
> public class Foo {
>
>   private static final String DEFAULT_NAME = "name";
>
>   private String name = DEFAULT_NAME;
>
>   private Integer counter = 42;
>
>   private List hosts = Collections.singletonList("localhost");
>
>
> }
>
> What we've build is a visitor that navigates to those elements and
> extracts the default values assigned to each field, including navigating to
> parent element (the "name" constant there) or inferring value from method
> parameters ("localhost"). The  current code relies on a feature of the JDK
> that is no longer exported[4]:
>
>
> java.lang.IllegalAccessException: class org.springframework.boot.
> configurationprocessor.fieldvalues.javac.Trees cannot access class
> com.sun.tools.javac.api.JavacTrees (in module jdk.compiler) because
> module jdk.compiler does not export com.sun.tools.javac.api to unnamed
> module @5a7fe64
> 
>
> Does anybody has some insight as how we could migrate those two use cases?
> In particular, the second use case could be implemented with a contract of
> javax.lang.model but we haven't found how to do it.
>
> Thank you,
> S.
>
>
>
> [1] https://github.com/spring-projects/spring-boot
> [2] https://github.com/spring-projects/spring-boot/issues/7226
> [3] https://github.com/spring-projects/spring-boot/blob/
> master/spring-boot-devtools/src/main/java/org/
> springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java
> [4] https://github.com/spring-projects/spring-boot/blob/
> master/spring-boot-tools/spring-boot-configuration-
> processor/src/main/java/org/springframework/boot/configurationprocessor/
> fieldvalues/javac/Trees.java
>
>
>
>
>

Re: Replacement for JDK8 APIs

[Alan Bateman]

On 25/11/2016 12:11, Stéphane Nicoll wrote:


:

Yes, there is a feature in Spring Boot called devtools that allows you 
do remote debugging via SSH[1] - Is there any way to achieve the same 
feature with JDK 9?


Nothing has really changed here, it's just that some JDK internal 
classes have moved and of course they are no longer accessible.


So if understand correctly then you want the debugger agent to create a 
listener on an ephemeral port when started over ssh. That should work 
fine and the listener port will be printed to stdout (and hence sent 
over the ssh session) so that the user can connect with the socket 
transport.


The alternative is of course to invert the setup so that the user starts 
the debugger configured to use a ListeningConnector and have the 
debuggee started with the `address` sub-option specifying the host/port 
of the debugger to connect to (no server=y).


If there isn't a solution then serviceability-dev would be a good place 
to bring up this topic as there has never been a supported way to 
publish the debugger port (the sun.jdwp.listenerAddress property is for 
the ProcessAttachingConnector).


-Alan

Re: Replacement for JDK8 APIs

[Eirik Bjørsnøs]

Except that wouldn't work with random ports..

Eirik.

On Fri, Nov 25, 2016 at 1:37 PM, Eirik Bjørsnøs  wrote:

>
>
> Stéphane,
>
> Could you inspect the JVM command line and parse the debugging agent
> options?
>
> Eirik.
>
> On Fri, Nov 25, 2016 at 1:11 PM, Stéphane Nicoll 
> wrote:
>
>> On Fri, Nov 25, 2016 at 3:14 AM, Alan Bateman 
>> wrote:
>>
>> > On 24/11/2016 14:22, Stéphane Nicoll wrote:
>> >
>> > :
>> >>
>> >> We use "sun.misc.VMSupport" to retrieve the port being used by the Java
>> >> remote debugging. You can find the actual code in
>> >> RemoteDebugPortProvider[3]
>> >>
>> >> This class was never intended to be used directly of course. It doesn't
>> > exist (or rather it has moved) in JDK 9. Are you grabbing the port so
>> that
>> > it can be published for debuggers to attach? Have you considered
>> publishing
>> > the pid instead - that would allow debuggers to use the
>> > ProcessAttachingConnector to attach.
>>
>>
>> Yes, there is a feature in Spring Boot called devtools that allows you do
>> remote debugging via SSH[1] - Is there any way to achieve the same feature
>> with JDK 9?
>>
>> Thanks,
>> S.
>>
>> [1]
>> http://docs.spring.io/spring-boot/docs/current/reference/htm
>> lsingle/#using-boot-devtools-remote-debugtunnel
>>
>>
>> >
>> >
>> > -Alan
>> >
>>
>
>

Re: Replacement for JDK8 APIs

[Eirik Bjørsnøs]

Stéphane,

Could you inspect the JVM command line and parse the debugging agent
options?

Eirik.

On Fri, Nov 25, 2016 at 1:11 PM, Stéphane Nicoll  wrote:

> On Fri, Nov 25, 2016 at 3:14 AM, Alan Bateman 
> wrote:
>
> > On 24/11/2016 14:22, Stéphane Nicoll wrote:
> >
> > :
> >>
> >> We use "sun.misc.VMSupport" to retrieve the port being used by the Java
> >> remote debugging. You can find the actual code in
> >> RemoteDebugPortProvider[3]
> >>
> >> This class was never intended to be used directly of course. It doesn't
> > exist (or rather it has moved) in JDK 9. Are you grabbing the port so
> that
> > it can be published for debuggers to attach? Have you considered
> publishing
> > the pid instead - that would allow debuggers to use the
> > ProcessAttachingConnector to attach.
>
>
> Yes, there is a feature in Spring Boot called devtools that allows you do
> remote debugging via SSH[1] - Is there any way to achieve the same feature
> with JDK 9?
>
> Thanks,
> S.
>
> [1]
> http://docs.spring.io/spring-boot/docs/current/reference/
> htmlsingle/#using-boot-devtools-remote-debugtunnel
>
>
> >
> >
> > -Alan
> >
>

Re: Replacement for JDK8 APIs

[Stéphane Nicoll]

On Fri, Nov 25, 2016 at 3:14 AM, Alan Bateman 
wrote:

> On 24/11/2016 14:22, Stéphane Nicoll wrote:
>
> :
>>
>> We use "sun.misc.VMSupport" to retrieve the port being used by the Java
>> remote debugging. You can find the actual code in
>> RemoteDebugPortProvider[3]
>>
>> This class was never intended to be used directly of course. It doesn't
> exist (or rather it has moved) in JDK 9. Are you grabbing the port so that
> it can be published for debuggers to attach? Have you considered publishing
> the pid instead - that would allow debuggers to use the
> ProcessAttachingConnector to attach.


Yes, there is a feature in Spring Boot called devtools that allows you do
remote debugging via SSH[1] - Is there any way to achieve the same feature
with JDK 9?

Thanks,
S.

[1]
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-devtools-remote-debugtunnel


>
>
> -Alan
>

Re: Replacement for JDK8 APIs

[Alan Bateman]

On 24/11/2016 14:22, Stéphane Nicoll wrote:


:

We use "sun.misc.VMSupport" to retrieve the port being used by the Java
remote debugging. You can find the actual code in RemoteDebugPortProvider[3]

This class was never intended to be used directly of course. It doesn't 
exist (or rather it has moved) in JDK 9. Are you grabbing the port so 
that it can be published for debuggers to attach? Have you considered 
publishing the pid instead - that would allow debuggers to use the 
ProcessAttachingConnector to attach.


-Alan

Replacement for JDK8 APIs

[Stéphane Nicoll]

Hi,

I am working on the Spring Boot project[1] and I am trying to make sure our
codebase compiles with the current JDK9 build[2]. So far I've hit two major
issues:

We use "sun.misc.VMSupport" to retrieve the port being used by the Java
remote debugging. You can find the actual code in RemoteDebugPortProvider[3]

We have an annotation processor that inspects all classes annotated with
@ConfigurationProperties and generates some meta-data about them. One
important piece of this is to extract the default value assigned to fields.
Consider the following example

@ConfigurationProperties
public class Foo {

  private static final String DEFAULT_NAME = "name";

  private String name = DEFAULT_NAME;

  private Integer counter = 42;

  private List hosts = Collections.singletonList("localhost");


}

What we've build is a visitor that navigates to those elements and extracts
the default values assigned to each field, including navigating to parent
element (the "name" constant there) or inferring value from method
parameters ("localhost"). The  current code relies on a feature of the JDK
that is no longer exported[4]:


java.lang.IllegalAccessException: class
org.springframework.boot.configurationprocessor.fieldvalues.javac.Trees
cannot access class com.sun.tools.javac.api.JavacTrees (in module
jdk.compiler) because module jdk.compiler does not export
com.sun.tools.javac.api to unnamed module @5a7fe64


Does anybody has some insight as how we could migrate those two use cases?
In particular, the second use case could be implemented with a contract of
javax.lang.model but we haven't found how to do it.

Thank you,
S.



[1] https://github.com/spring-projects/spring-boot
[2] https://github.com/spring-projects/spring-boot/issues/7226
[3]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-devtools/src/main/java/org/springframework/boot/devtools/tunnel/server/RemoteDebugPortProvider.java
[4]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-tools/spring-boot-configuration-processor/src/main/java/org/springframework/boot/configurationprocessor/fieldvalues/javac/Trees.java