Menu
▾
▴
jython-dev
|
From: Jeff A. <ja...@fa...> - 2019-07-26 20:54:38
|
When the project set out to create Jython 2.7.2, it was reasonable still to support Java 7. Now we find ourselves on the verge of a 2.7.2 beta release, Java 8 seems the logical minimum. We currently build and test on Java 7 but some things would resolve themselves if we could move on. We intend to support "before and after Jigsaw" JVMs (say 8 and 11). Straw poll: does anyone amongst our users have a good reason why Jython 2.7.2 should run on Java 7? -- Jeff Allen |
|
From: Jim B. <jim...@py...> - 2019-07-26 23:49:14
|
Previously we resolved this issue based on what version of Java is publicly and currently supported. Given Java 7 was end of lifed a few years ago, and these problems, it makes sense to require Java 8 (or 11, for similar reasons). On Fri, Jul 26, 2019, 1:54 PM Jeff Allen <ja...@fa...> wrote: > When the project set out to create Jython 2.7.2, it was reasonable still > to support Java 7. Now we find ourselves on the verge of a 2.7.2 beta > release, Java 8 seems the logical minimum. We currently build and test > on Java 7 but some things would resolve themselves if we could move on. > We intend to support "before and after Jigsaw" JVMs (say 8 and 11). > > Straw poll: does anyone amongst our users have a good reason why Jython > 2.7.2 should run on Java 7? > > -- > Jeff Allen > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Stefan R. <ste...@gm...> - 2019-07-27 12:02:12
|
AFAIK, the current Jython 2.7 master still compiles and runs with Java 7. So why would we drop that support right now? At least I think we shouldn't explicitly/on purpose destroy Java 7 compatibility e.g. by inserting a lambda or so somewhere. Dropping Java 7 support just "one second" before 2.7.2 release looks rushed to me. IMO the right moment to drop support for something is right after a release not in the last moment before a release. It's usually good practice to have a designated last release to support something. For 2.7.2 it was decided some time ago that it would be that last release to support Java 7 IIRC. I personally know a company where still Java 6 is floating around and I suspect there are plenty. So the EOL argument is more a virtual one. Anyway, I'm not fanatic for Java 7, it just appears to be a low-hanging fruit to keep the compatibility just on these last meters till the release. And all the named reasons sum up for me to vote for Java 7 support in 2.7.2. At least, let's make Java 7 support "on best effort", i.e. avoid to break it explicitly, and Java 8 can be the official support. That's my view. Best Stefan Am Sa., 27. Juli 2019 um 01:48 Uhr schrieb Jim Baker <jim...@py...>: > Previously we resolved this issue based on what version of Java is > publicly and currently supported. Given Java 7 was end of lifed a few years > ago, and these problems, it makes sense to require Java 8 (or 11, for > similar reasons). > > On Fri, Jul 26, 2019, 1:54 PM Jeff Allen <ja...@fa...> wrote: > >> When the project set out to create Jython 2.7.2, it was reasonable still >> to support Java 7. Now we find ourselves on the verge of a 2.7.2 beta >> release, Java 8 seems the logical minimum. We currently build and test >> on Java 7 but some things would resolve themselves if we could move on. >> We intend to support "before and after Jigsaw" JVMs (say 8 and 11). >> >> Straw poll: does anyone amongst our users have a good reason why Jython >> 2.7.2 should run on Java 7? >> >> -- >> Jeff Allen >> >> >> >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > _______________________________________________ > Jython-users mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users > |
|
From: Stefan R. <ste...@gm...> - 2019-07-27 18:52:03
|
> Are we talking weeks or or over a year away from a release? On Jython-dev mailing list, Jeff recently started a thread about Jython 2.7.2 beta phase details. So I assumed in my vote that the release is reasonably close. I agree that supporting Java 7 does not make sense if that's not the case. I also assumed that Jython 2.7.2 would be forward compatible as work went into supporting Java 9+. It runs well also on Java 8 right now. And if not in some aspects, I doubt that it would do much good just to say "J7 is not supported any more" without doing actual changes beyond stopping building and testing on J7. Actually and significantly leveraging Java 8 advantages requires additional work and wouldn't be feasible for a soonish release. Better cut here (like it was the plan) and do a proper Java 8(+?) integration for 2.7.3 and/or 3. > ...seems more important that trying to support people who decided not to upgrade 3-4 years ago from J7. I also agree here. My point was not to support them; just not to "intentionally" hurt them without compelling reason. Regarding the elephant - I'll postpone that topic for now. Am Sa., 27. Juli 2019 um 18:32 Uhr schrieb James Klo <ji...@sr...>: > This seems to be the most credible argument for not changing to J8 for > 2.7.2. > > However lets unpack that a bit. > > Dropping Java 7 support just "one second" before 2.7.2 release looks > rushed to me. > > > While I agree in theory - “one second” in Jython time appears to be in the > year range given the amount of resources that I have observed to supporting > advancement of the project. Are we talking weeks or or over a year away > from a release? If latter I think in the best interests of both the current > and future community that would like to utilize 2.7.2 - J8 is a better > choice. That opens the door wider community wanting to incorporate. For us, > we’ve had to stifle development on a custom lexer library that we access > via pygments in order to retain Jython support. If we’re saying a release > is eminent within a few weeks to a month I say just wrap up with J7, and > the next version makes J8 the minimum. But Jython is quickly advancing into > irrelevance as fewer and fewer projects are left that will work with J7. > Modern projects won’t want to refactor libraries backwards just to gain > Jython support - they’ll start looking for alternatives that are more > modern. > > I personally know a company where still Java 6 is floating around and I > suspect there are plenty. So the EOL argument > is more a virtual one. > > > OpenJDK is where the world is at in the post-apocalyptic world known as > Oracle Java. Those companies that have chosen to stick with 6 (and even 7 > at this point) have concluded that they have the resources to support their > back porting modern frameworks to fit their circumstances. I hate sounding > like a dick, but given the number of developer resources available to > support the Jython project - that already moves at a snails pace - growing > adoption and the developer community around a solution that a wider > audience can use seems more important that trying to support people who > decided not to upgrade 3-4 years ago from J7. > > Jeff mentions: > > We currently build and test >>> on Java 7 but some things would resolve themselves if we could move on. >> >> > Could there be some elaboration here? What issues on the 2.7.2 milestone > would be solved by moving to J8? Pluses and minuses here would be helpful. > > The other elephant in the room is certainly around Python 3. The looming > end of life for Python 2 is fast approaching. While I concede this isn’t > necessarily a problem for Jython but it does define what a final 2.7.x > features would need to be supported. How long does this project intend to > support the Python 2.7 language spec? When do we support Python 3? I’m > already seeing a fair number of modules not being supported for Python 2. > The last time I had to build our runtime environment I had to go and pull > package dependencies from sources as I could no longer download compatible > versions for Jython. With the vast majority of new Python scripting > happening around Python 3 - this is only going to get worse Furthering J7 > much longer furthers an ecosystem of frameworks that is all but obsolete > and difficult to incorporate into modern projects. > > My vote. If 2.7.2 is close to release (meaning days to weeks) stick to J7 > for the sake of getting it done. If we’re talking more than a month or more > - I vote J8 as IMO throws out a lifeline for the Jython project as a whole. > > - jk > > |
|
From: Jeff A. <ja...@fa...> - 2019-08-10 06:49:06
|
On 27/07/2019 17:32, James Klo via Jython-users wrote: > [snipped lots of other good points] > > Jeff mentions: >> >> We currently build and test >> on Java 7 but some things would resolve themselves if we >> could move on. >> > > Could there be some elaboration here? What issues on the 2.7.2 > milestone would be solved by moving to J8? Pluses and minuses here > would be helpful. I was thinking of: * https://bugs.jython.org/issue2770 (SSL test failures) * I wrote a substitute base64 decoder in https://bugs.jython.org/issue2663 (which was fun, but it could be removed at Java 8). * The odd place where a lambda would save nugatory work (logging). Only the first is an actual problem for users (who have to downgrade their JAR to match their insecure JVM). There may be other bugs we didn't consider blockers that are also 7-isms. Jeff Jeff Allen |
|
From: Jeff A. <ja...@fa...> - 2019-09-01 10:11:47
|
It is a fact that we remain source-compatible with Java 7. We test on 7, 8 and 11 in the CI. Java 7 is past EOL, and no-one should really be using it in production, but a few may still be running Jython on it. (No-one has said they are, so it's at best a reasonable conjecture.) I have observed test failures with SSL on Java 7, that disappear on Java 8, since upgrading the BC jars to satisfy security concerns. I propose we compile releases up to 2.7.2 final with Java 8, and for the Java 8 target. (It really doesn't seem right to compile it with an unsupported Java 7.) This means the Jython that users download will require a minimum of Java 8 to run. We support up to Java 11, with reasonable confidence beyond that. But we remain source-compatible with Java 7 up to 2.7.2 final. Then, if a user really needs a version that runs on Java 7, we can show them how to build one. I believe it is a matter of defining properties in or around the Ant build, down-grading the BC JARs if need be, and making a snapshot installer. It will be an "unofficial" build that we do not undertake to support, and comes with a number of (additional) known defects. Good compromise? Jeff Jeff Allen On 26/07/2019 21:54, Jeff Allen wrote: > When the project set out to create Jython 2.7.2, it was reasonable > still to support Java 7. Now we find ourselves on the verge of a 2.7.2 > beta release, Java 8 seems the logical minimum. We currently build and > test on Java 7 but some things would resolve themselves if we could > move on. We intend to support "before and after Jigsaw" JVMs (say 8 > and 11). > > Straw poll: does anyone amongst our users have a good reason why > Jython 2.7.2 should run on Java 7? > |
|
From: Jim B. <jim...@py...> - 2019-09-01 14:29:29
|
+100 I like this well-considered compromise. Source compatibility with Java 7 ensures it is possible for a self service model if there are users who actually need Java 7. Meanwhile we are able to ensure all of our dependencies are supported, which is key for any release. This approach also gives an immediate path forward to being on Java 11, the only current LTS option, for a Jython 2.7.3, as well as setting up for Jython 3.x development. - Jim On Sun, Sep 1, 2019 at 4:11 AM Jeff Allen <ja...@fa...> wrote: > It is a fact that we remain source-compatible with Java 7. We test on 7, > 8 and 11 in the CI. > > Java 7 is past EOL, and no-one should really be using it in production, > but a few may still be running Jython on it. (No-one has said they are, > so it's at best a reasonable conjecture.) I have observed test failures > with SSL on Java 7, that disappear on Java 8, since upgrading the BC > jars to satisfy security concerns. > > I propose we compile releases up to 2.7.2 final with Java 8, and for the > Java 8 target. (It really doesn't seem right to compile it with an > unsupported Java 7.) This means the Jython that users download will > require a minimum of Java 8 to run. We support up to Java 11, with > reasonable confidence beyond that. > > But we remain source-compatible with Java 7 up to 2.7.2 final. Then, if > a user really needs a version that runs on Java 7, we can show them how > to build one. I believe it is a matter of defining properties in or > around the Ant build, down-grading the BC JARs if need be, and making a > snapshot installer. It will be an "unofficial" build that we do not > undertake to support, and comes with a number of (additional) known > defects. > > Good compromise? > > Jeff > > Jeff Allen > > On 26/07/2019 21:54, Jeff Allen wrote: > > When the project set out to create Jython 2.7.2, it was reasonable > > still to support Java 7. Now we find ourselves on the verge of a 2.7.2 > > beta release, Java 8 seems the logical minimum. We currently build and > > test on Java 7 but some things would resolve themselves if we could > > move on. We intend to support "before and after Jigsaw" JVMs (say 8 > > and 11). > > > > Straw poll: does anyone amongst our users have a good reason why > > Jython 2.7.2 should run on Java 7? > > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Pekka K. <pe...@ik...> - 2019-09-02 22:01:14
|
Jim Baker wrote::
>
> +100
>
> I like this well-considered compromise. Source compatibility with Java 7 ensures it is possible for a self service model if there are users who actually need Java 7. Meanwhile we are able to ensure all of our dependencies are supported, which is key for any release.
+1
> This approach also gives an immediate path forward to being on Java 11, the only current LTS option, for a Jython 2.7.3, as well as setting up for Jython 3.x development.
Has there been discussion lately about Jython 2.7.3 vs Jython 3? I'd
personally like to see all efforts concentrated on Jython 3 once
Jython 2.7.2 is out. Python 2 EOL being very near, more and more
projects are dropping Python 2 support and at the same time they drop
Jython support as well. For us Jython support is the primary reason to
support Python 2 still after the EOL, but I cannot see us doing it
past 2020 anymore.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
|
|
From: Jeff A. <ja...@fa...> - 2019-09-03 06:31:42
|
Good, I'm glad that seems sensible. I think there has to be a 2.7.3 as a target for bug-fixes etc.. For me 2.7.2 as a thing we have to get out to clear space for 3. Separate topic. Jeff Allen On 02/09/2019 23:00, Pekka Klärck wrote: > Jim Baker wrote:: >> +100 >> >> I like this well-considered compromise. Source compatibility with Java 7 ensures it is possible for a self service model if there are users who actually need Java 7. Meanwhile we are able to ensure all of our dependencies are supported, which is key for any release. > +1 > >> This approach also gives an immediate path forward to being on Java 11, the only current LTS option, for a Jython 2.7.3, as well as setting up for Jython 3.x development. > Has there been discussion lately about Jython 2.7.3 vs Jython 3? I'd > personally like to see all efforts concentrated on Jython 3 once > Jython 2.7.2 is out. Python 2 EOL being very near, more and more > projects are dropping Python 2 support and at the same time they drop > Jython support as well. For us Jython support is the primary reason to > support Python 2 still after the EOL, but I cannot see us doing it > past 2020 anymore. > > Cheers, > .peke |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X