maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: Java 11 and java.xml.bin, etc.
Date Wed, 19 Sep 2018 13:03:34 GMT
Il giorno mer 19 set 2018 alle ore 14:15 Sverre Moe <sverre.moe@gmail.com>
ha scritto:

> Would it work running JAXB 2.3.0 on Java 8? I understand this version of
> JAXB has been modularized for Java 9.
>     Java 6 = JAXB Version 2.0
>     Java 7 = JAXB Version 2.2.3
>     Java 8 = JAXB Version 2.2.8
>     Java 9 = JAXB Version 2.3.0
>


I am deploying such JAR together with my applications, this way they can
run both on JDK8 and JDK10.
On JDK8 system classes are loaded before additional JARs so having that
JARs is mostly like an NOOP.

But you should test the effective behavior before going to production.
The presence of a SecurityManager or a Web Contains may also affect the way
system classes can be overridden.

In most of all that specs/libraries the way a Factory/Provider is loaded
from the classpath is hard to understand sometimes, because there is no
common rule.

In my experience it seems safe to put those jars on the classpath and run
on JDK8.

Cheers
Enrico



>
> /Sverre
>
>
> Den ons. 19. sep. 2018 kl. 14:01 skrev Enrico Olivelli <
> eolivelli@gmail.com
> >:
>
> > I suggest to use Glassfish artifacts and use 2.3.0 or later.
> > Actually the 2.3.0 version is the best replacement for jdk8 APIs
> >
> > Enrico
> >
> > Il mer 19 set 2018, 13:55 Sverre Moe <sverre.moe@gmail.com> ha scritto:
> >
> > > This is what we have done for our legacy application running Java 8.
> > >
> > > By adding the dependencies for JAXB we where able to run our
> application
> > > with Java 9 and 10 without any other changes needed and still keep
> > > compatibility with Java 8.
> > >
> > > We don't have the compile scope, as we deploy with Java Web Start and
> > need
> > > the JAXB dependencies there in case some client is running Java 9+.
> > >
> > >         <dependency>
> > >             <groupId>javax.xml.bind</groupId>
> > >             <artifactId>jaxb-api</artifactId>
> > >             <version>2.2.11</version>
> > >         </dependency>
> > >
> > >         <dependency>
> > >             <groupId>com.sun.xml.bind</groupId>
> > >             <artifactId>jaxb-core</artifactId>
> > >             <version>2.2.11</version>
> > >         </dependency>
> > >
> > >         <dependency>
> > >             <groupId>com.sun.xml.bind</groupId>
> > >             <artifactId>jaxb-impl</artifactId>
> > >             <version>2.2.11</version>
> > >         </dependency>
> > >
> > >         <dependency>
> > >             <groupId>javax.activation</groupId>
> > >             <artifactId>activation</artifactId>
> > >             <version>1.1.1</version>
> > >         </dependency>
> > >
> > > This is the Sun JAXB implementation. There is alternatives from
> Glassfish
> > > and Eclipselink.
> > >
> > > Den tir. 18. sep. 2018 kl. 21:46 skrev Robert Scholte <
> > > rfscholte@apache.org
> > > >:
> > >
> > > > Add them as compile scoped dependencies. The JRE implementation will
> be
> > > > picked up first, so there should be no issues here.
> > > > AFAIK this is what the jigsaw team suggests to do. (this is actually
> > not
> > > > a
> > > > buildtool specific issue but a general Java issue)
> > > >
> > > > thanks,
> > > > Robert
> > > >
> > > >
> > > > On Fri, 14 Sep 2018 01:21:52 +0200, Bernd Eckenfels
> > > > <ecki@zusammenkunft.net> wrote:
> > > >
> > > > > And in addition to Jörgs Questions, do we also have a canonical
> > > > > representation which replacements are actually preferred in ASL
> land?
> > > > >
> > > > > Gruss
> > > > > Bernd
> > > > > --
> > > > > http://bernd.eckenfels.net
> > > > >
> > > > > ________________________________
> > > > > Von: Jörg Schaible <joerg.schaible@gmx.de>
> > > > > Gesendet: Freitag, September 14, 2018 1:16 AM
> > > > > An: users@maven.apache.org
> > > > > Betreff: Java 11 and java.xml.bin, etc.
> > > > >
> > > > > Hi,
> > > > >
> > > > > now with Java 11 not containing several jave.ee modules, what's
> the
> > > best
> > > > > approach for a library that supports still Java 8? I guess profiles
> > > based
> > > > > on the current Java version declaring the missing stuff as
> dependency
> > > are
> > > > > a bad idea. Should a library developer add the new dependencies
> > > > > nevertheless with compile/runtime scope or as provided or optional
> to
> > > > > move
> > > > > the responsibility to the library users? What do you recommend?
> > > > >
> > > > > Cheers,
> > > > > Jörg
> > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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
> > > >
> > > >
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message