#jdk7

[art7vandelay]

I use to work here.

[art7vandelay]

Art from the masters

[art7vandelay]

Study of eyes.

The second photo is done in Autodesk Sketchbook.  I am impressed with this product.

[art7vandelay]

Designed well,

[sevennet-blog]

How to: After Installing Java JDK 7 For Mac OS X - mvn -version still shows java version 1.6.0_31

How to: After Installing Java JDK 7 For Mac OS X – mvn -version still shows java version 1.6.0_31

After Installing Java JDK 7 For Mac OS X – mvn -version still shows java version 1.6.0_31

Oracle released Java JDK 7 on April 26 for Mac OS X. I followed the install instructions and when I do java -version in a terminal window I get:

java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)

However when I do mvn…

View On WordPress

[sevennet-blog]

How to: Java 7 language features with Android

How to: Java 7 language features with Android

Java 7 language features with Android

Just wondering if anyone has tried using new Java 7 language features with Android? I know that Android reads the bytecode that Java spits out and turns it to dex. So I guess my question is can it understand the bytecode of Java 7?

Answer: Java 7 language features with Android

EDIT: At the time this was written, the latest release was Android 9 and Eclipse…

View On WordPress

[ad-hockery]

Enabling Groovy's "invokedynamic" support in Gradle

I posted previously about configuring a Gradle project to ensure that only the indy version of Groovy (that is the variant that supports Java 7's invokedynamic bytecode instruction) is included in the dependency graph. However, just including that version of the Groovy jar is not enough to make your Groovy code compile in such a way that it uses invokedynamic.

In addition to including the right version of the jar you need to configure Gradle's GroovyCompile task like this:

tasks.withType(GroovyCompile) { groovyOptions.optimizationOptions.indy = true }

If you want to check the code is being compiled correctly the easiest way I've found to do so is to use javap to read the bytecode form a class file and see if there are any invokedynamic instructions. Here's an example:

javap -v -cp build/classes/test co.freeside.jdbi.time.LocalDateSpec | grep invokedynamic

If the class is compiled with the indy option set you'll see some output. Here's what I get from that class:

3: invokedynamic #46, 0 // InvokeDynamic #0:init:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object; 8: invokedynamic #52, 0 // InvokeDynamic #1:cast:(Ljava/lang/Object;)Lorg/skife/jdbi/v2/tweak/ResultSetMapper; 2: invokedynamic #62, 0 // InvokeDynamic #2:getProperty:(Ljava/lang/Class;)Ljava/lang/Object; 7: invokedynamic #52, 0 // InvokeDynamic #1:cast:(Ljava/lang/Object;)Lorg/skife/jdbi/v2/tweak/ResultSetMapper; 3: invokedynamic #70, 0 // InvokeDynamic #3:getProperty:(Lco/freeside/jdbi/time/LocalDateSpec;)Ljava/lang/Object; 8: invokedynamic #76, 0 // InvokeDynamic #4:invoke:(Ljava/lang/Class;Ljava/lang/Object;)Ljava/lang/Object; 13: invokedynamic #79, 0 // InvokeDynamic #1:cast:(Ljava/lang/Object;)Ljava/time/LocalDate; 32: invokedynamic #95, 0 // InvokeDynamic #1:cast:(Lgroovy/lang/GString;)Ljava/lang/String; 35: invokedynamic #95, 0 // InvokeDynamic #1:cast:(Lgroovy/lang/GString;)Ljava/lang/String; 32: invokedynamic #95, 0 // InvokeDynamic #1:cast:(Lgroovy/lang/GString;)Ljava/lang/String;

Of course, bear in mind that not all classes will contain any invokedynamic instructions. If you've used @CompileStatic for example method calls are not dispatched dynamically.

Edit: Cédric Champeau pointed out that you should use JDK 7u60 or above to avoid any potential invokedynamic related bugs.

[ad-hockery]

Gradle and Groovy's Invoke Dynamic support

Since version 2.0 the Groovy distribution has included an alternate artifact that enables invoke dynamic support.

You can include that in a Gradle project by specifying a dependency like this:

compile "org.codehaus.groovy:groovy-all:2.3.3:indy"

However if you have other libraries that depend on groovy they may pull in the regular version transitively giving you two versions of Groovy in your dependency graph. This happens to me a lot with Spock which depends on groovy-all:2.0.5. For example I probably have a dependency like this as well:

testCompile "org.spockframework:spock-core:0.7-groovy-2.0"

I noticed that the External Libraries section of the project tree in IntelliJ IDEA contained two groovy-all jars. One is groovy-all-2.3.3 and the other is groovy-all-2.3.3-indy. That's not good. I only want the indy version.

To debug where the dependency is coming from you can use Gradle's dependencyInsight target like this:

gradle dependencyInsight --dependency groovy-all

By default the dependencyInsight only searches the compile configuration and you may well see nothing there. You can search other configurations by adding an argument on the command line. For example:

gradle dependencyInsight --dependency groovy-all --configuration testCompile

The output from the command looks like this:

:dependencyInsight org.codehaus.groovy:groovy-all:2.3.3 (conflict resolution) \--- compile org.codehaus.groovy:groovy-all:2.0.5 -> 2.3.3 \--- org.spockframework:spock-core:0.7-groovy-2.0 \--- testCompile

Here we can see groovy-all version 2.3.3 explicitly included as a compile dependency and pulled in transitively by Spock. Gradle's conflict resolution has selected version 2.3.3 but what the output doesn't show us is the variant. It doesn't appear to be possible to tell whether the indy or regular flavor of groovy-all is pulled in.

To fix this I first tried forcing the version with:

configurations.all { resolutionStrategy { force "org.codehaus.groovy:groovy-all:2.3.3:indy" } }

The dependencyInsight output changed a little:

:dependencyInsight org.codehaus.groovy:groovy-all:2.3.3 (forced) \--- compile org.codehaus.groovy:groovy-all:2.0.5 -> 2.3.3 \--- org.spockframework:spock-core:0.7-groovy-2.0 \--- testCompile

However, I could still see both versions of groovy-all in IDEA's project tree. It looks like the force resolution strategy doesn't take into account the variant you request.

Unfortunately the only way to get evict the regular groovy-all jar from the dependency tree seems to be to explicitly exclude it from every dependency that pulls it in transitively. For example:

testCompile("org.spockframework:spock-core:0.7-groovy-2.0") { exclude module: "groovy-all" }

Finally the extra jar is gone from IDEA.