On Fri, 9 Jun 2017 at 02:35, Gary Gregory <garydgreg...@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 6:29 PM, Simon Spero <sesunc...@gmail.com> wrote:
>
> > There is a one other compatibility issue, which can be seen in the
> attached
> > code:
> >
> > import java.nio.charset.StandardCharsets;
> >
> > public class Weasel {
> >
> > private static final String US_ASCII = "US-ASCII";
> > private static final String UTF_8 = "UTF-8";
> > private static final String STANDARD_US_ASCII =
> > StandardCharsets.US_ASCII.name();
> > private static final String STANDARD_UTF_8 =
> > StandardCharsets.UTF_8.name
> > ();
> >
> > public static void main(String[] args) {
> >
> > switch (args[0]) {
> > case US_ASCII:
> > System.out.println("USA! USA!");
> > break;
> > case UTF_8:
> > System.out.println("Emoji Lovin' Hippies!");
> > break;
> > default:
> > System.out.println("Weirdo.");
> > }
> > }
> > }
> >
> >
> > This code compiles.
> > However, if the case labels are changed to STANDARD_US_ASCII and
> > STANDARD_UTF_8, the compilation will fail, because the case labels are
> no
> > longer constant expressions.
> > In the actual code, this means that code compiled against an older
> version
> > of the library would work against the new code (because the old strings
> had
> > already been inlined), but could not be re-compiled.
> >
>
> Thank you for doing this research and POC :-)
>
> But Ugh! :-( We shot ourselves in the foot here.
D'oh. Sorry about that guys :-(
>
> Benedikt, how do you feel about a fix and a new RC?
>
> Gary
>
>
> >
> > I don't know why anyone would be doing this...
> >
> > (CLIRR pre-dates string switches)
> >
> > Simon
> >
> > On Thu, Jun 8, 2017 at 5:10 PM, sebb <seb...@gmail.com> wrote:
> >
> > > On 8 June 2017 at 18:09, Gary Gregory <garydgreg...@gmail.com> wrote:
> > > > On Thu, Jun 8, 2017 at 9:57 AM, sebb <seb...@gmail.com> wrote:
> > > >
> > > >> On 8 June 2017 at 17:19, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> > > >> > On Thu, Jun 8, 2017 at 5:38 AM, Simon Spero <sesunc...@gmail.com>
> > > wrote:
> > > >> >
> > > >> >> [A Note, not a vote :) ]
> > > >> >>
> > > >> >> 1. Clirr is generally considered obsolete, as it hadn't been
> worked
> > > on
> > > >> for
> > > >> >> about ten years. japicmp is a good replacement, especially for
> > > report
> > > >> >> generation, and is used in other commons projects.
> > > >> >>
> > > >> >
> > > >> > IIRC, we've started using japicm here and there. Each component
> can
> > > >> decide.
> > > >> > But yes, Clirr looks pretty dead.
> > > >> >
> > > >> >
> > > >> >> 2. Are the "changes" to the values in CharEncoding really
> > > necessary[1]
> > > >> (The
> > > >> >> deprecation surely is). Technically this is a potentially
> breaking
> > > >> binary
> > > >> >> incompatible change, as constant strings and primitives are
> inlined
> > > at
> > > >> >> compile time. [2]
> > > >> >> In this particular case, the results of load-time evaluation of
> the
> > > new
> > > >> >> initialization expressions are identical to the old constants,
> so
> > > it's
> > > >> >> behaviourally compatible; however, since this is the case, and
> > since
> > > >> it's
> > > >> >> all deprecated anyway, why not leave the old values in-place?
> > > >> >>
> > > >> >
> > > >> > The changes are not "necessary" that for sure and we do get Clirr
> > > >> warnings:
> > > >> >
> > > >> > Value of field ISO_8859_1 is no longer a compile-time constant
> > > >> > Value of field US_ASCII is no longer a compile-time constant
> > > >> > Value of field UTF_16 is no longer a compile-time constant
> > > >> > Value of field UTF_16BE is no longer a compile-time constant
> > > >> > Value of field UTF_16LE is no longer a compile-time constant
> > > >> > Value of field UTF_8 is no longer a compile-time constant
> > > >> >
> > > >> > It's source compatible. What is the issue at runtime that could
> hurt
> > > >> users?
> > > >>
> > > >> As the OP wrote, constants are inlined by the compiler.
> > > >> So unless all code is recompiled, if it referenced the constant it
> may
> > > >> have a stale value.
> > > >> That is not binary compatible.
> > > >>
> > > >
> > > > But in this case the actual values are the same are they not? So what
> > is
> > > > the difference? Would this only be a problem if we changed the string
> > > > values?
> > >
> > > AFAIK the compiler only inlines compile-time constants.
> > > So going forward, the values won't be inlined.
> > > I assume the behaviour will be unaffected since the runtime value
> > > should be the same as the constant.
> > >
> > > The release notes really ought to explain why the Clirr report items
> > > aren't a problem.
> > >
> > > > Which we can't since these are defined in the JRE. And the JRE is
> > > > unlikely to change those.
> > > >
> > > > Gary
> > > >
> > > >
> > > >>
> > > >> >
> > > >> >> 3. JDK9 adds some extra parameters to the Deprecated annotation
> > (most
> > > >> >> notably forRemoval=true, which is used to indicate that the
> > > annotated
> > > >> item
> > > >> >> is really really deprecated.) It's not needed in this case, but
> > is
> > > >> worth
> > > >> >> thinking about when jdk9 is eventually released (latest schedule
> > > >> change :
> > > >> >> from 7/27/2017 to 9/21/2017).
> > > >> >>
> > > >> >
> > > >> > I do not think we plan on making Java 9 a requirement for any
> > current
> > > >> > project.
> > > >> >
> > > >> > Gary
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> Simon
> > > >> >>
> > > >> >> [1] https://github.com/apache/commons-lang/commit/7c19a1ff4c217
> > > >> >> f03c0be62baf1169d689f566825#diff-820a48456e11e85bf6cf5356c1aed4
> > baR48
> > > >> >>
> > > >> >> [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-
> > > >> >> 13.html#jls-13.4.9
> > > >> >>
> > > >> >> On Jun 8, 2017 4:48 AM, "Benedikt Ritter" <brit...@apache.org>
> > > wrote:
> > > >> >>
> > > >> >> > Hello,
> > > >> >> >
> > > >> >> > we have fixed quite a few bugs and added some nice new features
> > > since
> > > >> >> > Commons Lang 3.5 was released, so I would like to release
> Commons
> > > Lang
> > > >> >> 3.6
> > > >> >> > based on RC3.
> > > >> >> > The following issues have been fixed since RC2:
> > > >> >> >
> > > >> >> > - Site build now works from source distribution
> > > >> >> > - IBM JDK test failures have been fixed
> > > >> >> > - Automatic-Module-Name MANIFEST entry has been added for Java
> 9
> > > >> >> > compatibility
> > > >> >> >
> > > >> >> > Commons Lang 3.6 R3 is available for review here:
> > > >> >> > https://dist.apache.org/repos/dist/dev/commons/lang (svn
> > revision
> > > >> >> 19928)
> > > >> >> >
> > > >> >> > The tag is here:
> > > >> >> > https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;
> > > a=tag;h=
> > > >> >> > e454e79463ffbbd9114db43019dd211debbcc105
> > > >> >> >
> > > >> >> > Commit ID the tag points at:
> > > >> >> > 360198dfb6a2d68f1702f616dfacee34ae0541bb
> > > >> >> >
> > > >> >> > Maven Artifacts:
> > > >> >> > https://repository.apache.org/content/repositories/
> > > >> >> orgapachecommons-1250
> > > >> >> >
> > > >> >> > These are the Maven artifacts and their hashes:
> > > >> >> >
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > > javadoc.jar
> > > >> >> > (SHA1: c8adadb6c0b56c73f2cc2b4c77a09bfe34ec3a66)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > > >> sources.jar.asc
> > > >> >> > (SHA1: 46347c179ca9246d146d653bdc7363bda6f17d44)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom.asc
> > > >> >> > (SHA1: 1309d4f3dd41a01ff9dd1f3c1a6eee10dad1ef77)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.pom
> > > >> >> > (SHA1: 0fb4499188c94c63b3cba44f12481e193708c4a8)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar.asc
> > > >> >> > (SHA1: e67e7d44751f1e346c2fda496193cbe251cfe098)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > > >> javadoc.jar.asc
> > > >> >> > (SHA1: 6b19fa12d319ced69c0f8a27001569514711f9dc)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > > sources.jar
> > > >> >> > (SHA1: f89c1df082d6f67cb7c956715c56d7e7a0508d0a)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6.jar
> > > >> >> > (SHA1: e58ba08b01d37a023746f0987dcd910036a63021)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > > tests.jar.asc
> > > >> >> > (SHA1: af050e8c29a801a5d6783268c56230b814f56240)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > > >> >> > test-sources.jar.asc
> > > >> >> > (SHA1: 71e4c11efb9e3b2eff402ba4648d21822fb8da4a)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > > >> test-sources.jar
> > > >> >> > (SHA1: 04a0fc8293d4ed64a54dcc9ba5f996776a4657ea)
> > > >> >> > /org/apache/commons/commons-lang3/3.6/commons-lang3-3.6-
> > tests.jar
> > > >> >> > (SHA1: 87993a16c14a251062e3fe860fa53b5ef5304a0f)
> > > >> >> >
> > > >> >> > I have tested this with JDK 7, JDK 8 and JDK 9 EA b172 using
> > Maven
> > > >> 3.5.0.
> > > >> >> >
> > > >> >> > Details of changes since 3.5 are in the release notes:
> > > >> >> >
> https://dist.apache.org/repos/dist/dev/commons/lang/RELEASE-
> > > >> NOTES.txt
> > > >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_
> > > >> >> > RC3/changes-report.html
> > > >> >> >
> > > >> >> > Site:
> > > >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_RC3
> > > >> >> > (note some *relative* links are broken and the 3.6 directories
> > are
> > > >> >> > not yet created - these will be OK once the site is deployed)
> > > >> >> >
> > > >> >> > Clirr Report (compared to 3.5):
> > > >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_
> > > >> >> > RC3/clirr-report.html
> > > >> >> >
> > > >> >> > RAT Report:
> > > >> >> > http://home.apache.org/~britter/commons/lang/LANG_3_6_
> > > >> >> > RC3/rat-report.html
> > > >> >> >
> > > >> >> > KEYS:
> > > >> >> > https://www.apache.org/dist/commons/KEYS
> > > >> >> >
> > > >> >> > Please review the release candidate and vote.
> > > >> >> > This vote will close no sooner that 72 hours from now,
> > > >> >> > i.e. sometime after 11:00 CEST (UTC+2) 11-June 2017
> > > >> >> >
> > > >> >> > [ ] +1 Release these artifacts
> > > >> >> > [ ] +0 OK, but...
> > > >> >> > [ ] -0 OK, but really should fix...
> > > >> >> > [ ] -1 I oppose this release because...
> > > >> >> >
> > > >> >> > Thanks!
> > > >> >> > Benedikt
> > > >> >> > ------------------------------------------------------------
> > > ---------
> > > >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >> >> >
> > > >> >> >
> > > >> >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>
