Java 11 and java.xml.bin, etc.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Java 11 and java.xml.bin, etc.

Jörg Schaible
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Java 11 and java.xml.bin, etc.

Bernd Eckenfels
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 <[hidden email]>
Gesendet: Freitag, September 14, 2018 1:16 AM
An: [hidden email]
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Java 11 and java.xml.bin, etc.

rfscholte
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  
<[hidden email]> 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 <[hidden email]>
> Gesendet: Freitag, September 14, 2018 1:16 AM
> An: [hidden email]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Java 11 and java.xml.bin, etc.

DJViking
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 <[hidden email]
>:

> 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
> <[hidden email]> 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 <[hidden email]>
> > Gesendet: Freitag, September 14, 2018 1:16 AM
> > An: [hidden email]
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Java 11 and java.xml.bin, etc.

Enrico Olivelli
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 <[hidden email]> 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 <
> [hidden email]
> >:
>
> > 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
> > <[hidden email]> 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 <[hidden email]>
> > > Gesendet: Freitag, September 14, 2018 1:16 AM
> > > An: [hidden email]
> > > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
--


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Java 11 and java.xml.bin, etc.

DJViking
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

/Sverre


Den ons. 19. sep. 2018 kl. 14:01 skrev Enrico Olivelli <[hidden email]
>:

> 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 <[hidden email]> 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 <
> > [hidden email]
> > >:
> >
> > > 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
> > > <[hidden email]> 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 <[hidden email]>
> > > > Gesendet: Freitag, September 14, 2018 1:16 AM
> > > > An: [hidden email]
> > > > 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> --
>
>
> -- Enrico Olivelli
>
Reply | Threaded
Open this post in threaded view
|

Re: Java 11 and java.xml.bin, etc.

Enrico Olivelli
Il giorno mer 19 set 2018 alle ore 14:15 Sverre Moe <[hidden email]>
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 <
> [hidden email]
> >:
>
> > 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 <[hidden email]> 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 <
> > > [hidden email]
> > > >:
> > >
> > > > 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
> > > > <[hidden email]> 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 <[hidden email]>
> > > > > Gesendet: Freitag, September 14, 2018 1:16 AM
> > > > > An: [hidden email]
> > > > > 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: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
>