jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2018-09-07 - 2018-09-14)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     344 ( +0)
  closed  2378 ( +1)
  total   2722 ( +1)

Open issues with patches: 27   


Issues opened (1)
=================

#2703: JycompileAntTask cannot find org.python.apache.tools.ant.taskd
http://bugs.jython.org/issue2703  opened by jeff.allen



Most recent 15 issues with no replies (15)
==========================================

#2703: JycompileAntTask cannot find org.python.apache.tools.ant.taskd
http://bugs.jython.org/issue2703

#2698: urllib2.URLError: <urlopen error unknown url type: https>
http://bugs.jython.org/issue2698

#2697: name$py.class is ignored when in a JAR with name.py
http://bugs.jython.org/issue2697

#2684: WindowsError:[Error 123] The filename,directory name,or volume
http://bugs.jython.org/issue2684

#2680: Ignore Java accessibility rules selectively by package (Java 9
http://bugs.jython.org/issue2680

#2666: Imports in python from java do not work if there is a package 
http://bugs.jython.org/issue2666

#2665: Standalone jar includes test classes
http://bugs.jython.org/issue2665

#2663: Remove dependency on javax.xml.bind.DatatypeConverter
http://bugs.jython.org/issue2663

#2651: Travis Builds failing with *** buffer overflow detected ***
http://bugs.jython.org/issue2651

#2644: Representation of Java maps with String keys differs from Pyth
http://bugs.jython.org/issue2644

#2640: Virtualenv gets confused using paths with ~
http://bugs.jython.org/issue2640

#2633: Unicode garbled in writing to spreadsheet via openpyxl
http://bugs.jython.org/issue2633

#2631: jython 2.7.1 [Errno 107] Socket is not connected
http://bugs.jython.org/issue2631

#2618: socket.sendall no longer sends all
http://bugs.jython.org/issue2618

#2616: Incomplete / broken support for Certificate Revocation Lists
http://bugs.jython.org/issue2616



Most recent 15 issues waiting for review (15)
=============================================

#2635: AST.lineno ignored by compile
http://bugs.jython.org/issue2635

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
http://bugs.jython.org/issue2363

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embeds other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
http://bugs.jython.org/issue1842



Top 10 most discussed issues (1)
================================

#2658: Update jython.org website
http://bugs.jython.org/issue2658   8 msgs



Issues closed (1)
=================

#2702: java.lang.ClassCastException: org.python.core.PySingleton cann
http://bugs.jython.org/issue2702  closed by stefan.richthofer

Re: [Jython-dev] Do we intend the -jar option to work?

[Jeff A. <ja...@fa...>]

Yes, -cp ignored with -jar is a Java command thing. (I assume there's a 
good reason.) You can specify a classpath in the JAR. 
(https://stackoverflow.com/questions/15930782/call-java-jar-myfile-jar-with-additional-classpath-option)

It's really two proposals: remove -jar option (as it hasn't worked, so 
probably won't be missed); and deprecate runJar().

Jeff Allen

On 14/09/2018 09:34, Adam Burke wrote:
> > java -cp JyNI.jar -jar jython.jar
> This would be clean, useful, and feel right to me as a user.
> Adam
>
> On Fri, 14 Sep 2018 at 18:17, Stefan Richthofer 
> <ste...@gm... <mailto:ste...@gm...>> wrote:
>
>     No real opinion from me here, deprecation sounds better to me than
>     complete removal. However now that you are looking into this I
>     wanted to ask about this thing that bothered me a bit since I
>     started with Jython:
>     I always found it cumbersome that it isn't possible to run
>
>     |java -cp JyNI.jar -jar jython.jar|
>
>     Well, it runs but the -cp option is like ignored in this case.
>     Same if I try
>
>     |java -cp jython.jar:JyNI.jar -jar jython.jar|
>
>     One has to use one of these variants:
>
>     |java -cp jython.jar:JyNI.jar org.python.util.jython|
>
>     |jython -J-cp JyNI.jar |
>
>     That means for me, the most natural/intuitive way to launch Jython
>     with additional jars on the classpath does not work. Especially
>     when I was getting started with Jython I tried to use it as an
>     ordinary jar in terms of launching. I found it confusing that -cp
>     didn't work. Do you se a way to fix this? Or is this a JVM limitation?
>
>
>     Am Fr., 14. Sep. 2018 um 09:21 Uhr schrieb Jeff Allen
>     <ja...@fa... <mailto:ja...@fa...>>:
>
>         The question is a lot like that of SystemRestart, although I
>         haven't
>         done as much code archaeology. At present, we appear to
>         support an
>         option -jar to the jython command. Just type jython -h or see:
>
>         https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l91
>
>         But we don't. When you try to use it, all that happens, and
>         has happened
>         for a while, is this:
>
>         PS startup2> jython -jar test.jar
>         C:\Jython\2.7.0\bin\jython.exe: No module named __main__
>
>         The reason it doesn't work as promised is that before we try
>         to run the
>         JAR, we try this:
>
>         https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l316
>
>         and since the attempt to get an importer for a JAR is
>         successful, that
>         method returns true, and so we never check the -jar option.
>         The handler
>         runMainFromImporter() can't run it, because it expects a
>         __main__ module
>         (the -jar flag expects a __run__.py instead), and that leads
>         locally to
>         a System.exit().
>
>         Functionally, runMainFromImporter(), which was added in 2.7 to
>         implement
>         CPython behaviour, is very similar to the much older runJar()
>         although
>         not exactly the same. I think if we were doing this now, we'd
>         only
>         provide that later mechanism. CPython can run exactly the same
>         JAR (with
>         a __main__.py) that I'm using to test runMainFromImporter().
>
>         When I correct the logic so that -jar calls runJar() as it
>         used to, it
>         doesn't work that well anyway: the script runs, but my import
>         produces
>         warning messages about the (assumed) package name of my
>         script, and what
>         ought to be the source code context in the message looks like
>         binary
>         from the JAR. However, runJar() is public so maybe there are
>         applications that call it.
>
>         I'll make a commit with the -jar option restored for
>         comparison, but I
>         think the command option could be removed immediately and a
>         deprecation
>         warning slapped on runJar().
>
>         Any contrary thoughts?
>
>         Jeff
>
>         -- 
>         Jeff Allen
>
>
>
>         _______________________________________________
>         Jython-dev mailing list
>         Jyt...@li...
>         <mailto:Jyt...@li...>
>         https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>     _______________________________________________
>     Jython-dev mailing list
>     Jyt...@li...
>     <mailto:Jyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Do we intend the -jar option to work?

[Adam B. <ada...@gm...>]

> java -cp JyNI.jar -jar jython.jar

This would be clean, useful, and feel right to me as a user.

Adam

On Fri, 14 Sep 2018 at 18:17, Stefan Richthofer <ste...@gm...>
wrote:

> No real opinion from me here, deprecation sounds better to me than
> complete removal. However now that you are looking into this I wanted to
> ask about this thing that bothered me a bit since I started with Jython:
> I always found it cumbersome that it isn't possible to run
>
> java -cp JyNI.jar -jar jython.jar
>
> Well, it runs but the -cp option is like ignored in this case. Same if I
> try
>
> java -cp jython.jar:JyNI.jar -jar jython.jar
>
> One has to use one of these variants:
>
> java -cp jython.jar:JyNI.jar org.python.util.jython
>
> jython -J-cp JyNI.jar
>
> That means for me, the most natural/intuitive way to launch Jython with
> additional jars on the classpath does not work. Especially when I was
> getting started with Jython I tried to use it as an ordinary jar in terms
> of launching. I found it confusing that -cp didn't work. Do you se a way to
> fix this? Or is this a JVM limitation?
>
> Am Fr., 14. Sep. 2018 um 09:21 Uhr schrieb Jeff Allen <ja...@fa...
> >:
>
>> The question is a lot like that of SystemRestart, although I haven't
>> done as much code archaeology. At present, we appear to support an
>> option -jar to the jython command. Just type jython -h or see:
>>
>> https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l91
>>
>> But we don't. When you try to use it, all that happens, and has happened
>> for a while, is this:
>>
>> PS startup2> jython -jar test.jar
>> C:\Jython\2.7.0\bin\jython.exe: No module named __main__
>>
>> The reason it doesn't work as promised is that before we try to run the
>> JAR, we try this:
>>
>> https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l316
>>
>> and since the attempt to get an importer for a JAR is successful, that
>> method returns true, and so we never check the -jar option. The handler
>> runMainFromImporter() can't run it, because it expects a __main__ module
>> (the -jar flag expects a __run__.py instead), and that leads locally to
>> a System.exit().
>>
>> Functionally, runMainFromImporter(), which was added in 2.7 to implement
>> CPython behaviour, is very similar to the much older runJar() although
>> not exactly the same. I think if we were doing this now, we'd only
>> provide that later mechanism. CPython can run exactly the same JAR (with
>> a __main__.py) that I'm using to test runMainFromImporter().
>>
>> When I correct the logic so that -jar calls runJar() as it used to, it
>> doesn't work that well anyway: the script runs, but my import produces
>> warning messages about the (assumed) package name of my script, and what
>> ought to be the source code context in the message looks like binary
>> from the JAR. However, runJar() is public so maybe there are
>> applications that call it.
>>
>> I'll make a commit with the -jar option restored for comparison, but I
>> think the command option could be removed immediately and a deprecation
>> warning slapped on runJar().
>>
>> Any contrary thoughts?
>>
>> Jeff
>>
>> --
>> Jeff Allen
>>
>>
>>
>> _______________________________________________
>> 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
>

Re: [Jython-dev] Do we intend the -jar option to work?

[Stefan R. <ste...@gm...>]

No real opinion from me here, deprecation sounds better to me than complete
removal. However now that you are looking into this I wanted to ask about
this thing that bothered me a bit since I started with Jython:
I always found it cumbersome that it isn't possible to run

java -cp JyNI.jar -jar jython.jar

Well, it runs but the -cp option is like ignored in this case. Same if I try

java -cp jython.jar:JyNI.jar -jar jython.jar

One has to use one of these variants:

java -cp jython.jar:JyNI.jar org.python.util.jython

jython -J-cp JyNI.jar

That means for me, the most natural/intuitive way to launch Jython with
additional jars on the classpath does not work. Especially when I was
getting started with Jython I tried to use it as an ordinary jar in terms
of launching. I found it confusing that -cp didn't work. Do you se a way to
fix this? Or is this a JVM limitation?

Am Fr., 14. Sep. 2018 um 09:21 Uhr schrieb Jeff Allen <ja...@fa...>:

> The question is a lot like that of SystemRestart, although I haven't
> done as much code archaeology. At present, we appear to support an
> option -jar to the jython command. Just type jython -h or see:
>
> https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l91
>
> But we don't. When you try to use it, all that happens, and has happened
> for a while, is this:
>
> PS startup2> jython -jar test.jar
> C:\Jython\2.7.0\bin\jython.exe: No module named __main__
>
> The reason it doesn't work as promised is that before we try to run the
> JAR, we try this:
>
> https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l316
>
> and since the attempt to get an importer for a JAR is successful, that
> method returns true, and so we never check the -jar option. The handler
> runMainFromImporter() can't run it, because it expects a __main__ module
> (the -jar flag expects a __run__.py instead), and that leads locally to
> a System.exit().
>
> Functionally, runMainFromImporter(), which was added in 2.7 to implement
> CPython behaviour, is very similar to the much older runJar() although
> not exactly the same. I think if we were doing this now, we'd only
> provide that later mechanism. CPython can run exactly the same JAR (with
> a __main__.py) that I'm using to test runMainFromImporter().
>
> When I correct the logic so that -jar calls runJar() as it used to, it
> doesn't work that well anyway: the script runs, but my import produces
> warning messages about the (assumed) package name of my script, and what
> ought to be the source code context in the message looks like binary
> from the JAR. However, runJar() is public so maybe there are
> applications that call it.
>
> I'll make a commit with the -jar option restored for comparison, but I
> think the command option could be removed immediately and a deprecation
> warning slapped on runJar().
>
> Any contrary thoughts?
>
> Jeff
>
> --
> Jeff Allen
>
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

[Jython-dev] Do we intend the -jar option to work?

[Jeff A. <ja...@fa...>]

The question is a lot like that of SystemRestart, although I haven't 
done as much code archaeology. At present, we appear to support an 
option -jar to the jython command. Just type jython -h or see:

https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l91

But we don't. When you try to use it, all that happens, and has happened 
for a while, is this:

PS startup2> jython -jar test.jar
C:\Jython\2.7.0\bin\jython.exe: No module named __main__

The reason it doesn't work as promised is that before we try to run the 
JAR, we try this:

https://hg.python.org/jython/file/tip/src/org/python/util/jython.java#l316

and since the attempt to get an importer for a JAR is successful, that 
method returns true, and so we never check the -jar option. The handler 
runMainFromImporter() can't run it, because it expects a __main__ module 
(the -jar flag expects a __run__.py instead), and that leads locally to 
a System.exit().

Functionally, runMainFromImporter(), which was added in 2.7 to implement 
CPython behaviour, is very similar to the much older runJar() although 
not exactly the same. I think if we were doing this now, we'd only 
provide that later mechanism. CPython can run exactly the same JAR (with 
a __main__.py) that I'm using to test runMainFromImporter().

When I correct the logic so that -jar calls runJar() as it used to, it 
doesn't work that well anyway: the script runs, but my import produces 
warning messages about the (assumed) package name of my script, and what 
ought to be the source code context in the message looks like binary 
from the JAR. However, runJar() is public so maybe there are 
applications that call it.

I'll make a commit with the -jar option restored for comparison, but I 
think the command option could be removed immediately and a deprecation 
warning slapped on runJar().

Any contrary thoughts?

Jeff

-- 
Jeff Allen

Re: [Jython-dev] Versions in extlibs and Gradle

[Eero A. <eer...@ik...>]

Note that this was a quick and dirty proof of concept. If you are in favor
of adopting this, we would probably want to limit the 'newest version' to
'newest version with matching major version number'. As all libraries
seemed to have semantic-ish version numbers, that should be easy.

--
Eero

On Tue, Sep 11, 2018 at 9:14 AM Adam Burke <ada...@gm...> wrote:

> That's a pretty neat idea too, and I can see how it would work.
>
> Adam
>
> On Mon, 10 Sep 2018 at 23:16, Eero Aaltonen <eer...@ik...> wrote:
>
>> Relatedly someone has apparently already implemented the "report me any
>> new library versions" part
>> https://github.com/ben-manes/gradle-versions-plugin
>>
>> --
>> Eero
>>
>> On Mon, Sep 10, 2018 at 3:50 PM Eero Aaltonen <eer...@ik...>
>> wrote:
>>
>>> Hope I'm not late to the party.
>>>
>>> Personally I would prefer to have the defaults the other way around,
>>> namely:
>>> - default to fixed versions
>>> - grab the latest versions, if requested.
>>>
>>> Although Gradle has the concept of variants, I did not find variant
>>> support Java libraries. Instead, I wrote my own using an environment
>>> variable in
>>> https://github.com/eaaltonen/gradle-dependency-proposal
>>>
>>> The idea is that you could test against the latest versions of libraries
>>> very easily just by specifying `DEPS=latest` before the build.
>>>
>>> --
>>> Eero
>>>
>>> On Tue, Aug 21, 2018 at 4:29 AM Adam Burke <ada...@gm...>
>>> wrote:
>>>
>>>> Good topic. It’s really really good to see Jython moving to declared
>>>> dependency management instead of a jar folder. 2 cents from me ...
>>>>
>>>> At work I have always favoured strictly pinned versions, for
>>>> determinism / repeatability reasons. Being able to reproduce exactly the
>>>> classes being used at a particular point in time can be invaluable with
>>>> deep dependency trees and wide usage of different versions.
>>>>
>>>> People usually aren’t too shy about forcing different dependency
>>>> versions if needed in my experience.
>>>>
>>>> I do see some advantages to the less strict versions, around
>>>> maintenance and advertising to developers the choice of specific version is
>>>> somewhat arbitrary (which it often is, especially when talking about patch
>>>> versions.)
>>>>
>>>> This blog post has a good discussion about pinned versions
>>>>
>>>> https://brock.io/post/repeatable_android_builds/
>>>>
>>>>
>>>> It also points on to an interesting dependency lock plugin.
>>>>
>>>> https://github.com/nebula-plugins/gradle-dependency-lock-plugin
>>>>
>>>> I haven’t used that plugin in anger, but it might allow the best of
>>>> both worlds.
>>>>
>>>> Cheers
>>>> Adam
>>>>
>>>> 在 2018年8月14日，上午5:36，Jeff Allen <ja...@fa...> 写道：
>>>>
>>>> One of the things we were looking forward to with Gradle was that it
>>>> would become easier to control the versions of JARs (modules) we depend on.
>>>> Gradle can get quite sophisticated about this: you can have anything you
>>>> want. Only ... what do we want?
>>>>
>>>> * If we only specify a module name, we'll get the latest all the time
>>>>   (with obvious risks).
>>>> * If a module moves to a new API we aren't ready for, we can specify
>>>>   the version in part (3.1.+), and continue to take minor/patch
>>>> releases.
>>>> * If a module has to be pinned to an exact version, we can name it
>>>>   explicitly (or an acceptable range).
>>>>
>>>> At least we don't have to check the JAR in: just change the dependency
>>>> statements (once we use Gradle exclusively). If we build distributions with
>>>> Gradle like the JARs we build now, I believe we end up jarjar'ring the
>>>> dynamically downloaded modules, but I haven't tried that yet.
>>>>
>>>> A second dimension is when other projects cite Jython as a dependency
>>>> and get our dependencies transitively. Consuming projects are able to
>>>> override our version choices (if I understand correctly,
>>>> https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version).
>>>> The less specific we are about version,  the more helpful to consumers.
>>>> However, these might be untested combinations.
>>>>
>>>> Any thoughts how to tell, for a given module, what the sensible policy
>>>> would be?
>>>>
>>>> --
>>>> Jeff Allen
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Jython-dev mailing list
>>>> Jyt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Jython-dev mailing list
>>>> Jyt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>>>
>>>

Re: [Jython-dev] Versions in extlibs and Gradle

[Adam B. <ada...@gm...>]

That's a pretty neat idea too, and I can see how it would work.

Adam

On Mon, 10 Sep 2018 at 23:16, Eero Aaltonen <eer...@ik...> wrote:

> Relatedly someone has apparently already implemented the "report me any
> new library versions" part
> https://github.com/ben-manes/gradle-versions-plugin
>
> --
> Eero
>
> On Mon, Sep 10, 2018 at 3:50 PM Eero Aaltonen <eer...@ik...>
> wrote:
>
>> Hope I'm not late to the party.
>>
>> Personally I would prefer to have the defaults the other way around,
>> namely:
>> - default to fixed versions
>> - grab the latest versions, if requested.
>>
>> Although Gradle has the concept of variants, I did not find variant
>> support Java libraries. Instead, I wrote my own using an environment
>> variable in
>> https://github.com/eaaltonen/gradle-dependency-proposal
>>
>> The idea is that you could test against the latest versions of libraries
>> very easily just by specifying `DEPS=latest` before the build.
>>
>> --
>> Eero
>>
>> On Tue, Aug 21, 2018 at 4:29 AM Adam Burke <ada...@gm...>
>> wrote:
>>
>>> Good topic. It’s really really good to see Jython moving to declared
>>> dependency management instead of a jar folder. 2 cents from me ...
>>>
>>> At work I have always favoured strictly pinned versions, for determinism
>>> / repeatability reasons. Being able to reproduce exactly the classes being
>>> used at a particular point in time can be invaluable with deep dependency
>>> trees and wide usage of different versions.
>>>
>>> People usually aren’t too shy about forcing different dependency
>>> versions if needed in my experience.
>>>
>>> I do see some advantages to the less strict versions, around maintenance
>>> and advertising to developers the choice of specific version is somewhat
>>> arbitrary (which it often is, especially when talking about patch versions.)
>>>
>>> This blog post has a good discussion about pinned versions
>>>
>>> https://brock.io/post/repeatable_android_builds/
>>>
>>>
>>> It also points on to an interesting dependency lock plugin.
>>>
>>> https://github.com/nebula-plugins/gradle-dependency-lock-plugin
>>>
>>> I haven’t used that plugin in anger, but it might allow the best of both
>>> worlds.
>>>
>>> Cheers
>>> Adam
>>>
>>> 在 2018年8月14日，上午5:36，Jeff Allen <ja...@fa...> 写道：
>>>
>>> One of the things we were looking forward to with Gradle was that it
>>> would become easier to control the versions of JARs (modules) we depend on.
>>> Gradle can get quite sophisticated about this: you can have anything you
>>> want. Only ... what do we want?
>>>
>>> * If we only specify a module name, we'll get the latest all the time
>>>   (with obvious risks).
>>> * If a module moves to a new API we aren't ready for, we can specify
>>>   the version in part (3.1.+), and continue to take minor/patch releases.
>>> * If a module has to be pinned to an exact version, we can name it
>>>   explicitly (or an acceptable range).
>>>
>>> At least we don't have to check the JAR in: just change the dependency
>>> statements (once we use Gradle exclusively). If we build distributions with
>>> Gradle like the JARs we build now, I believe we end up jarjar'ring the
>>> dynamically downloaded modules, but I haven't tried that yet.
>>>
>>> A second dimension is when other projects cite Jython as a dependency
>>> and get our dependencies transitively. Consuming projects are able to
>>> override our version choices (if I understand correctly,
>>> https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version).
>>> The less specific we are about version,  the more helpful to consumers.
>>> However, these might be untested combinations.
>>>
>>> Any thoughts how to tell, for a given module, what the sensible policy
>>> would be?
>>>
>>> --
>>> Jeff Allen
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Jython-dev mailing list
>>> Jyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Jython-dev mailing list
>>> Jyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>>
>>

Re: [Jython-dev] Versions in extlibs and Gradle

[Eero A. <eer...@ik...>]

Relatedly someone has apparently already implemented the "report me any new
library versions" part
https://github.com/ben-manes/gradle-versions-plugin

--
Eero

On Mon, Sep 10, 2018 at 3:50 PM Eero Aaltonen <eer...@ik...> wrote:

> Hope I'm not late to the party.
>
> Personally I would prefer to have the defaults the other way around,
> namely:
> - default to fixed versions
> - grab the latest versions, if requested.
>
> Although Gradle has the concept of variants, I did not find variant
> support Java libraries. Instead, I wrote my own using an environment
> variable in
> https://github.com/eaaltonen/gradle-dependency-proposal
>
> The idea is that you could test against the latest versions of libraries
> very easily just by specifying `DEPS=latest` before the build.
>
> --
> Eero
>
> On Tue, Aug 21, 2018 at 4:29 AM Adam Burke <ada...@gm...>
> wrote:
>
>> Good topic. It’s really really good to see Jython moving to declared
>> dependency management instead of a jar folder. 2 cents from me ...
>>
>> At work I have always favoured strictly pinned versions, for determinism
>> / repeatability reasons. Being able to reproduce exactly the classes being
>> used at a particular point in time can be invaluable with deep dependency
>> trees and wide usage of different versions.
>>
>> People usually aren’t too shy about forcing different dependency versions
>> if needed in my experience.
>>
>> I do see some advantages to the less strict versions, around maintenance
>> and advertising to developers the choice of specific version is somewhat
>> arbitrary (which it often is, especially when talking about patch versions.)
>>
>> This blog post has a good discussion about pinned versions
>>
>> https://brock.io/post/repeatable_android_builds/
>>
>>
>> It also points on to an interesting dependency lock plugin.
>>
>> https://github.com/nebula-plugins/gradle-dependency-lock-plugin
>>
>> I haven’t used that plugin in anger, but it might allow the best of both
>> worlds.
>>
>> Cheers
>> Adam
>>
>> 在 2018年8月14日，上午5:36，Jeff Allen <ja...@fa...> 写道：
>>
>> One of the things we were looking forward to with Gradle was that it
>> would become easier to control the versions of JARs (modules) we depend on.
>> Gradle can get quite sophisticated about this: you can have anything you
>> want. Only ... what do we want?
>>
>> * If we only specify a module name, we'll get the latest all the time
>>   (with obvious risks).
>> * If a module moves to a new API we aren't ready for, we can specify
>>   the version in part (3.1.+), and continue to take minor/patch releases.
>> * If a module has to be pinned to an exact version, we can name it
>>   explicitly (or an acceptable range).
>>
>> At least we don't have to check the JAR in: just change the dependency
>> statements (once we use Gradle exclusively). If we build distributions with
>> Gradle like the JARs we build now, I believe we end up jarjar'ring the
>> dynamically downloaded modules, but I haven't tried that yet.
>>
>> A second dimension is when other projects cite Jython as a dependency and
>> get our dependencies transitively. Consuming projects are able to override
>> our version choices (if I understand correctly,
>> https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version).
>> The less specific we are about version,  the more helpful to consumers.
>> However, these might be untested combinations.
>>
>> Any thoughts how to tell, for a given module, what the sensible policy
>> would be?
>>
>> --
>> Jeff Allen
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>

Re: [Jython-dev] Versions in extlibs and Gradle

[Eero A. <eer...@ik...>]

Hope I'm not late to the party.

Personally I would prefer to have the defaults the other way around, namely:
- default to fixed versions
- grab the latest versions, if requested.

Although Gradle has the concept of variants, I did not find variant support
Java libraries. Instead, I wrote my own using an environment variable in
https://github.com/eaaltonen/gradle-dependency-proposal

The idea is that you could test against the latest versions of libraries
very easily just by specifying `DEPS=latest` before the build.

--
Eero

On Tue, Aug 21, 2018 at 4:29 AM Adam Burke <ada...@gm...> wrote:

> Good topic. It’s really really good to see Jython moving to declared
> dependency management instead of a jar folder. 2 cents from me ...
>
> At work I have always favoured strictly pinned versions, for determinism /
> repeatability reasons. Being able to reproduce exactly the classes being
> used at a particular point in time can be invaluable with deep dependency
> trees and wide usage of different versions.
>
> People usually aren’t too shy about forcing different dependency versions
> if needed in my experience.
>
> I do see some advantages to the less strict versions, around maintenance
> and advertising to developers the choice of specific version is somewhat
> arbitrary (which it often is, especially when talking about patch versions.)
>
> This blog post has a good discussion about pinned versions
>
> https://brock.io/post/repeatable_android_builds/
>
>
> It also points on to an interesting dependency lock plugin.
>
> https://github.com/nebula-plugins/gradle-dependency-lock-plugin
>
> I haven’t used that plugin in anger, but it might allow the best of both
> worlds.
>
> Cheers
> Adam
>
> 在 2018年8月14日，上午5:36，Jeff Allen <ja...@fa...> 写道：
>
> One of the things we were looking forward to with Gradle was that it would
> become easier to control the versions of JARs (modules) we depend on.
> Gradle can get quite sophisticated about this: you can have anything you
> want. Only ... what do we want?
>
> * If we only specify a module name, we'll get the latest all the time
>   (with obvious risks).
> * If a module moves to a new API we aren't ready for, we can specify
>   the version in part (3.1.+), and continue to take minor/patch releases.
> * If a module has to be pinned to an exact version, we can name it
>   explicitly (or an acceptable range).
>
> At least we don't have to check the JAR in: just change the dependency
> statements (once we use Gradle exclusively). If we build distributions with
> Gradle like the JARs we build now, I believe we end up jarjar'ring the
> dynamically downloaded modules, but I haven't tried that yet.
>
> A second dimension is when other projects cite Jython as a dependency and
> get our dependencies transitively. Consuming projects are able to override
> our version choices (if I understand correctly,
> https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version).
> The less specific we are about version,  the more helpful to consumers.
> However, these might be untested combinations.
>
> Any thoughts how to tell, for a given module, what the sensible policy
> would be?
>
> --
> Jeff Allen
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] JYTHONSTARTUP and PYTHONINSPECT

[Jim B. <jim...@py...>]

+1 on both of these updates, they look good and highly useful.

On Sat, Sep 8, 2018 at 12:13 PM, Jeff Allen <ja...@fa...> wrote:

> I'm remodelling jython.run along the lines of CPython main for clarity and
> conformity. CPython supports a couple of environment variables it has been
> easy to include. They seem useful, but are maybe not quite done in the
> Jython way. I'm not totally sure whether they should be JYTHONsomething or
> PYTHONsomething, or be registry entries instead, or as well. I'm canvassing
> opinions.
>
> Historically, our policy appears to be that configuration should be done
> via the registry (the registry files and the -D options). We *always* label
> registry items in the style "python.some.thing". We also honour some
> environment variables and mostly call them JYTHONsomething, except there's
> also PYTHONWARNINGS and PYTHONIOENCODING, I suppose because you want to see
> the same values as CPython (I think).
>
> I propose:
>
> JYTHONSTARTUP (registry python.startup) a file to run at the start of an
> interactive session. *J*YTHONSTARTUP because your script is unlikely to be
> the same for CPython. Precedence as with other variables.
>
> PYTHONINSPECT (registry python.inspect) if not empty, effectively sets the
> -i flag. (Any of these sources will *set* the flag, but none can turn it
> off.) It's called *P*YTHONINSPECT because setting it during execution
> should make us drop into interactive mode, instead of exiting, when the
> first SystemExit is raised. A script that does so may not be aware it's in
> Jython, so I favour the standard Python name.
>
> Jeff
>
> --
>
> Jeff Allen
>
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

[Jython-dev] JYTHONSTARTUP and PYTHONINSPECT

[Jeff A. <ja...@fa...>]

I'm remodelling jython.run along the lines of CPython main for clarity 
and conformity. CPython supports a couple of environment variables it 
has been easy to include. They seem useful, but are maybe not quite done 
in the Jython way. I'm not totally sure whether they should be 
JYTHONsomething or PYTHONsomething, or be registry entries instead, or 
as well. I'm canvassing opinions.

Historically, our policy appears to be that configuration should be done 
via the registry (the registry files and the -D options). We *always* 
label registry items in the style "python.some.thing". We also honour 
some environment variables and mostly call them JYTHONsomething, except 
there's also PYTHONWARNINGS and PYTHONIOENCODING, I suppose because you 
want to see the same values as CPython (I think).

I propose:

JYTHONSTARTUP (registry python.startup) a file to run at the start of an 
interactive session. *J*YTHONSTARTUP because your script is unlikely to 
be the same for CPython. Precedence as with other variables.

PYTHONINSPECT (registry python.inspect) if not empty, effectively sets 
the -i flag. (Any of these sources will *set* the flag, but none can 
turn it off.) It's called *P*YTHONINSPECT because setting it during 
execution should make us drop into interactive mode, instead of exiting, 
when the first SystemExit is raised. A script that does so may not be 
aware it's in Jython, so I favour the standard Python name.

Jeff

-- 

Jeff Allen

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2018-08-31 - 2018-09-07)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     344 ( +1)
  closed  2377 ( +0)
  total   2721 ( +1)

Open issues with patches: 27   


Issues opened (1)
=================

#2702: java.lang.ClassCastException: org.python.core.PySingleton cann
http://bugs.jython.org/issue2702  opened by ucguy



Most recent 15 issues with no replies (15)
==========================================

#2698: urllib2.URLError: <urlopen error unknown url type: https>
http://bugs.jython.org/issue2698

#2697: name$py.class is ignored when in a JAR with name.py
http://bugs.jython.org/issue2697

#2684: WindowsError:[Error 123] The filename,directory name,or volume
http://bugs.jython.org/issue2684

#2680: Ignore Java accessibility rules selectively by package (Java 9
http://bugs.jython.org/issue2680

#2666: Imports in python from java do not work if there is a package 
http://bugs.jython.org/issue2666

#2665: Standalone jar includes test classes
http://bugs.jython.org/issue2665

#2663: Remove dependency on javax.xml.bind.DatatypeConverter
http://bugs.jython.org/issue2663

#2651: Travis Builds failing with *** buffer overflow detected ***
http://bugs.jython.org/issue2651

#2644: Representation of Java maps with String keys differs from Pyth
http://bugs.jython.org/issue2644

#2640: Virtualenv gets confused using paths with ~
http://bugs.jython.org/issue2640

#2633: Unicode garbled in writing to spreadsheet via openpyxl
http://bugs.jython.org/issue2633

#2631: jython 2.7.1 [Errno 107] Socket is not connected
http://bugs.jython.org/issue2631

#2618: socket.sendall no longer sends all
http://bugs.jython.org/issue2618

#2616: Incomplete / broken support for Certificate Revocation Lists
http://bugs.jython.org/issue2616

#2605: Jython 2.7.0 startup performance regression
http://bugs.jython.org/issue2605



Most recent 15 issues waiting for review (15)
=============================================

#2635: AST.lineno ignored by compile
http://bugs.jython.org/issue2635

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
http://bugs.jython.org/issue2363

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embeds other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
http://bugs.jython.org/issue1842

[Jython-dev] JDK 12 & JMC 7.0.0 Early Access builds are available

[Rory O'D. <ror...@or...>]

Hi Alan,

*JDK 11 build 28 is our first JDK 11 Release Candidate [1]
*

  * JDK 11 build 28 is available at : - jdk.java.net/11/

*JDK 12 Early Access build 10 is available at : - jdk.java.net/12/*

  * Release Notes for JDK 12 [2]
  * *JEPs integrated to JDK 12:*
      o 325: Switch Expressions (Preview [3])
  * *JEPs proposed to target JDK 12:*
      o 326: Raw String Literals (Preview [3])

*FOSS bug fixes in recent builds.*

  * Apache Ant -
    JDK-8209965<https://bugs.openjdk.java.net/browse/JDK-8209965>(b09)

*Other important fixes in JDK 12*

  * Disabled all DES TLS Cipher Suites (JDK-8208350
    <https://bugs.openjdk.java.net/browse/JDK-8208350>)
      o DES-based TLS cipher suites are considered obsolete and should
        no longer be used

*JMC 7.0.0 Early Access build 04 is available at :- 
**http://jdk.java.net/jmc/*

  * Overview - summary [4]
  * These early-access, open-source builds are provided under the
    Universal Permissive License,
    version 1.0<https://opensource.org/licenses/UPL>.
  * Feedback via the http://bugreport.java.com/
      o Be sure to include jmc application Build id from "Help" - "About
        JDK Mission Control".


Rgds, Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html
[2] http://jdk.java.net/12/release-notes
[3] http://openjdk.java.net/jeps/12<http://jdk.java.net/12/release-notes>
[4] 
https://download.java.net/java/early_access/jmc7/core/common/docs/api/overview-summary.html 


-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: [Jython-dev] Nobody uses SystemRestart

[Jim B. <jim...@py...>]

Jeff,

My first thought here is as follows: If there's no breaking test, then the
feature was not implemented. I say this of course as the person who
inadvertently nuked it :)

The rest of the problems you raise are also highly fatal to resurrecting
this feature. So I would suggest that you please do not restore.

- Jim


On Tue, Sep 4, 2018 at 1:55 PM, Jeff Allen <ja...@fa...> wrote:

> I know this because it hasn't worked since 2014 and no-one has complained.
> Should we keep it?
>
> First, some archaeology ... Restarting was introduced by Leo Soto in 2008
> (rationale here: https://codereview.appspot.com/2810) and is still marked
> as "experimental". Along the way it has had some work including the
> introduction of shutdownInterpreter() here: https://hg.python.org/jython/
> rev/94b5f009fb77#l3.36 and the accompanying socket._closeActiveSockets()
> that it calls. The motivation is to restart Jython when used in a
> web-server without incurring the application start-up time. Fast-forward to
> 2014 and _closeActiveSockets gets blown away (
> https://hg.python.org/jython/rev/107fe4a4c96b). From here on, raising
> SystemRestart gets you an NPE, but nobody notices that. Here it is in 2.7.0:
>
> PS startup2> jython test_restart.py
> Exception in thread "MainThread" java.lang.NullPointerException
>         at org.python.util.jython.shutdownInterpreter(jython.java:439)
>         at org.python.util.jython.run(jython.java:372)
>         at org.python.util.jython.main(jython.java:142)
>
> Restart gets a mention here: http://bugs.jython.org/issue1475 so it was
> used in 2.5.1 ...
>
> I can keep it (really, restore it) but I'm not sure what to do to
> reproduce the missing _closeActiveSockets() or whether it matters. Just for
> now I've made the absence non-fatal while I work on the rest of
> http://bugs.jython.org/issue2686.
>
> I think the idea of this has a couple of flaws we cannot easily get around.
>
>    - It is not compatible with the idea of multiple interpreters
>    (multiple sys modules). A restart, invoked by one interpreter, stops *all*
>    Jython threads, cleans up *one* interpreter, and restarts the *whole*
>    application.
>    - Static initialisation is not reset unless you know to do it. Some
>    static initialisation (the type system, loaded classes) is intentionally
>    preserved because it drives the start-up time we're trying to save. But
>    others (initially empty lists in sys, Options flags, the registry) can trip
>    up the interpreter on a second pass. Every such case I find has an easy
>    corrective: countless others are waiting to pounce.
>
> Any thoughts on this experiment?
>
> Jeff
>
> --
> Jeff Allen
>
>

[Jython-dev] Nobody uses SystemRestart

[Jeff A. <ja...@fa...>]

I know this because it hasn't worked since 2014 and no-one has 
complained. Should we keep it?

First, some archaeology ... Restarting was introduced by Leo Soto in 
2008 (rationale here: https://codereview.appspot.com/2810) and is still 
marked as "experimental". Along the way it has had some work including 
the introduction of shutdownInterpreter() here: 
https://hg.python.org/jython/rev/94b5f009fb77#l3.36 and the accompanying 
socket._closeActiveSockets() that it calls. The motivation is to restart 
Jython when used in a web-server without incurring the application 
start-up time. Fast-forward to 2014 and _closeActiveSockets gets blown 
away (https://hg.python.org/jython/rev/107fe4a4c96b). From here on, 
raising SystemRestart gets you an NPE, but nobody notices that. Here it 
is in 2.7.0:

PS startup2> jython test_restart.py
Exception in thread "MainThread" java.lang.NullPointerException
         at org.python.util.jython.shutdownInterpreter(jython.java:439)
         at org.python.util.jython.run(jython.java:372)
         at org.python.util.jython.main(jython.java:142)

Restart gets a mention here: http://bugs.jython.org/issue1475 so it was 
used in 2.5.1 ...

I can keep it (really, restore it) but I'm not sure what to do to 
reproduce the missing _closeActiveSockets() or whether it matters. Just 
for now I've made the absence non-fatal while I work on the rest of 
http://bugs.jython.org/issue2686.

I think the idea of this has a couple of flaws we cannot easily get around.

  * It is not compatible with the idea of multiple interpreters
    (multiple sys modules). A restart, invoked by one interpreter, stops
    *all* Jython threads, cleans up *one* interpreter, and restarts the
    *whole* application.
  * Static initialisation is not reset unless you know to do it. Some
    static initialisation (the type system, loaded classes) is
    intentionally preserved because it drives the start-up time we're
    trying to save. But others (initially empty lists in sys, Options
    flags, the registry) can trip up the interpreter on a second pass.
    Every such case I find has an easy corrective: countless others are
    waiting to pounce.

Any thoughts on this experiment?

Jeff

-- 
Jeff Allen

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2018-08-24 - 2018-08-31)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     343 ( -2)
  closed  2377 ( +2)
  total   2720 ( +0)

Open issues with patches: 27   


Most recent 15 issues with no replies (15)
==========================================

#2698: urllib2.URLError: <urlopen error unknown url type: https>
http://bugs.jython.org/issue2698

#2697: name$py.class is ignored when in a JAR with name.py
http://bugs.jython.org/issue2697

#2684: WindowsError:[Error 123] The filename,directory name,or volume
http://bugs.jython.org/issue2684

#2680: Ignore Java accessibility rules selectively by package (Java 9
http://bugs.jython.org/issue2680

#2666: Imports in python from java do not work if there is a package 
http://bugs.jython.org/issue2666

#2665: Standalone jar includes test classes
http://bugs.jython.org/issue2665

#2663: Remove dependency on javax.xml.bind.DatatypeConverter
http://bugs.jython.org/issue2663

#2651: Travis Builds failing with *** buffer overflow detected ***
http://bugs.jython.org/issue2651

#2644: Representation of Java maps with String keys differs from Pyth
http://bugs.jython.org/issue2644

#2640: Virtualenv gets confused using paths with ~
http://bugs.jython.org/issue2640

#2633: Unicode garbled in writing to spreadsheet via openpyxl
http://bugs.jython.org/issue2633

#2631: jython 2.7.1 [Errno 107] Socket is not connected
http://bugs.jython.org/issue2631

#2618: socket.sendall no longer sends all
http://bugs.jython.org/issue2618

#2616: Incomplete / broken support for Certificate Revocation Lists
http://bugs.jython.org/issue2616

#2605: Jython 2.7.0 startup performance regression
http://bugs.jython.org/issue2605



Most recent 15 issues waiting for review (15)
=============================================

#2635: AST.lineno ignored by compile
http://bugs.jython.org/issue2635

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
http://bugs.jython.org/issue2363

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embeds other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

#1842: Add IBM i support to Jython
http://bugs.jython.org/issue1842

Re: [Jython-dev] PyShadowString test, ideas, questions

[Jeff A. <ja...@fa...>]

CharSequence: good idea. Makes me think PyString should be the same. 
(Bigger step to take, however.)

There's a Unicode issue lurking here, as there always is with PyString 
and Java char. With PyString constructors we know that the chars in the 
arguments represent bytes by convention, and I think this should be the 
same. They would only be called from Java, where the caller ought to 
take care of the encoding. Broadening to PyObject makes it less likely 
the caller will do so, IMO.

Jeff Allen

On 30/08/2018 00:28, Stefan Richthofer wrote:
> Re 1) > the ultimate constructor guarantees stringiness
> Maybe we could have one public constructor based on CharSequence. That 
> would directly allow PyString and alike. Internally it would check for 
> instanceof PyObject, cast if possible and construct PyString from the 
> CharSequnce otherwise.
>
> Re 2) > I wondered if there is some document that explains what to 
> consider when adding a new builtin type that shall support 
> subclassing. I found this wiki page: 
> https://wiki.python.org/jython/GeneratedDerivedClasses that confirms 
> all we need to add is the check I suggested. If you know an additional 
> doc, please tell me.
>
> > Please feel free to go ahead with the changes.
> Alright. Perfect.
>
> Am So., 26. Aug. 2018 um 23:59 Uhr schrieb Jeff Allen 
> <ja...@fa... <mailto:ja...@fa...>>:
>
>     1) I don't recall the thinking at the time. There are an awful lot
>     of constructors here and I suspect I wanted to minimise. It looks
>     like the ultimate constructor guarantees stringiness, so that
>     wasn't the explanation. I'd be fine with public.
>
>     2) I think you're right about new. I'd prefer to add the for_type
>     clause than prohibit it, because sub-classing is required by the
>     tests (for it to be equivalent to str in all respects). We
>     discussed it below, I see.
>
>     Please feel free to go ahead with the changes.
>
>     Jeff Allen
>
>     On 26/08/2018 16:17, Stefan Richthofer wrote:
>>     Jeff, I encountered two more concerns with PyShadowString recently:
>>
>>     1) I would like to have the PyObject/PyObject constructor public.
>>     See https://github.com/Stewori/JyNI/pull/29. Is there an actual
>>     concern to keep it private?
>>     2) I noticed that PyShadowStringDerived is never used. In
>>     shadowstr_new some equivalent to this code (e.g. from PyString)
>>     would be needed:
>>     if (new_.for_type == subtype) {
>>          return new PyString(str);
>>     } else {
>>         return new PyStringDerived(subtype, str);
>>     }
>>     If we wouldn't add something like this there is no point to have
>>     PyShadowStringDerived at all. We should either add this or remove
>>     PyShadowStringDerived and prohibit subclassing of PyShadowString.
>>     Or do I overlook something?
>>     I can perform these changes if it's okay for you.
>>
>>     Best
>>
>>     -Stefan
>>
>>     Am Do., 30. Nov. 2017 um 08:13 Uhr schrieb Jeff Allen
>>     <ja...@fa... <mailto:ja...@fa...>>:
>>
>>         The point of having a copy of the list would be to prevent this:
>>
>>         >>> s = PyShadowString("hello", "bonjour")
>>         >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>>         >>> t = s[:3]
>>         >>> t == "bon"
>>         True
>>         >>> s. gettargets().pop()
>>         ('org\\.python\\.util\\.InteractiveConsole',)
>>         >>> t == "bon"
>>         False
>>
>>         It is not a problem if the slice is only transient, as in if
>>         sys.platform[:4] == 'java' , which I agree is the only sort
>>         of slicing attested in the stdlib. If we imagine a slice
>>         getting a life of its own, the behaviour above would be very
>>         confusing, but I'm happy to risk that for now.
>>
>>         I think I have a decent implementation now of these several
>>         changes.
>>
>>         Jeff
>>
>>         Jeff Allen
>>
>>         On 27/11/2017 21:31, Stefan Richthofer wrote:
>>>         > I wonder why we write if sys.platform[:4] == 'java'
>>>         anyway. It's more work than startswith and you have to count
>>>         to 4 yourself.
>>>         It's a matter of fact that external libraries sometimes use
>>>         slicing for platform check. So far the implementation served
>>>         all use cases I found.
>>>         > suggest we expect PyShadowString(a, b)[m,n] to be
>>>         PyShadowString(a[m,n], b[m,n]), and I can see advantages to
>>>         that.
>>>         Good spot. Luckily this is mostly used for "win" which is
>>>         shorter than "java", but of course your version is safer and
>>>         more correct.
>>>         Please let's apply that.
>>>         > Also, if the targets list is mutable, I think each slice
>>>         must have its own.
>>>         I'm not sure if that is necessary. At least for all use
>>>         cases I know it is fine if the slice inherits or shares
>>>         target list from/with the original PyShadowString. Do I
>>>         overlook something?
>>>         *Gesendet:* Montag, 27. November 2017 um 21:33 Uhr
>>>         *Von:* "Jeff Allen" <ja...@fa...>
>>>         <mailto:ja...@fa...>
>>>         *An:* "Stefan Richthofer" <Ste...@gm...>
>>>         <mailto:Ste...@gm...>
>>>         *Cc:* "Jython Developers" <jyt...@li...>
>>>         <mailto:jyt...@li...>
>>>         *Betreff:* Re: PyShadowString test, ideas, questions
>>>
>>>         Thanks Stefan:
>>>
>>>         I'm happy with your answers. I have tried isBaseType = true
>>>         and can run the str tests now (passes of course). I've added
>>>         a *Derived.java file.
>>>
>>>         7. Slicing is interesting. Nice touch.
>>>
>>>         >>> s = PyShadowString("hello", "bonjour")
>>>         >>> s[:3]
>>>         'hel ( ==bon for targets )'
>>>
>>>         I appreciate the main use case is sys.platform[:n] , but
>>>         these were surprising (because the slice is only interpreted
>>>         relative to the main string):
>>>
>>>         >>> s[:7]
>>>         'hello ( ==bonjo for targets )'
>>>
>>>         >>> s[-3:]
>>>         'llo ( ==njo for targets )'
>>>
>>>         I suggest we expect PyShadowString(a, b)[m,n] to be
>>>         PyShadowString(a[m,n], b[m,n]), and I can see advantages to
>>>         that. Also, if the targets list is mutable, I think each
>>>         slice must have its own.
>>>
>>>         I wonder why we write if sys.platform[:4] == 'java' anyway.
>>>         It's more work than startswith and you have to count to 4
>>>         yourself.
>>>
>>>         Jeff
>>>
>>>         Jeff Allen
>>>         On 26/11/2017 10:16, Stefan Richthofer wrote:
>>>
>>>             Trying to give answers as far as I have them...
>>>
>>>             1. Should I be able to do this?
>>>
>>>             >>> s.gettargets().pop()
>>>             ('org\\.python\\.util\\.InteractiveConsole',)
>>>             >>> s == 'bonjour'
>>>             False
>>>
>>>             I think that's okay. target list is not private to alow
>>>             monkeypatching etc in usual Python fashion.
>>>
>>>             2. This seems like a useful "unconditional", but I
>>>             wonder if it is harmful:
>>>
>>>             >>> s.addtarget(None)
>>>             >>> s == 'bonjour'
>>>             True
>>>
>>>             No opinion. This behavior looks okay to me. Whoever uses
>>>             PyShadowString must be aware of entering evil zone anyway.
>>>
>>>             3. Confusing subject, but I'm not sure the exposure of
>>>             __eq__ is "canonical". I think the convention is __eq__
>>>             just wraps shadowstr___eq__, as done for startswith and
>>>             __repr__, but here there is "added value" in __eq__
>>>             (also in PyString.__eq__). shadowstr___eq__ will be
>>>             exposed as __eq__, and shouldn't PyShadowString.__eq__
>>>             do the same thing? What we need is complicated by the
>>>             wrapper PyObject._eq.
>>>
>>>             I think you're right. The check for isTarget should be
>>>             moved to shadowstr___eq__ I suppose. Sorry I overlooked
>>>             this when I wrote it.
>>>
>>>             4. Single-stepping through __eq__ I notice that a call
>>>             like s == 'bonjour' (i.e. a call to __eq__) is quite
>>>             costly, even when there are no targets that match. The
>>>             problem is in isTarget() and so I think I will try
>>>             changing the logic to:
>>>
>>>             return other==string || (other==shadow && isTarget())
>>>
>>>             but also, we can make isTarget() cheaper.
>>>
>>>             Thats' s a good improvement. Also, isTarget should
>>>             fail-fast if target list is empty (I thought I had done
>>>             it that way).On the other hand, performance is hardly a
>>>             priority here, because platform checks are usually
>>>             rather seldom, mostly on startup only.
>>>
>>>             5. I tried the tests of str on PyShadowString, to prove
>>>             it is also a str, but they fail because it cannot be
>>>             sub-classed. Is there a reason to prevent sub-classing?
>>>
>>>             This is because of isBaseType = false? We can remove
>>>             that. I just felt that shadow string contains enough
>>>             magic and should not be further extended, but there is
>>>             no concrete reason. We can allow subclassing.
>>>
>>>             6. And relatedly, when I was working on PyType I noticed
>>>             that it is possible to expose a Java sub-class as the
>>>             same Python type as its parent. This would mean that
>>>             type(PyShadowString("a", "b")) would be str even though
>>>             the behaviour is different. This sounds worth trying.
>>>
>>>             Hmm, I don't like that. ShadowString is not a string and
>>>             its type should be labled accordingly.
>>>
>>>             *Gesendet:* Sonntag, 26. November 2017 um 09:06 Uhr
>>>             *Von:* "Jeff Allen" <ja...@fa...>
>>>             <mailto:ja...@fa...>
>>>             *An:* "Jython Developers"
>>>             <jyt...@li...>
>>>             <mailto:jyt...@li...>, "Stefan
>>>             Richthofer" <Ste...@gm...>
>>>             <mailto:Ste...@gm...>
>>>             *Betreff:* PyShadowString test, ideas, questions
>>>
>>>             I've added a test for PyShadowString, our string that
>>>             can have two values at once. Trying to design a test
>>>             raises some questions.
>>>
>>>             >>> s = PyShadowString("hello", "bonjour")
>>>             >>> s == 'bonjour'
>>>             False
>>>             >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>>>             >>> s == 'bonjour'
>>>             True
>>>
>>>             So far so good.
>>>
>>>             1. Should I be able to do this?
>>>
>>>             >>> s.gettargets().pop()
>>>             ('org\\.python\\.util\\.InteractiveConsole',)
>>>             >>> s == 'bonjour'
>>>             False
>>>
>>>             2. This seems like a useful "unconditional", but I
>>>             wonder if it is harmful:
>>>
>>>             >>> s.addtarget(None)
>>>             >>> s == 'bonjour'
>>>             True
>>>
>>>             3. Confusing subject, but I'm not sure the exposure of
>>>             __eq__ is "canonical". I think the convention is __eq__
>>>             just wraps shadowstr___eq__, as done for startswith and
>>>             __repr__, but here there is "added value" in __eq__
>>>             (also in PyString.__eq__). shadowstr___eq__ will be
>>>             exposed as __eq__, and shouldn't PyShadowString.__eq__
>>>             do the same thing? What we need is complicated by the
>>>             wrapper PyObject._eq.
>>>
>>>             4. Single-stepping through __eq__ I notice that a call
>>>             like s == 'bonjour' (i.e. a call to __eq__) is quite
>>>             costly, even when there are no targets that match. The
>>>             problem is in isTarget() and so I think I will try
>>>             changing the logic to:
>>>
>>>             return other==string || (other==shadow && isTarget())
>>>
>>>             but also, we can make isTarget() cheaper.
>>>
>>>             5. I tried the tests of str on PyShadowString, to prove
>>>             it is also a str, but they fail because it cannot be
>>>             sub-classed. Is there a reason to prevent sub-classing?
>>>
>>>             6. And relatedly, when I was working on PyType I noticed
>>>             that it is possible to expose a Java sub-class as the
>>>             same Python type as its parent. This would mean that
>>>             type(PyShadowString("a", "b")) would be str even though
>>>             the behaviour is different. This sounds worth trying.
>>>
>>>             Jeff
>>>
>>>             -- 
>>>             Jeff Allen
>>>
>>
>

Re: [Jython-dev] PyShadowString test, ideas, questions

[Stefan R. <ste...@gm...>]

Re 1) > the ultimate constructor guarantees stringiness
Maybe we could have one public constructor based on CharSequence. That
would directly allow PyString and alike. Internally it would check for
instanceof PyObject, cast if possible and construct PyString from the
CharSequnce otherwise.

Re 2) > I wondered if there is some document that explains what to consider
when adding a new builtin type that shall support subclassing. I found this
wiki page: https://wiki.python.org/jython/GeneratedDerivedClasses that
confirms all we need to add is the check I suggested. If you know an
additional doc, please tell me.

> Please feel free to go ahead with the changes.
Alright. Perfect.

Am So., 26. Aug. 2018 um 23:59 Uhr schrieb Jeff Allen <ja...@fa...>:

> 1) I don't recall the thinking at the time. There are an awful lot of
> constructors here and I suspect I wanted to minimise. It looks like the
> ultimate constructor guarantees stringiness, so that wasn't the
> explanation. I'd be fine with public.
>
> 2) I think you're right about new. I'd prefer to add the for_type clause
> than prohibit it, because sub-classing is required by the tests (for it to
> be equivalent to str in all respects). We discussed it below, I see.
>
> Please feel free to go ahead with the changes.
>
> Jeff Allen
>
> On 26/08/2018 16:17, Stefan Richthofer wrote:
>
> Jeff, I encountered two more concerns with PyShadowString recently:
>
> 1) I would like to have the PyObject/PyObject constructor public. See
> https://github.com/Stewori/JyNI/pull/29. Is there an actual concern to
> keep it private?
> 2) I noticed that PyShadowStringDerived is never used. In shadowstr_new
> some equivalent to this code (e.g. from PyString) would be needed:
> if (new_.for_type == subtype) {
>      return new PyString(str);
> } else {
>     return new PyStringDerived(subtype, str);
> }
> If we wouldn't add something like this there is no point to have
> PyShadowStringDerived at all. We should either add this or remove
> PyShadowStringDerived and prohibit subclassing of PyShadowString. Or do I
> overlook something?
> I can perform these changes if it's okay for you.
>
> Best
>
> -Stefan
>
> Am Do., 30. Nov. 2017 um 08:13 Uhr schrieb Jeff Allen <ja...@fa...
> >:
>
>> The point of having a copy of the list would be to prevent this:
>>
>> >>> s = PyShadowString("hello", "bonjour")
>> >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>> >>> t = s[:3]
>> >>> t == "bon"
>> True
>> >>> s. gettargets().pop()
>> ('org\\.python\\.util\\.InteractiveConsole',)
>> >>> t == "bon"
>> False
>> It is not a problem if the slice is only transient, as in if
>> sys.platform[:4] == 'java' , which I agree is the only sort of slicing
>> attested in the stdlib. If we imagine a slice getting a life of its own,
>> the behaviour above would be very confusing, but I'm happy to risk that for
>> now.
>>
>> I think I have a decent implementation now of these several changes.
>>
>> Jeff
>>
>> Jeff Allen
>>
>> On 27/11/2017 21:31, Stefan Richthofer wrote:
>>
>> > I wonder why we write if sys.platform[:4] == 'java' anyway. It's more
>> work than startswith and you have to count to 4 yourself.
>>
>> It's a matter of fact that external libraries sometimes use slicing for
>> platform check. So far the implementation served all use cases I found.
>>
>>
>> > suggest we expect PyShadowString(a, b)[m,n] to be
>> PyShadowString(a[m,n], b[m,n]), and I can see advantages to that.
>> Good spot. Luckily this is mostly used for "win" which is shorter than
>> "java", but of course your version is safer and more correct.
>> Please let's apply that.
>>
>>
>>
>> > Also, if the targets list is mutable, I think each slice must have its
>> own.
>> I'm not sure if that is necessary. At least for all use cases I know it
>> is fine if the slice inherits or shares target list from/with the original
>> PyShadowString. Do I overlook something?
>>
>>
>>
>> *Gesendet:* Montag, 27. November 2017 um 21:33 Uhr
>> *Von:* "Jeff Allen" <ja...@fa...> <ja...@fa...>
>> *An:* "Stefan Richthofer" <Ste...@gm...>
>> <Ste...@gm...>
>> *Cc:* "Jython Developers" <jyt...@li...>
>> <jyt...@li...>
>> *Betreff:* Re: PyShadowString test, ideas, questions
>>
>> Thanks Stefan:
>>
>> I'm happy with your answers. I have tried isBaseType = true and can run
>> the str tests now (passes of course). I've added a *Derived.java file.
>>
>> 7. Slicing is interesting. Nice touch.
>>
>> >>> s = PyShadowString("hello", "bonjour")
>> >>> s[:3]
>> 'hel ( ==bon for targets )'
>>
>> I appreciate the main use case is sys.platform[:n] , but these were
>> surprising (because the slice is only interpreted relative to the main
>> string):
>>
>> >>> s[:7]
>> 'hello ( ==bonjo for targets )'
>>
>> >>> s[-3:]
>> 'llo ( ==njo for targets )'
>>
>> I suggest we expect PyShadowString(a, b)[m,n] to be
>> PyShadowString(a[m,n], b[m,n]), and I can see advantages to that. Also, if
>> the targets list is mutable, I think each slice must have its own.
>>
>> I wonder why we write if sys.platform[:4] == 'java' anyway. It's more
>> work than startswith and you have to count to 4 yourself.
>>
>> Jeff
>>
>> Jeff Allen
>>
>> On 26/11/2017 10:16, Stefan Richthofer wrote:
>>
>> Trying to give answers as far as I have them...
>>
>>
>> 1. Should I be able to do this?
>>
>> >>> s.gettargets().pop()
>> ('org\\.python\\.util\\.InteractiveConsole',)
>> >>> s == 'bonjour'
>> False
>>
>> I think that's okay. target list is not private to alow monkeypatching
>> etc in usual Python fashion.
>>
>>
>>
>> 2. This seems like a useful "unconditional", but I wonder if it is
>> harmful:
>>
>> >>> s.addtarget(None)
>> >>> s == 'bonjour'
>> True
>>
>> No opinion. This behavior looks okay to me. Whoever uses PyShadowString
>> must be aware of entering evil zone anyway.
>>
>>
>>
>> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
>> "canonical". I think the convention is __eq__ just wraps shadowstr___eq__,
>> as done for startswith and __repr__, but here there is "added value" in
>> __eq__ (also in PyString.__eq__). shadowstr___eq__ will be exposed as
>> __eq__, and shouldn't PyShadowString.__eq__ do the same thing? What we need
>> is complicated by the wrapper PyObject._eq.
>>
>> I think you're right. The check for isTarget should be moved to
>> shadowstr___eq__ I suppose. Sorry I overlooked this when I wrote it.
>>
>>
>>
>> 4. Single-stepping through __eq__ I notice that a call like s ==
>> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there are
>> no targets that match. The problem is in isTarget() and so I think I will
>> try changing the logic to:
>>
>> return other==string || (other==shadow && isTarget())
>>
>> but also, we can make isTarget() cheaper.
>>
>>
>>
>> Thats' s a good improvement. Also, isTarget should fail-fast if target
>> list is empty (I thought I had done it that way).On the other hand,
>> performance is hardly a priority here, because platform checks are usually
>> rather seldom, mostly on startup only.
>>
>>
>>
>> 5. I tried the tests of str on PyShadowString, to prove it is also a str,
>> but they fail because it cannot be sub-classed. Is there a reason to
>> prevent sub-classing?
>>
>> This is because of isBaseType = false? We can remove that. I just felt
>> that shadow string contains enough magic and should not be further
>> extended, but there is no concrete reason. We can allow subclassing.
>>
>>
>>
>> 6. And relatedly, when I was working on PyType I noticed that it is
>> possible to expose a Java sub-class as the same Python type as its parent.
>> This would mean that type(PyShadowString("a", "b")) would be str even
>> though the behaviour is different. This sounds worth trying.
>>
>> Hmm, I don't like that. ShadowString is not a string and its type should
>> be labled accordingly.
>>
>> *Gesendet:* Sonntag, 26. November 2017 um 09:06 Uhr
>> *Von:* "Jeff Allen" <ja...@fa...> <ja...@fa...>
>> *An:* "Jython Developers" <jyt...@li...>
>> <jyt...@li...>, "Stefan Richthofer"
>> <Ste...@gm...> <Ste...@gm...>
>> *Betreff:* PyShadowString test, ideas, questions
>>
>> I've added a test for PyShadowString, our string that can have two values
>> at once. Trying to design a test raises some questions.
>>
>> >>> s = PyShadowString("hello", "bonjour")
>> >>> s == 'bonjour'
>> False
>> >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>> >>> s == 'bonjour'
>> True
>>
>> So far so good.
>>
>> 1. Should I be able to do this?
>>
>> >>> s.gettargets().pop()
>> ('org\\.python\\.util\\.InteractiveConsole',)
>> >>> s == 'bonjour'
>> False
>>
>> 2. This seems like a useful "unconditional", but I wonder if it is
>> harmful:
>>
>> >>> s.addtarget(None)
>> >>> s == 'bonjour'
>> True
>>
>> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
>> "canonical". I think the convention is __eq__ just wraps shadowstr___eq__,
>> as done for startswith and __repr__, but here there is "added value" in
>> __eq__ (also in PyString.__eq__). shadowstr___eq__ will be exposed as
>> __eq__, and shouldn't PyShadowString.__eq__ do the same thing? What we need
>> is complicated by the wrapper PyObject._eq.
>>
>> 4. Single-stepping through __eq__ I notice that a call like s ==
>> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there are
>> no targets that match. The problem is in isTarget() and so I think I will
>> try changing the logic to:
>>
>> return other==string || (other==shadow && isTarget())
>>
>> but also, we can make isTarget() cheaper.
>>
>> 5. I tried the tests of str on PyShadowString, to prove it is also a str,
>> but they fail because it cannot be sub-classed. Is there a reason to
>> prevent sub-classing?
>>
>> 6. And relatedly, when I was working on PyType I noticed that it is
>> possible to expose a Java sub-class as the same Python type as its parent.
>> This would mean that type(PyShadowString("a", "b")) would be str even
>> though the behaviour is different. This sounds worth trying.
>>
>> Jeff
>>
>> --
>> Jeff Allen
>>
>>
>>
>

Re: [Jython-dev] pip-related option -J-Dcpython_cmd

[Stefan R. <ste...@gm...>]

Hey Jeff,

indeed I intended at that time to get eventually back to this and find a
better solution
("Todo: Resolve this discrepancy!"). Then there were other priorities...
A prototype use case is to let things like this genereate some required
pyc-files smoothly:

pip install --global-option="-J-Dcpython_cmd=python" sympy

If that works with the Windows launcher now, it should be fine to
remove the special case.
I think I originally thought about solving this by making the options
parser smarter, e.g.
atomatically sort out -J options regardless where they occur. That
would move some logic
from platform dependent launchers into the platform independent Java
code -> easier to maintain.

Anyway. If it works fine now with the launchers I think there is no
priority to move things around now.

-Stefan


Am Mi., 29. Aug. 2018 um 00:58 Uhr schrieb Jeff Allen <ja...@fa...>:

> HI Stefan:
>
> I'm rationalising the Jython main program and the options parser, and I'm
> looking at the code added by this change:
>
> https://hg.python.org/jython/rev/03f4808038f8#l3.8
>
> which is clearly a work-around you seemed to intend be resolved another
> way eventually. It deals as a specific case with the option
> -J-Dcpython_cmd=python, which ends up as a Jython argument when using pip
> with --global-options. (That's if I've understood correctly.) Am I right
> in thinking this is a specific case of a general problem when Java options
> mix with Python ones (observed here in 2.7.1):
>
> PS startup2> jython -E -J-Dtest=TEST
> Unknown option: J-Dtest=TEST
> usage: ...
>
> Since that time, and with an unconnected motive, I've changed the Windows
> launcher so that it shuffles recognisable Python options and Java options
> (-J<stuff>) to their proper places. (
> https://hg.python.org/jython/rev/b556dcdf8258) In the tip now, I get:
>
> PS jython-trunk> dist\bin\jython -E -J-Dtest=TEST -c "import sys; print sys.registry.getProperty('test')"
> TEST
>
> Do you think this means I can I safely omit the special case from the
> options parser?
>
> Jeff
>
> --
> Jeff Allen
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

[Jython-dev] pip-related option -J-Dcpython_cmd

[Jeff A. <ja...@fa...>]

HI Stefan:

I'm rationalising the Jython main program and the options parser, and 
I'm looking at the code added by this change:

https://hg.python.org/jython/rev/03f4808038f8#l3.8

which is clearly a work-around you seemed to intend be resolved another 
way eventually. It deals as a specific case with the 
option-J-Dcpython_cmd=python, which ends up as a Jython argument when 
using pip with --global-options. (That's if I've understood correctly.) 
Am I right in thinking this is a specific case of a general problem when 
Java options mix with Python ones (observed here in 2.7.1):

PS startup2> jython -E -J-Dtest=TEST
Unknown option: J-Dtest=TEST
usage: ...

Since that time, and with an unconnected motive, I've changed the 
Windows launcher so that it shuffles recognisable Python options and 
Java options (-J<stuff>) to their proper places. 
(https://hg.python.org/jython/rev/b556dcdf8258) In the tip now, I get:

PS jython-trunk> dist\bin\jython -E -J-Dtest=TEST -c "import sys; print sys.registry.getProperty('test')"
TEST

Do you think this means I can I safely omit the special case from the 
options parser?

Jeff

-- 
Jeff Allen

Re: [Jython-dev] PyShadowString test, ideas, questions

[Jeff A. <ja...@fa...>]

1) I don't recall the thinking at the time. There are an awful lot of 
constructors here and I suspect I wanted to minimise. It looks like the 
ultimate constructor guarantees stringiness, so that wasn't the 
explanation. I'd be fine with public.

2) I think you're right about new. I'd prefer to add the for_type clause 
than prohibit it, because sub-classing is required by the tests (for it 
to be equivalent to str in all respects). We discussed it below, I see.

Please feel free to go ahead with the changes.

Jeff Allen

On 26/08/2018 16:17, Stefan Richthofer wrote:
> Jeff, I encountered two more concerns with PyShadowString recently:
>
> 1) I would like to have the PyObject/PyObject constructor public. See 
> https://github.com/Stewori/JyNI/pull/29. Is there an actual concern to 
> keep it private?
> 2) I noticed that PyShadowStringDerived is never used. In 
> shadowstr_new some equivalent to this code (e.g. from PyString) would 
> be needed:
> if (new_.for_type == subtype) {
>      return new PyString(str);
> } else {
>     return new PyStringDerived(subtype, str);
> }
> If we wouldn't add something like this there is no point to have 
> PyShadowStringDerived at all. We should either add this or remove 
> PyShadowStringDerived and prohibit subclassing of PyShadowString. Or 
> do I overlook something?
> I can perform these changes if it's okay for you.
>
> Best
>
> -Stefan
>
> Am Do., 30. Nov. 2017 um 08:13 Uhr schrieb Jeff Allen 
> <ja...@fa... <mailto:ja...@fa...>>:
>
>     The point of having a copy of the list would be to prevent this:
>
>     >>> s = PyShadowString("hello", "bonjour")
>     >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>     >>> t = s[:3]
>     >>> t == "bon"
>     True
>     >>> s. gettargets().pop()
>     ('org\\.python\\.util\\.InteractiveConsole',)
>     >>> t == "bon"
>     False
>
>     It is not a problem if the slice is only transient, as in if
>     sys.platform[:4] == 'java' , which I agree is the only sort of
>     slicing attested in the stdlib. If we imagine a slice getting a
>     life of its own, the behaviour above would be very confusing, but
>     I'm happy to risk that for now.
>
>     I think I have a decent implementation now of these several changes.
>
>     Jeff
>
>     Jeff Allen
>
>     On 27/11/2017 21:31, Stefan Richthofer wrote:
>>     > I wonder why we write if sys.platform[:4] == 'java' anyway.
>>     It's more work than startswith and you have to count to 4 yourself.
>>     It's a matter of fact that external libraries sometimes use
>>     slicing for platform check. So far the implementation served all
>>     use cases I found.
>>     > suggest we expect PyShadowString(a, b)[m,n] to be
>>     PyShadowString(a[m,n], b[m,n]), and I can see advantages to that.
>>     Good spot. Luckily this is mostly used for "win" which is shorter
>>     than "java", but of course your version is safer and more correct.
>>     Please let's apply that.
>>     > Also, if the targets list is mutable, I think each slice must
>>     have its own.
>>     I'm not sure if that is necessary. At least for all use cases I
>>     know it is fine if the slice inherits or shares target list
>>     from/with the original PyShadowString. Do I overlook something?
>>     *Gesendet:* Montag, 27. November 2017 um 21:33 Uhr
>>     *Von:* "Jeff Allen" <ja...@fa...> <mailto:ja...@fa...>
>>     *An:* "Stefan Richthofer" <Ste...@gm...>
>>     <mailto:Ste...@gm...>
>>     *Cc:* "Jython Developers" <jyt...@li...>
>>     <mailto:jyt...@li...>
>>     *Betreff:* Re: PyShadowString test, ideas, questions
>>
>>     Thanks Stefan:
>>
>>     I'm happy with your answers. I have tried isBaseType = true and
>>     can run the str tests now (passes of course). I've added a
>>     *Derived.java file.
>>
>>     7. Slicing is interesting. Nice touch.
>>
>>     >>> s = PyShadowString("hello", "bonjour")
>>     >>> s[:3]
>>     'hel ( ==bon for targets )'
>>
>>     I appreciate the main use case is sys.platform[:n] , but these
>>     were surprising (because the slice is only interpreted relative
>>     to the main string):
>>
>>     >>> s[:7]
>>     'hello ( ==bonjo for targets )'
>>
>>     >>> s[-3:]
>>     'llo ( ==njo for targets )'
>>
>>     I suggest we expect PyShadowString(a, b)[m,n] to be
>>     PyShadowString(a[m,n], b[m,n]), and I can see advantages to that.
>>     Also, if the targets list is mutable, I think each slice must
>>     have its own.
>>
>>     I wonder why we write if sys.platform[:4] == 'java' anyway. It's
>>     more work than startswith and you have to count to 4 yourself.
>>
>>     Jeff
>>
>>     Jeff Allen
>>     On 26/11/2017 10:16, Stefan Richthofer wrote:
>>
>>         Trying to give answers as far as I have them...
>>
>>         1. Should I be able to do this?
>>
>>         >>> s.gettargets().pop()
>>         ('org\\.python\\.util\\.InteractiveConsole',)
>>         >>> s == 'bonjour'
>>         False
>>
>>         I think that's okay. target list is not private to alow
>>         monkeypatching etc in usual Python fashion.
>>
>>         2. This seems like a useful "unconditional", but I wonder if
>>         it is harmful:
>>
>>         >>> s.addtarget(None)
>>         >>> s == 'bonjour'
>>         True
>>
>>         No opinion. This behavior looks okay to me. Whoever uses
>>         PyShadowString must be aware of entering evil zone anyway.
>>
>>         3. Confusing subject, but I'm not sure the exposure of __eq__
>>         is "canonical". I think the convention is __eq__ just wraps
>>         shadowstr___eq__, as done for startswith and __repr__, but
>>         here there is "added value" in __eq__ (also in
>>         PyString.__eq__). shadowstr___eq__ will be exposed as __eq__,
>>         and shouldn't PyShadowString.__eq__ do the same thing? What
>>         we need is complicated by the wrapper PyObject._eq.
>>
>>         I think you're right. The check for isTarget should be moved
>>         to shadowstr___eq__ I suppose. Sorry I overlooked this when I
>>         wrote it.
>>
>>         4. Single-stepping through __eq__ I notice that a call like s
>>         == 'bonjour' (i.e. a call to __eq__) is quite costly, even
>>         when there are no targets that match. The problem is in
>>         isTarget() and so I think I will try changing the logic to:
>>
>>         return other==string || (other==shadow && isTarget())
>>
>>         but also, we can make isTarget() cheaper.
>>
>>         Thats' s a good improvement. Also, isTarget should fail-fast
>>         if target list is empty (I thought I had done it that way).On
>>         the other hand, performance is hardly a priority here,
>>         because platform checks are usually rather seldom, mostly on
>>         startup only.
>>
>>         5. I tried the tests of str on PyShadowString, to prove it is
>>         also a str, but they fail because it cannot be sub-classed.
>>         Is there a reason to prevent sub-classing?
>>
>>         This is because of isBaseType = false? We can remove that. I
>>         just felt that shadow string contains enough magic and should
>>         not be further extended, but there is no concrete reason. We
>>         can allow subclassing.
>>
>>         6. And relatedly, when I was working on PyType I noticed that
>>         it is possible to expose a Java sub-class as the same Python
>>         type as its parent. This would mean that
>>         type(PyShadowString("a", "b")) would be str even though the
>>         behaviour is different. This sounds worth trying.
>>
>>         Hmm, I don't like that. ShadowString is not a string and its
>>         type should be labled accordingly.
>>
>>         *Gesendet:* Sonntag, 26. November 2017 um 09:06 Uhr
>>         *Von:* "Jeff Allen" <ja...@fa...>
>>         <mailto:ja...@fa...>
>>         *An:* "Jython Developers" <jyt...@li...>
>>         <mailto:jyt...@li...>, "Stefan
>>         Richthofer" <Ste...@gm...>
>>         <mailto:Ste...@gm...>
>>         *Betreff:* PyShadowString test, ideas, questions
>>
>>         I've added a test for PyShadowString, our string that can
>>         have two values at once. Trying to design a test raises some
>>         questions.
>>
>>         >>> s = PyShadowString("hello", "bonjour")
>>         >>> s == 'bonjour'
>>         False
>>         >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>>         >>> s == 'bonjour'
>>         True
>>
>>         So far so good.
>>
>>         1. Should I be able to do this?
>>
>>         >>> s.gettargets().pop()
>>         ('org\\.python\\.util\\.InteractiveConsole',)
>>         >>> s == 'bonjour'
>>         False
>>
>>         2. This seems like a useful "unconditional", but I wonder if
>>         it is harmful:
>>
>>         >>> s.addtarget(None)
>>         >>> s == 'bonjour'
>>         True
>>
>>         3. Confusing subject, but I'm not sure the exposure of __eq__
>>         is "canonical". I think the convention is __eq__ just wraps
>>         shadowstr___eq__, as done for startswith and __repr__, but
>>         here there is "added value" in __eq__ (also in
>>         PyString.__eq__). shadowstr___eq__ will be exposed as __eq__,
>>         and shouldn't PyShadowString.__eq__ do the same thing? What
>>         we need is complicated by the wrapper PyObject._eq.
>>
>>         4. Single-stepping through __eq__ I notice that a call like s
>>         == 'bonjour' (i.e. a call to __eq__) is quite costly, even
>>         when there are no targets that match. The problem is in
>>         isTarget() and so I think I will try changing the logic to:
>>
>>         return other==string || (other==shadow && isTarget())
>>
>>         but also, we can make isTarget() cheaper.
>>
>>         5. I tried the tests of str on PyShadowString, to prove it is
>>         also a str, but they fail because it cannot be sub-classed.
>>         Is there a reason to prevent sub-classing?
>>
>>         6. And relatedly, when I was working on PyType I noticed that
>>         it is possible to expose a Java sub-class as the same Python
>>         type as its parent. This would mean that
>>         type(PyShadowString("a", "b")) would be str even though the
>>         behaviour is different. This sounds worth trying.
>>
>>         Jeff
>>
>>         -- 
>>         Jeff Allen
>>
>

Re: [Jython-dev] PyShadowString test, ideas, questions

[Stefan R. <ste...@gm...>]

Jeff, I encountered two more concerns with PyShadowString recently:

1) I would like to have the PyObject/PyObject constructor public. See
https://github.com/Stewori/JyNI/pull/29. Is there an actual concern to keep
it private?
2) I noticed that PyShadowStringDerived is never used. In shadowstr_new
some equivalent to this code (e.g. from PyString) would be needed:
if (new_.for_type == subtype) {
     return new PyString(str);
} else {
    return new PyStringDerived(subtype, str);
}
If we wouldn't add something like this there is no point to have
PyShadowStringDerived at all. We should either add this or remove
PyShadowStringDerived and prohibit subclassing of PyShadowString. Or do I
overlook something?
I can perform these changes if it's okay for you.

Best

-Stefan

Am Do., 30. Nov. 2017 um 08:13 Uhr schrieb Jeff Allen <ja...@fa...>:

> The point of having a copy of the list would be to prevent this:
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
> >>> t = s[:3]
> >>> t == "bon"
> True
> >>> s. gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> t == "bon"
> False
> It is not a problem if the slice is only transient, as in if
> sys.platform[:4] == 'java' , which I agree is the only sort of slicing
> attested in the stdlib. If we imagine a slice getting a life of its own,
> the behaviour above would be very confusing, but I'm happy to risk that for
> now.
>
> I think I have a decent implementation now of these several changes.
>
> Jeff
>
> Jeff Allen
>
> On 27/11/2017 21:31, Stefan Richthofer wrote:
>
> > I wonder why we write if sys.platform[:4] == 'java' anyway. It's more
> work than startswith and you have to count to 4 yourself.
>
> It's a matter of fact that external libraries sometimes use slicing for
> platform check. So far the implementation served all use cases I found.
>
>
> > suggest we expect PyShadowString(a, b)[m,n] to be PyShadowString(a[m,n],
> b[m,n]), and I can see advantages to that.
> Good spot. Luckily this is mostly used for "win" which is shorter than
> "java", but of course your version is safer and more correct.
> Please let's apply that.
>
>
>
> > Also, if the targets list is mutable, I think each slice must have its
> own.
> I'm not sure if that is necessary. At least for all use cases I know it is
> fine if the slice inherits or shares target list from/with the original
> PyShadowString. Do I overlook something?
>
>
>
> *Gesendet:* Montag, 27. November 2017 um 21:33 Uhr
> *Von:* "Jeff Allen" <ja...@fa...> <ja...@fa...>
> *An:* "Stefan Richthofer" <Ste...@gm...>
> <Ste...@gm...>
> *Cc:* "Jython Developers" <jyt...@li...>
> <jyt...@li...>
> *Betreff:* Re: PyShadowString test, ideas, questions
>
> Thanks Stefan:
>
> I'm happy with your answers. I have tried isBaseType = true and can run
> the str tests now (passes of course). I've added a *Derived.java file.
>
> 7. Slicing is interesting. Nice touch.
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s[:3]
> 'hel ( ==bon for targets )'
>
> I appreciate the main use case is sys.platform[:n] , but these were
> surprising (because the slice is only interpreted relative to the main
> string):
>
> >>> s[:7]
> 'hello ( ==bonjo for targets )'
>
> >>> s[-3:]
> 'llo ( ==njo for targets )'
>
> I suggest we expect PyShadowString(a, b)[m,n] to be PyShadowString(a[m,n],
> b[m,n]), and I can see advantages to that. Also, if the targets list is
> mutable, I think each slice must have its own.
>
> I wonder why we write if sys.platform[:4] == 'java' anyway. It's more
> work than startswith and you have to count to 4 yourself.
>
> Jeff
>
> Jeff Allen
>
> On 26/11/2017 10:16, Stefan Richthofer wrote:
>
> Trying to give answers as far as I have them...
>
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> I think that's okay. target list is not private to alow monkeypatching etc
> in usual Python fashion.
>
>
>
> 2. This seems like a useful "unconditional", but I wonder if it is harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> No opinion. This behavior looks okay to me. Whoever uses PyShadowString
> must be aware of entering evil zone anyway.
>
>
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps shadowstr___eq__,
> as done for startswith and __repr__, but here there is "added value" in
> __eq__ (also in PyString.__eq__). shadowstr___eq__ will be exposed as
> __eq__, and shouldn't PyShadowString.__eq__ do the same thing? What we need
> is complicated by the wrapper PyObject._eq.
>
> I think you're right. The check for isTarget should be moved to
> shadowstr___eq__ I suppose. Sorry I overlooked this when I wrote it.
>
>
>
> 4. Single-stepping through __eq__ I notice that a call like s == 'bonjour'
> (i.e. a call to __eq__) is quite costly, even when there are no targets
> that match. The problem is in isTarget() and so I think I will try changing
> the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
>
>
> Thats' s a good improvement. Also, isTarget should fail-fast if target
> list is empty (I thought I had done it that way).On the other hand,
> performance is hardly a priority here, because platform checks are usually
> rather seldom, mostly on startup only.
>
>
>
> 5. I tried the tests of str on PyShadowString, to prove it is also a str,
> but they fail because it cannot be sub-classed. Is there a reason to
> prevent sub-classing?
>
> This is because of isBaseType = false? We can remove that. I just felt
> that shadow string contains enough magic and should not be further
> extended, but there is no concrete reason. We can allow subclassing.
>
>
>
> 6. And relatedly, when I was working on PyType I noticed that it is
> possible to expose a Java sub-class as the same Python type as its parent.
> This would mean that type(PyShadowString("a", "b")) would be str even
> though the behaviour is different. This sounds worth trying.
>
> Hmm, I don't like that. ShadowString is not a string and its type should
> be labled accordingly.
>
> *Gesendet:* Sonntag, 26. November 2017 um 09:06 Uhr
> *Von:* "Jeff Allen" <ja...@fa...> <ja...@fa...>
> *An:* "Jython Developers" <jyt...@li...>
> <jyt...@li...>, "Stefan Richthofer"
> <Ste...@gm...> <Ste...@gm...>
> *Betreff:* PyShadowString test, ideas, questions
>
> I've added a test for PyShadowString, our string that can have two values
> at once. Trying to design a test raises some questions.
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s == 'bonjour'
> False
> >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
> >>> s == 'bonjour'
> True
>
> So far so good.
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> 2. This seems like a useful "unconditional", but I wonder if it is harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps shadowstr___eq__,
> as done for startswith and __repr__, but here there is "added value" in
> __eq__ (also in PyString.__eq__). shadowstr___eq__ will be exposed as
> __eq__, and shouldn't PyShadowString.__eq__ do the same thing? What we need
> is complicated by the wrapper PyObject._eq.
>
> 4. Single-stepping through __eq__ I notice that a call like s == 'bonjour'
> (i.e. a call to __eq__) is quite costly, even when there are no targets
> that match. The problem is in isTarget() and so I think I will try changing
> the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
> 5. I tried the tests of str on PyShadowString, to prove it is also a str,
> but they fail because it cannot be sub-classed. Is there a reason to
> prevent sub-classing?
>
> 6. And relatedly, when I was working on PyType I noticed that it is
> possible to expose a Java sub-class as the same Python type as its parent.
> This would mean that type(PyShadowString("a", "b")) would be str even
> though the behaviour is different. This sounds worth trying.
>
> Jeff
>
> --
> Jeff Allen
>
>
>

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2018-08-17 - 2018-08-24)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     345 ( +0)
  closed  2375 ( +0)
  total   2720 ( +0)

Open issues with patches: 28   


Most recent 15 issues with no replies (15)
==========================================

#2698: urllib2.URLError: <urlopen error unknown url type: https>
http://bugs.jython.org/issue2698

#2697: name$py.class is ignored when in a JAR with name.py
http://bugs.jython.org/issue2697

#2684: WindowsError:[Error 123] The filename,directory name,or volume
http://bugs.jython.org/issue2684

#2681: Arbitrary file retrieval
http://bugs.jython.org/issue2681

#2680: Ignore Java accessibility rules selectively by package (Java 9
http://bugs.jython.org/issue2680

#2666: Imports in python from java do not work if there is a package 
http://bugs.jython.org/issue2666

#2665: Standalone jar includes test classes
http://bugs.jython.org/issue2665

#2663: Remove dependency on javax.xml.bind.DatatypeConverter
http://bugs.jython.org/issue2663

#2651: Travis Builds failing with *** buffer overflow detected ***
http://bugs.jython.org/issue2651

#2644: Representation of Java maps with String keys differs from Pyth
http://bugs.jython.org/issue2644

#2640: Virtualenv gets confused using paths with ~
http://bugs.jython.org/issue2640

#2633: Unicode garbled in writing to spreadsheet via openpyxl
http://bugs.jython.org/issue2633

#2631: jython 2.7.1 [Errno 107] Socket is not connected
http://bugs.jython.org/issue2631

#2618: socket.sendall no longer sends all
http://bugs.jython.org/issue2618

#2616: Incomplete / broken support for Certificate Revocation Lists
http://bugs.jython.org/issue2616



Most recent 15 issues waiting for review (15)
=============================================

#2664: subprocess in jython ends with IOError: Stream closed
http://bugs.jython.org/issue2664

#2635: AST.lineno ignored by compile
http://bugs.jython.org/issue2635

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2363: relative seeks works incorrectly after readline
http://bugs.jython.org/issue2363

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embeds other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

[Jython-dev] JDK 11: First Release Candidate available

[Rory O'D. <ror...@or...>]

Hi Alan,

*JDK 11 build 28 is our first JDK 11 Release Candidate [1]
*

  * JDK 11 Early Access  build 28 is available at : - jdk.java.net/11/

*FOSS fixes in recent builds.*

  * Eclipse Jetty - JDK-8207177
    <https://bugs.openjdk.java.net/browse/JDK-8207177> (b27)
  * Apache Tomcat   -JDK-8208642
    <https://bugs.openjdk.java.net/browse/JDK-8208642>(b27)
  * JBoss Netty - JDK-8207029
    <https://bugs.openjdk.java.net/browse/JDK-8207029> (b23),
    JDK-8208166 <https://bugs.openjdk.java.net/browse/JDK-8208166> (b25)

*JDK 12 Early Access build 8 is available at : - jdk.java.net/12/*

  * Release Notes for JDK 12 [2]
  * Changes in this build include
      o JDK-8208350 <https://bugs.openjdk.java.net/browse/JDK-8208350> -
        Disable all DES TLS cipher suites

*OpenJFX Early-Access Build 24 is available at :-* 
*http://jdk.java.net/openjfx/*

  * This library is delivered as a set of modules, along with the native
    code needed to run JavaFX, that can be run using a JDK 10
    <http://jdk.java.net/10/> build or a JDK 11 EA
    <http://jdk.java.net/11/> build.
  * This build is intended to allow application developers and OpenJFX
    contributors to test their applications with an unbundled,
    standalone JavaFX library.

Regards,
Rory

[1] 
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html 
<http://openjdk.java.net/projects/jdk/11/#Schedule>
[2] http://jdk.java.net/12/release-notes


-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: [Jython-dev] Versions in extlibs and Gradle

[Adam B. <ada...@gm...>]

Good topic. It’s really really good to see Jython moving to declared dependency management instead of a jar folder. 2 cents from me ...

At work I have always favoured strictly pinned versions, for determinism / repeatability reasons. Being able to reproduce exactly the classes being used at a particular point in time can be invaluable with deep dependency trees and wide usage of different versions.

People usually aren’t too shy about forcing different dependency versions if needed in my experience.

I do see some advantages to the less strict versions, around maintenance and advertising to developers the choice of specific version is somewhat arbitrary (which it often is, especially when talking about patch versions.)

This blog post has a good discussion about pinned versions
https://brock.io/post/repeatable_android_builds/

It also points on to an interesting dependency lock plugin.
https://github.com/nebula-plugins/gradle-dependency-lock-plugin

I haven’t used that plugin in anger, but it might allow the best of both worlds.

Cheers 
Adam

> 在 2018年8月14日，上午5:36，Jeff Allen <ja...@fa...> 写道：
> 
> One of the things we were looking forward to with Gradle was that it would become easier to control the versions of JARs (modules) we depend on. Gradle can get quite sophisticated about this: you can have anything you want. Only ... what do we want?
> 
> * If we only specify a module name, we'll get the latest all the time
>   (with obvious risks).
> * If a module moves to a new API we aren't ready for, we can specify
>   the version in part (3.1.+), and continue to take minor/patch releases.
> * If a module has to be pinned to an exact version, we can name it
>   explicitly (or an acceptable range).
> 
> At least we don't have to check the JAR in: just change the dependency statements (once we use Gradle exclusively). If we build distributions with Gradle like the JARs we build now, I believe we end up jarjar'ring the dynamically downloaded modules, but I haven't tried that yet.
> 
> A second dimension is when other projects cite Jython as a dependency and get our dependencies transitively. Consuming projects are able to override our version choices (if I understand correctly, https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version). The less specific we are about version,  the more helpful to consumers. However, these might be untested combinations.
> 
> Any thoughts how to tell, for a given module, what the sensible policy would be?
> 
> -- 
> Jeff Allen
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev