Re: automatic modules leaking types when using addmods

I understand this statement from the perspective of automatic modules. Not so much from the perspective of named modules however. Why would it be necessary to give implicit readability to all automatic modules when you're just explicitly using a single one? Paul > On 25 Apr 2016, at 02:38, Pau

Re: automatic modules leaking types when using addmods

That doesn't seem to be the case, I can run successfully, as long as I have the right -addmods. I've pushed my example here if you want to take a further look at it: https://github.com/paulbakker/automaticmodules-example Paul > On 25 Ap

Re: automatic modules leaking types when using addmods

On 24/04/2016 21:00, Paul Bakker wrote: So when modules B, C and D are automatic modules and named module A depends on B, A also gets implicit readability to C and D? What is the reasoning behind this automatic implicit readability? It makes migration less reliable I think, because it hides wh

Re: automatic modules leaking types when using addmods

Automatic modules live in a classpath-like world. Everything is exported to each other. You use this feature if you don't have time to migrate to a modular architecture. On Apr 24, 2016 3:01 PM, "Paul Bakker" wrote: > So when modules B, C and D are automatic modules and named module A > depends o

Re: automatic modules leaking types when using addmods

So when modules B, C and D are automatic modules and named module A depends on B, A also gets implicit readability to C and D? What is the reasoning behind this automatic implicit readability? It makes migration less reliable I think, because it hides what dependencies a module really has. Paul

Re: automatic modules leaking types when using addmods

On 24/04/2016 10:57, Paul Bakker wrote: Hello, Another question related to automatic modules. I have the following code: import com.fasterxml.jackson.core.JsonFactory; ... JsonFactory f = new JsonFactory(); System.out.println(f.getCodec()); This code clearly d

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

+1 -Sundar On 4/24/2016 5:20 PM, Jim Laskey (Oracle) wrote: > Thank you, changes incorporated. > >> On Apr 22, 2016, at 2:08 PM, Mandy Chung wrote: >> >> Hi Jim, >> >>> On Apr 22, 2016, at 6:12 AM, Jim Laskey (Oracle) >>> wrote: >>> >>> Listing is by module, extract has been by module for some

Re: RFR: JDK-8069079 - jimage extract / list to organize classes by modules

Thank you, changes incorporated. > On Apr 22, 2016, at 2:08 PM, Mandy Chung wrote: > > Hi Jim, > >> On Apr 22, 2016, at 6:12 AM, Jim Laskey (Oracle) >> wrote: >> >> Listing is by module, extract has been by module for some time. >> >> http://cr.openjdk.java.net/~jlaskey/8069079/webrev/index

Re: RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

Thank you. > On Apr 24, 2016, at 5:23 AM, Alan Bateman wrote: > > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> The unused cache is being unnecessarily activated (ThreadLocal) when buffers >> are being released. >> >> http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html >>

Re: RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND

JCK change incorporated. Thank you. > On Apr 24, 2016, at 5:22 AM, Alan Bateman wrote: > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the >> jdk jimage.hpp header. Brought the headers in line. >> >> http://cr

automatic modules leaking types when using addmods

Hello, Another question related to automatic modules. I have the following code: import com.fasterxml.jackson.core.JsonFactory; ... JsonFactory f = new JsonFactory(); System.out.println(f.getCodec()); This code clearly depends on jackson.core. So my module-info co

Re: RFR: JDK-8154179 - BasicImageReader activating ImageBufferCache when not used

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: The unused cache is being unnecessarily activated (ThreadLocal) when buffers are being released. http://cr.openjdk.java.net/~jlaskey/8154179/webrev/index.html https://bugs.openjdk.

Re: RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND

On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the jdk jimage.hpp header. Brought the headers in line. http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html

Re: java.lang.reflect.Module.WeakSet is not thread-safe

On 22/04/2016 14:42, Peter Levart wrote: : I tried to reduce the complexity of WeakPairMap as much as I could. I added some docs that describe the architecture. Hopefully this is now easier to grasp: http://cr.openjdk.java.net/~plevart/jdk9-dev/Module.WeakSet.multithreadUnsafe/webrev.03/

Re: The javax.annotation.Generated and annotation processors

On 23/04/2016 00:14, Sanne Grinovero wrote: : I couldn't try the "-J-addmods -Jjava.annotations.common" solution either, I suspect because Maven is getting in the way and possibly passing these parameters in the wrong order; for the record this is the stack: Caused by: java.lang.IllegalArgumen