[wildfly-dev] Smoothing the move from JDK 6 to 7

[Gunnar Morling]

Hi,

> Also it means that we have to use JDK7 IDE profiles with the source,
which increase the odds of using JDK types/methods/fields/values that do
not exist in JDK6.

You could use Animal Sniffer [1] to make sure no Java 7 APIs are referenced.

We're doing the same in several Hibernate projects which need to use Java 7
for compilation but have Java 6 as target runtime. Animal Sniffer provides
a Maven plug-in, Ant task etc. which fail the build if APIs are used which
don't exist in a configured target baseline.

--Gunnar

[1] http://mojo.codehaus.org/animal-sniffer/



2013/8/31 Jason Greene <jason.greene at redhat.com>

> If EAP diverges due to a patch, and then later we merge upstream after
> someone updates the entire file to use diamonds, then we get huge deltas
> referring to a ton of differences that have no practical value, and
> potentially conflicts.
>
> Also it means that we have to use JDK7 IDE profiles with the source, which
> increase the odds of using JDK types/methods/fields/values that do not
> exist in JDK6.
>
>
> On Aug 30, 2013, at 5:18 PM, David M. Lloyd <david.lloyd at redhat.com>
> wrote:
>
> > (Forgot to send to list!)
> >
> > This lets us compile EAP with JDK 7 syntax though, that's the point.  We
> > can backport 1.7 syntax patches.
> >
> > On 08/30/2013 05:01 PM, Jason Greene wrote:
> >> The biggest problem with the diamond operators isn't bytecode, its back
> porting into EAP.
> >>
> >> On Aug 30, 2013, at 4:46 PM, David M. Lloyd <david.lloyd at redhat.com>
> wrote:
> >>
> >>> At this point in time, I'd say just about everyone wants to move ahead
> >>> with Java 7 syntax because let's face it: there's a lot of nice stuff
> in
> >>> there.  But until now, doing so meant that projects which rely on
> >>> running on JDK 6 until the heat-death of the universe are on a fast
> road
> >>> to pain and suffering.
> >>>
> >>> Well, all that ends today... introducing "seven2six" [1], a tiny tool
> >>> (only two source files) which losslessly converts version 51.0 (1.7)
> >>> class files to version 50.0 (1.6).
> >>>
> >>> With this tool in your build, you can switch your language level to 1.7
> >>> without alienating your 1.6 users.  I've already got this integrated
> >>> with JBoss Modules (it's quite simple to do as the README describes).
> >>>
> >>> This could end Brian's major pet peeve of rooting out diamond operator
> >>> usage in new WildFly files, among other issues.  I want to know what
> you
> >>> guys think of bringing this in to WildFly (maybe even in to
> >>> jboss-parent, honestly).  The initial version is released to Maven
> >>> already at org.jboss.seven2six:seven2six:1.0.Final so feel free to mess
> >>> with it and suggest improvements (just use the GH bug tracker for now I
> >>> guess).
> >>>
> >>> Thanks to Kabir Khan for the original idea and implementation/POC (I
> >>> just polished it up with ASM), and James Perkins for the Maven
> >>> integration code.
> >>>
> >>> [1] https://github.com/dmlloyd/seven2six
> >>> --
> >>> - DML
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >> --
> >> Jason T. Greene
> >> WildFly Lead / JBoss EAP Platform Architect
> >> JBoss, a division of Red Hat
> >>
> >
> >
> > --
> > - DML
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130901/b4ebe16b/attachment.html