From: James M. <jam...@gm...> - 2019-01-08 19:42:06
|
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 <ja...@fa...> 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 <ja...@fa...> 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 >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |