You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Shaddy Baddah <be...@shaddybaddah.name> on 2016/02/04 06:07:53 UTC
Way Java 8 resolves interface dependencies seems to play havoc
Hi,
I was working through a problem where my local build of a project, using
Maven 3.2.2 and JDK 1.8.0_71 (Win64) was continually hitting a
dependency problem. Whilst our continuous integration server was not.
The continuous integration server is running JDK 1.7.0_80.
The problem being encountered was:
[ERROR] C:\Users\shaddy\workarea\...\FooBean.java:[72,45] error: cannot
access TransactionLocalDelegate
Before I dive head first into my investigation into the problem, I
am fairly certain the problem is because there has been a change to how
javac in Java 8 resolves interface dependencies; in contrast to previous
versions.
My understanding is pre Java 8, you did not need to include in the
classpath to javac, paths to the interfaces that are dependencies of
precompiled classes.
According to https://bugs.openjdk.java.net/browse/JDK-8055048, this has
changed (my understanding, due to a language spec change) with Java 8.
I know this seems late in the game, but considering how I encountered
the problem, how it seems so obscure and random, I thought it important
to have something on record about how Java 8's changed behaviour may
have been potentially crippling user experience of Maven. Through no
fault of Maven, or artifact creators themselves. But through a change in
the goal-posts.
To illustrate my point, if you can follow this. The code in question is:
import com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate;
import com.arjuna.ats.jta.transaction.Transaction;
...
TransactionManagerDelegate tx = (TransactionManagerDelegate)
TransactionManager.transactionManager();
try {
Transaction transaction = (Transaction) tx.getTransaction();
Tracing this to see where there was a reference to
TransactionLocalDelegate, I found that it was in a base class
com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate extends:
public class com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate
extends com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate
implements javax.naming.spi.ObjectFactory {
public com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate();
public int getTransactionTimeout() throws
javax.transaction.SystemException;
Now this base class implements interface
org.jboss.tm.TransactionLocalDelegate:
public abstract class
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
javax.transaction.TransactionManager,org.jboss.tm.TransactionLocalDelegate,org.jboss.tm.TransactionTimeoutConfiguration
With Java 1.7 and below, javac would not chase down the definition of
this interface (confirmed with javac -verbose). But with Java 1.8 it
does.
Now the artifact is:
<dependency>
<groupId>org.jboss.jbossts.jts</groupId>
<artifactId>jbossjts-integration</artifactId>
</dependency>
and the pom.xml for this artifact has this section:
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-transaction-spi</artifactId>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging-spi</artifactId>
</exclusion>
</exclusions>
</dependency>
Artifact jboss-transaction-spi would have provided the definition to
interface org.jboss.tm.TransactionLocalDelegate. But innocently (and
perhaps for greatest efficiency), the pom.xml definition has it scoped
provided.
This is now really really problematic. Maven will not provide it, but
Java 1.8 now requires that it does.
Without any sample of data (or even being in a position to take such)
I have to speculate that many pom.xml authors have taken the same
measures. And following on from that, users building projects that
depend on similarly defined artifacts, are unable to build with Java 8
javac. And potentially putting it down to Maven/artifact problems.
I'm not sure what the solution is. Is it as significant a change in
behaviour as I think it, for pom.xml authors to update their definitions
to no longer specify that interfaces are "provided"? It's going to make
Maven seem slightly slower and bloated. Through no fault of its own.
One last note. Running Java 8 javac with something like -target 1.6
-source 1.6 won't change the dependency resolution behaviour.
--
Regards,
Shaddy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Way Java 8 resolves interface dependencies seems to play havoc
Posted by ec...@zusammenkunft.net.
Hello,
Yes you have to provide interfaces for Java 8 compiler which you did not need before. If your dependencies do not provide these artifacts you get the compiler error. You then basically have the option to include it in the upstream dependency or in your own project as a compile time deoendency (and changes are high that you have depoyed that artifact at runtime anyway).
I dont think the typical maven plugins can make anything differently (and not even the bundle plugin I guess needs to do something else).
Gruss
Bernd
--
http://bernd.eckenfels.net
-----Original Message-----
From: Curtis Rueden <ct...@wisc.edu>
To: Maven Users List <us...@maven.apache.org>
Sent: Do., 04 Feb. 2016 15:23
Subject: Re: Way Java 8 resolves interface dependencies seems to play havoc
Hi Shaddy,
> Is it as significant a change in behaviour as I think it, for pom.xml
> authors to update their definitions to no longer specify that
> interfaces are "provided"?
Personally, I have never heard of interface/API JARs being scoped as
provided in this manner, until you pointed out the jboss example. I would
be surprised if this is a common practice, especially since it seems like a
hack: in this case, the interfaces are _not_ actually "provided" at
runtime, right? They just end up not actually being needed with Java 7 or
earlier runtime?
Anyway, it seems very dangerous to me to rely on class loading subtleties
like that when scoping Maven artifacts -- I would always put these things
at compile or runtime scope in my own projects, to maximize compatibility.
The fact is that those interfaces _are_ dependencies. I would call this a
"bug" in the JBoss BOM.
Regards,
Curtis
--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/
On Wed, Feb 3, 2016 at 11:07 PM, Shaddy Baddah <
beryllium-bugs@shaddybaddah.name> wrote:
> Hi,
>
> I was working through a problem where my local build of a project, using
> Maven 3.2.2 and JDK 1.8.0_71 (Win64) was continually hitting a
> dependency problem. Whilst our continuous integration server was not.
>
> The continuous integration server is running JDK 1.7.0_80.
>
> The problem being encountered was:
>
> [ERROR] C:\Users\shaddy\workarea\...\FooBean.java:[72,45] error: cannot
> access TransactionLocalDelegate
>
> Before I dive head first into my investigation into the problem, I
> am fairly certain the problem is because there has been a change to how
> javac in Java 8 resolves interface dependencies; in contrast to previous
> versions.
>
> My understanding is pre Java 8, you did not need to include in the
> classpath to javac, paths to the interfaces that are dependencies of
> precompiled classes.
>
> According to https://bugs.openjdk.java.net/browse/JDK-8055048, this has
> changed (my understanding, due to a language spec change) with Java 8.
>
> I know this seems late in the game, but considering how I encountered
> the problem, how it seems so obscure and random, I thought it important
> to have something on record about how Java 8's changed behaviour may
> have been potentially crippling user experience of Maven. Through no fault
> of Maven, or artifact creators themselves. But through a change in
> the goal-posts.
>
> To illustrate my point, if you can follow this. The code in question is:
>
> import com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate;
> import com.arjuna.ats.jta.transaction.Transaction;
> ...
>
> TransactionManagerDelegate tx =
> (TransactionManagerDelegate) TransactionManager.transactionManager();
> try {
> Transaction transaction = (Transaction)
> tx.getTransaction();
>
>
> Tracing this to see where there was a reference to
> TransactionLocalDelegate, I found that it was in a base class
> com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate extends:
>
> public class com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate
> extends com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> javax.naming.spi.ObjectFactory {
> public com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate();
> public int getTransactionTimeout() throws
> javax.transaction.SystemException;
>
> Now this base class implements interface
> org.jboss.tm.TransactionLocalDelegate:
>
> public abstract class
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> javax.transaction.TransactionManager,org.jboss.tm.TransactionLocalDelegate,
> org.jboss.tm.TransactionTimeoutConfiguration
>
> With Java 1.7 and below, javac would not chase down the definition of
> this interface (confirmed with javac -verbose). But with Java 1.8 it
> does.
>
> Now the artifact is:
>
> <dependency>
> <groupId>org.jboss.jbossts.jts</groupId>
> <artifactId>jbossjts-integration</artifactId>
> </dependency>
>
>
> and the pom.xml for this artifact has this section:
>
> <dependency>
> <groupId>org.jboss</groupId>
> <artifactId>jboss-transaction-spi</artifactId>
> <scope>provided</scope>
> <exclusions>
> <exclusion>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging-spi</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
> Artifact jboss-transaction-spi would have provided the definition to
> interface org.jboss.tm.TransactionLocalDelegate. But innocently (and
> perhaps for greatest efficiency), the pom.xml definition has it scoped
> provided.
>
> This is now really really problematic. Maven will not provide it, but
> Java 1.8 now requires that it does.
>
> Without any sample of data (or even being in a position to take such)
> I have to speculate that many pom.xml authors have taken the same
> measures. And following on from that, users building projects that
> depend on similarly defined artifacts, are unable to build with Java 8
> javac. And potentially putting it down to Maven/artifact problems.
>
> I'm not sure what the solution is. Is it as significant a change in
> behaviour as I think it, for pom.xml authors to update their definitions
> to no longer specify that interfaces are "provided"? It's going to make
> Maven seem slightly slower and bloated. Through no fault of its own.
>
> One last note. Running Java 8 javac with something like -target 1.6
> -source 1.6 won't change the dependency resolution behaviour.
>
> --
> Regards,
> Shaddy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Way Java 8 resolves interface dependencies seems to play havoc
Posted by Martin Gainty <mg...@hotmail.com>.
i agree with curtis
>javac -versionjavac 1.8.0_40
<!-- unless otherwise stated assume scope is 'compile' -->
<project><modelVersion>4.0.0</modelVersion><groupId>test</groupId><artifactId>Test</artifactId><version>1.0</version><dependencies><!-- this is the first and only dependency I had in pom.xml --> <dependency> <groupId>org.jboss.jbossts</groupId> <artifactId>jbossjts-integration</artifactId> <version>4.16.6</version> </dependency> <!-- then I got this error which forced me to add jbossjts --> <!-- [ERROR] /ShaddahTest/src/main/java/test/Test.java:[3,38] package com.arjuna.ats.jta.transaction does not exist --> <dependency> <groupId>org.jboss.jbossts</groupId> <artifactId>jbossjts</artifactId> <version>4.16.6.Final</version> </dependency> <!-- then I got this error which forced me to add jta --> <!-- [ERROR] /ShaddahTest/src/main/java/test/Test.java:[23,69] cannot find symbol[ERROR] symbol: class SystemException [ERROR] location: package javax.transaction --> <dependency> <groupId>javax.transaction</groupId> <artifactId>jta</artifactId> <version>1.1</version> </dependency> <!-- and finally i got missing interface TransactionLocalDelegate which forced me to add jboss-transaction-spi --> <!--[ERROR] /ShaddahTest/src/main/java/test/Test.java:[10,67] cannot access org.jboss.tm.TransactionLocalDelegate[ERROR] class file for org.jboss.tm.TransactionLocalDelegate not found --> <dependency> <groupId>org.jboss.integration</groupId> <artifactId>jboss-transaction-spi</artifactId> <version>6.0.0</version> </dependency></dependencies></project>
when scope=compile none of the Base Classes or Interfaces are 'automatically resolved' and I am forced to add the dependencies
Can you please illustrate a 'automatic resolution behaviour for interface' with a non jboss example?
Thanks,
Martin
______________________________________________
> From: ctrueden@wisc.edu
> Date: Thu, 4 Feb 2016 08:22:31 -0600
> Subject: Re: Way Java 8 resolves interface dependencies seems to play havoc
> To: users@maven.apache.org
>
> Hi Shaddy,
>
> > Is it as significant a change in behaviour as I think it, for pom.xml
> > authors to update their definitions to no longer specify that
> > interfaces are "provided"?
>
> Personally, I have never heard of interface/API JARs being scoped as
> provided in this manner, until you pointed out the jboss example. I would
> be surprised if this is a common practice, especially since it seems like a
> hack: in this case, the interfaces are _not_ actually "provided" at
> runtime, right? They just end up not actually being needed with Java 7 or
> earlier runtime?
>
> Anyway, it seems very dangerous to me to rely on class loading subtleties
> like that when scoping Maven artifacts -- I would always put these things
> at compile or runtime scope in my own projects, to maximize compatibility.
> The fact is that those interfaces _are_ dependencies. I would call this a
> "bug" in the JBoss BOM.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> Did you know ImageJ has a forum? http://forum.imagej.net/
>
>
> On Wed, Feb 3, 2016 at 11:07 PM, Shaddy Baddah <
> beryllium-bugs@shaddybaddah.name> wrote:
>
> > Hi,
> >
> > I was working through a problem where my local build of a project, using
> > Maven 3.2.2 and JDK 1.8.0_71 (Win64) was continually hitting a
> > dependency problem. Whilst our continuous integration server was not.
> >
> > The continuous integration server is running JDK 1.7.0_80.
> >
> > The problem being encountered was:
> >
> > [ERROR] C:\Users\shaddy\workarea\...\FooBean.java:[72,45] error: cannot
> > access TransactionLocalDelegate
> >
> > Before I dive head first into my investigation into the problem, I
> > am fairly certain the problem is because there has been a change to how
> > javac in Java 8 resolves interface dependencies; in contrast to previous
> > versions.
> >
> > My understanding is pre Java 8, you did not need to include in the
> > classpath to javac, paths to the interfaces that are dependencies of
> > precompiled classes.
> >
> > According to https://bugs.openjdk.java.net/browse/JDK-8055048, this has
> > changed (my understanding, due to a language spec change) with Java 8.
> >
> > I know this seems late in the game, but considering how I encountered
> > the problem, how it seems so obscure and random, I thought it important
> > to have something on record about how Java 8's changed behaviour may
> > have been potentially crippling user experience of Maven. Through no fault
> > of Maven, or artifact creators themselves. But through a change in
> > the goal-posts.
> >
> > To illustrate my point, if you can follow this. The code in question is:
> >
> > import com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate;
> > import com.arjuna.ats.jta.transaction.Transaction;
> > ...
> >
> > TransactionManagerDelegate tx =
> > (TransactionManagerDelegate) TransactionManager.transactionManager();
> > try {
> > Transaction transaction = (Transaction)
> > tx.getTransaction();
> >
> >
> > Tracing this to see where there was a reference to
> > TransactionLocalDelegate, I found that it was in a base class
> > com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate extends:
> >
> > public class com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate
> > extends com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> > javax.naming.spi.ObjectFactory {
> > public com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate();
> > public int getTransactionTimeout() throws
> > javax.transaction.SystemException;
> >
> > Now this base class implements interface
> > org.jboss.tm.TransactionLocalDelegate:
> >
> > public abstract class
> > com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> > javax.transaction.TransactionManager,org.jboss.tm.TransactionLocalDelegate,
> > org.jboss.tm.TransactionTimeoutConfiguration
> >
> > With Java 1.7 and below, javac would not chase down the definition of
> > this interface (confirmed with javac -verbose). But with Java 1.8 it
> > does.
> >
> > Now the artifact is:
> >
> > <dependency>
> > <groupId>org.jboss.jbossts.jts</groupId>
> > <artifactId>jbossjts-integration</artifactId>
> > </dependency>
> >
> >
> > and the pom.xml for this artifact has this section:
> >
> > <dependency>
> > <groupId>org.jboss</groupId>
> > <artifactId>jboss-transaction-spi</artifactId>
> > <scope>provided</scope>
> > <exclusions>
> > <exclusion>
> > <groupId>org.jboss.logging</groupId>
> > <artifactId>jboss-logging-spi</artifactId>
> > </exclusion>
> > </exclusions>
> > </dependency>
> >
> > Artifact jboss-transaction-spi would have provided the definition to
> > interface org.jboss.tm.TransactionLocalDelegate. But innocently (and
> > perhaps for greatest efficiency), the pom.xml definition has it scoped
> > provided.
> >
> > This is now really really problematic. Maven will not provide it, but
> > Java 1.8 now requires that it does.
> >
> > Without any sample of data (or even being in a position to take such)
> > I have to speculate that many pom.xml authors have taken the same
> > measures. And following on from that, users building projects that
> > depend on similarly defined artifacts, are unable to build with Java 8
> > javac. And potentially putting it down to Maven/artifact problems.
> >
> > I'm not sure what the solution is. Is it as significant a change in
> > behaviour as I think it, for pom.xml authors to update their definitions
> > to no longer specify that interfaces are "provided"? It's going to make
> > Maven seem slightly slower and bloated. Through no fault of its own.
> >
> > One last note. Running Java 8 javac with something like -target 1.6
> > -source 1.6 won't change the dependency resolution behaviour.
> >
> > --
> > Regards,
> > Shaddy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
Re: Way Java 8 resolves interface dependencies seems to play havoc
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Shaddy,
> Is it as significant a change in behaviour as I think it, for pom.xml
> authors to update their definitions to no longer specify that
> interfaces are "provided"?
Personally, I have never heard of interface/API JARs being scoped as
provided in this manner, until you pointed out the jboss example. I would
be surprised if this is a common practice, especially since it seems like a
hack: in this case, the interfaces are _not_ actually "provided" at
runtime, right? They just end up not actually being needed with Java 7 or
earlier runtime?
Anyway, it seems very dangerous to me to rely on class loading subtleties
like that when scoping Maven artifacts -- I would always put these things
at compile or runtime scope in my own projects, to maximize compatibility.
The fact is that those interfaces _are_ dependencies. I would call this a
"bug" in the JBoss BOM.
Regards,
Curtis
--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/
On Wed, Feb 3, 2016 at 11:07 PM, Shaddy Baddah <
beryllium-bugs@shaddybaddah.name> wrote:
> Hi,
>
> I was working through a problem where my local build of a project, using
> Maven 3.2.2 and JDK 1.8.0_71 (Win64) was continually hitting a
> dependency problem. Whilst our continuous integration server was not.
>
> The continuous integration server is running JDK 1.7.0_80.
>
> The problem being encountered was:
>
> [ERROR] C:\Users\shaddy\workarea\...\FooBean.java:[72,45] error: cannot
> access TransactionLocalDelegate
>
> Before I dive head first into my investigation into the problem, I
> am fairly certain the problem is because there has been a change to how
> javac in Java 8 resolves interface dependencies; in contrast to previous
> versions.
>
> My understanding is pre Java 8, you did not need to include in the
> classpath to javac, paths to the interfaces that are dependencies of
> precompiled classes.
>
> According to https://bugs.openjdk.java.net/browse/JDK-8055048, this has
> changed (my understanding, due to a language spec change) with Java 8.
>
> I know this seems late in the game, but considering how I encountered
> the problem, how it seems so obscure and random, I thought it important
> to have something on record about how Java 8's changed behaviour may
> have been potentially crippling user experience of Maven. Through no fault
> of Maven, or artifact creators themselves. But through a change in
> the goal-posts.
>
> To illustrate my point, if you can follow this. The code in question is:
>
> import com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate;
> import com.arjuna.ats.jta.transaction.Transaction;
> ...
>
> TransactionManagerDelegate tx =
> (TransactionManagerDelegate) TransactionManager.transactionManager();
> try {
> Transaction transaction = (Transaction)
> tx.getTransaction();
>
>
> Tracing this to see where there was a reference to
> TransactionLocalDelegate, I found that it was in a base class
> com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate extends:
>
> public class com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate
> extends com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> javax.naming.spi.ObjectFactory {
> public com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate();
> public int getTransactionTimeout() throws
> javax.transaction.SystemException;
>
> Now this base class implements interface
> org.jboss.tm.TransactionLocalDelegate:
>
> public abstract class
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate implements
> javax.transaction.TransactionManager,org.jboss.tm.TransactionLocalDelegate,
> org.jboss.tm.TransactionTimeoutConfiguration
>
> With Java 1.7 and below, javac would not chase down the definition of
> this interface (confirmed with javac -verbose). But with Java 1.8 it
> does.
>
> Now the artifact is:
>
> <dependency>
> <groupId>org.jboss.jbossts.jts</groupId>
> <artifactId>jbossjts-integration</artifactId>
> </dependency>
>
>
> and the pom.xml for this artifact has this section:
>
> <dependency>
> <groupId>org.jboss</groupId>
> <artifactId>jboss-transaction-spi</artifactId>
> <scope>provided</scope>
> <exclusions>
> <exclusion>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging-spi</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
> Artifact jboss-transaction-spi would have provided the definition to
> interface org.jboss.tm.TransactionLocalDelegate. But innocently (and
> perhaps for greatest efficiency), the pom.xml definition has it scoped
> provided.
>
> This is now really really problematic. Maven will not provide it, but
> Java 1.8 now requires that it does.
>
> Without any sample of data (or even being in a position to take such)
> I have to speculate that many pom.xml authors have taken the same
> measures. And following on from that, users building projects that
> depend on similarly defined artifacts, are unable to build with Java 8
> javac. And potentially putting it down to Maven/artifact problems.
>
> I'm not sure what the solution is. Is it as significant a change in
> behaviour as I think it, for pom.xml authors to update their definitions
> to no longer specify that interfaces are "provided"? It's going to make
> Maven seem slightly slower and bloated. Through no fault of its own.
>
> One last note. Running Java 8 javac with something like -target 1.6
> -source 1.6 won't change the dependency resolution behaviour.
>
> --
> Regards,
> Shaddy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>