Re: 2.7.2 for the New Year?

I agree a 2.7.2 release as soon as possible would be great. Sorry I haven't
done much work on Jython since the website but hopefully have a look at the
remaining issues soon.

My opinion on Java support would be to try for 8 and 11. Is there is a
compelling reason maintain 7 support? Dropping 7 would be nice for java
syntax and might allow some issue to be looked at e.g.
http://bugs.jython.org/issue2695, on the other hand we still have 7 working
now so maybe its worth keeping for this release? Also I think we should be
careful to say which we actually support vs which work. I think making
Jython run on 7,8,9,10 and 11 is possible but saying only 8 and 11 are
officially supported makes things a bit easier going forward?

I haven't followed the Gradle discussion, so based on nothing here are my
opinions. Gradle is probably the nicest Java build system available at the
moment (i.e its what I would use given free choice). I think the real gain
would be to produce a smaller jar without the bundled dependencies (but
with a POM) so that people could integrate jython into other products more
easily where they have their own dependencies to worry about. The current
build.gradle looks really nice! I will have a play with it. A related issue
I mean to look at is OSGi support
https://github.com/jythontools/jython/issues/79 I think adding some
manifest header would be enough to make a start on this so I would like to
try and do that for this release.

Here is the current master regtest result on my system (Linux, Oracle Java
11.0.1):
     [exec] 379 tests OK.
     [exec] 2 tests skipped:
     [exec]     test_codecmaps_hk test_curses
     [exec] 3 tests failed:
     [exec]     test_import_jy test_signal test_socket
     [exec] 3 fails unexpected:
     [exec]     test_import_jy test_signal test_socket

So its pretty close.

Thanks for all the hard work already done towards 2.7.2

James

On Tue, 8 Jan 2019 at 09:19, Jeff Allen <[email protected]> wrote:

> Thanks Jim.
>
> 1. It would be worth deciding whether we support Java 7. It was sensible a
> year ago, I think, especially given that ANTLR produced horrible (although
> apparently harmless) stack dumps on Java 8+: it didn't feel safe to build a
> release other than on 7, but that's now fixed. (Java 9 and 10 went by
> quickly, didn't they? I suppose this moves our target :( to 7/8 &11.)
>
> 2. Darn, I guess I missed the import. It came and went a few times in the
> edit. Normally I let the IDE sort this out last thing, but hold off with
> old code as it creates noise in the change set. Easily fixed.
>
> 3. I have done a partial job on this, only scanning some modules, and
> intend to revisit. I do not think this explains a problem with Pattern.
>
> 4. A reflective access warning only occur if you are foolish enough to ask
> for a real fd. I regard this as unavoidable (but we now avoid doing it
> ourselves).
>
> 5. Signals: not something I understand very well at present.
>
> Let's not forget ski8pped tests. However, each should have an issue, and
> that issue may not be in this milestone.
>
> I wonder if Adam's extra failing tests might be to do with localisation?
> Jeff Allen
>
> On 08/01/2019 06:12, Jim Baker wrote:
>
> I agree with "better now (not perfect)"! Some more observations:
>
> 1. Java 9 is no longer supported, only Java 8 and Java 11, both of which
> are under long term support.
> 2. Java 11 removes javax.xml.bind, which we import from DatatypeConverter;
> fortunately we don't actually use! Commenting out two lines of source means
> trunk builds just fine on Java 11.
> 3. The key change that prevented Java 9 support from running, namely
> introspecting Java packages without using the rt.jar, now mostly works. In
> the regrtest, it still fails with importing Pattern from java.util.regex,
> not certain why; the two other imports tested in import_star_from_java.py
> work fine.
> 4. We do have some illegal access warnings from jnr.posix in terms of
> reflected fields, which we will have to look into at some point. Of course,
> this is just the usual encapsulation of Java that Java 9 introduced.
> 5. The other failing test in test_signal when run on JDK 11 is related to
> the change over to how signals are exposed.
>
> To summarize:
>
>      [exec] 380 tests OK.
>      [exec] 2 tests skipped:
>      [exec]     test_codecmaps_hk test_curses
>      [exec] 2 tests failed:
>      [exec]     test_import_jy test_signal
>      [exec] 2 fails unexpected:
>      [exec]     test_import_jy test_signal
>      [exec] Result: 1
>
> So this looks very close to me!
>
> Lots of incredibly hard work has gone into 2.7.2, it's time to get it out
> there.
>
> - Jim
>
> On Mon, Jan 7, 2019 at 1:19 PM Jeff Allen <[email protected]> wrote:
>
>> Thanks Adam. Mainly I thought we couldn't ship in such a shabby state on
>> Java 9. Better now (not perfect). -- J.
>>
>> Jeff Allen
>>
>> On 07/01/2019 10:55, Adam Burke wrote:
>>
>> I just checked out out the head for the first time in a while and
>> regrtest is green for me under Windows and Java 8. Great to see.
>>
>> <0.02 put in jar>
>>
>> From my (front-row?) spectator seat, I think more frequent patch releases
>> wouldn't hurt. It's been a fair while since 2.7.1. If the tests are green,
>> bugs have been fixed, and more stuff works in 2.7.2 than 2.7.1, I would
>> vote to ship.
>>
>> If the gradle stuff is working well enough to produce a jar, it could be
>> included and marked experimental? I'm sure it would be useful to projects
>> with dependencies on jython from maven or gradle projects.
>>
>> Obviously it would be good to announce the beta on the website though.
>>
>> Cheers
>> Adam
>>
>> _______________________________________________
>> Jython-dev mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
> _______________________________________________
> Jython-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev