hg: jigsaw/jake/langtools: Add tools/javac/processing/T8142931.java to temporary exclude list

[alan . bateman]

Changeset: 4af41bbaaa94
Author:alanb
Date:  2015-12-06 08:40 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4af41bbaaa94

Add tools/javac/processing/T8142931.java to temporary exclude list

! test/ProblemList.jake.txt

hg: jigsaw/jake/langtools: s/@since 1.9/@since 9/ + add missing @since

[alan . bateman]

Changeset: 4aa4950e2da9
Author:alanb
Date:  2015-12-06 08:27 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4aa4950e2da9

s/@since 1.9/@since 9/ + add missing @since

! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java
! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java
! src/java.compiler/share/classes/javax/lang/model/element/ModuleElement.java
! src/java.compiler/share/classes/javax/lang/model/type/TypeKind.java
! 
src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
! src/java.compiler/share/classes/javax/tools/JavaFileManager.java
! src/java.compiler/share/classes/javax/tools/StandardLocation.java

hg: jigsaw/jake/jdk: s/@since 1.9/@since 9/

[alan . bateman]

Changeset: 210190f00665
Author:alanb
Date:  2015-12-06 08:28 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/210190f00665

s/@since 1.9/@since 9/

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/StackTraceElement.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/module/Configuration.java
! src/java.base/share/classes/java/lang/module/FindException.java
! 
src/java.base/share/classes/java/lang/module/InvalidModuleDescriptorException.java
! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
! src/java.base/share/classes/java/lang/module/ModuleFinder.java
! src/java.base/share/classes/java/lang/module/ModuleReader.java
! src/java.base/share/classes/java/lang/module/ModuleReference.java
! src/java.base/share/classes/java/lang/module/ResolutionException.java
! src/java.base/share/classes/java/lang/module/package-info.java
! src/java.base/share/classes/java/lang/reflect/InaccessibleObjectException.java
! src/java.base/share/classes/java/lang/reflect/Layer.java
! src/java.base/share/classes/java/lang/reflect/LayerInstantiationException.java
! src/java.base/share/classes/java/lang/reflect/Module.java
! src/java.base/share/classes/java/util/ResourceBundle.java
! src/java.base/share/classes/java/util/ServiceLoader.java
! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java
! src/java.base/share/classes/java/util/spi/ResourceBundleProvider.java

Re: the acyclic module graph

[Jochen Theodorou]

On 05.12.2015 18:38, Alan Bateman wrote:
[...]

The strict requirement is that there isn't a cycle in the dependency
graph. This should be caught at compile-time, and at run-time when
creating a configuration (think startup for now).


ok, understood...  I mixed up readability and dependency graphs

bye Jochen

getting a basic class loader

[Alan Snyder]

I have been told [1] that doing something like String.class.getClassLoader() is 
a good way to get a value that can specified as the parent of a custom class 
loader when my goal for the custom class loader is to exclude 
application-specific classes (e.g. from the classpath).

Is this the best way to accomplish that goal, and does the answer change in JDK 
9 with jigsaw?

I am skeptical because I don’t see any reason to believe that the class loader 
for any given JDK class is necessarily a complete class loader that knows about 
all JDK runtime classes. In fact, in JDK 8 it is clearly not the case because 
the extensions class loader is not included.

  Alan

[1] 
http://stackoverflow.com/questions/34101259/need-a-java-system-only-class-loader
 

Re: Optional dependencies

[Stephen Colebourne]

On 5 December 2015 at 09:49, Alan Bateman  wrote:
>
> On 04/12/2015 19:10, Peter Levart wrote:
>>
>> :
>>
>> You would have to invoke jodaBeansModule.addRead(guavaModule); from your
>> org.joda.beans code before 1st use of any guava type. In Addition, you would
>> have to ensure guava is part of runtime configuration - either implicitly by
>> some module in your configuration requiring guava or explicitly by adding
>> "-addmodule guava" to the java launcher command line.
>
> Yes, that's right, there is enough to support all the scenarios. The
> use-guava-if-it-happens-to-be-there scenario is somewhat awkward though as
> it would means using -addmods. On the other hand, the
> use-guava-if-someone-hands-me-a-guava-type scenario is straight-forward, it
> just means reading the module at run-time (easy).
>
> -Alan

Re: Optional dependencies

[Stephen Colebourne]

On 5 December 2015 at 09:49, Alan Bateman  wrote:
> Yes, that's right, there is enough to support all the scenarios. The
> use-guava-if-it-happens-to-be-there scenario is somewhat awkward though as
> it would means using -addmods. On the other hand, the
> use-guava-if-someone-hands-me-a-guava-type scenario is straight-forward, it
> just means reading the module at run-time (easy).

However taking a step back, in order to support this type of release,
command line flags are not an option. Since Joda-Beans is an OSS
library, developers need to be able to "just use it". Telling
developers that if they use this library they have to add a complex
command line flag at runtime is simply not on.

To me, the answers have identified a clear need for optional module
dependencies in the jigsaw design, such that key information is not
lost.

Stephen