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

Re: [Jython-dev] Custom JAR using standalone Jython 2.7.2 doesn't obey JYTHONPATH

[Alan K. <jyt...@xh...>]

Is this documentation out of date?

https://www.jython.org/registry.html

I always found it accurate in the past.

Alan.


On Sun, Mar 29, 2020, 8:43 PM Jeff Allen <ja...@fa...> wrote:

> I find initialisation difficult to follow too, although I have
> single-stepped it a hundred times. It may help to see where the environment
> is picked up now in the main program:
>
>
> https://github.com/jythontools/jython/blob/f77cc106afc4b0b61426ae4212c1e38d20ec942d/src/org/python/util/jython.java#L498
>
> and this simply involves getting things from the variables and setting
> them in the Java properties that get passed into initialisation:
>
>
> https://github.com/jythontools/jython/blob/f77cc106afc4b0b61426ae4212c1e38d20ec942d/src/org/python/util/jython.java#L709
>
> These are just the system properties in this case, although the
> initialisation is designed to allow them to come from elsewhere. (This is
> where I get lost, but the simple case is simple enough.)
>
> The manifest in the standalone JAR makes org.python.util.jython the main
> class, so it runs when you run the JAR with java -jar, therefore it picks
> up JYTHONPATH in the places I've linked, to be the default value of
> python.path. Or you could (I think) have given -Dpython.path=... to java
> instead.
>
> Sorry this change was a surprise. Of course, there are no major releases
> to come (no 2.8, I mean).
>
> Jeff
>
> Jeff Allen
>
> On 29/03/2020 10:06, Pekka Klärck wrote:
>
> Hi,
>
> I understand the idea to isolate the JAR from the environment, but I'm
> still a bit surprised that this was changed in a minor release and
> that when I use `java -jar jython-standalone-2.7.2.jar` JYTHONPATH is
> actually obeyed. Anyway, this isn't a big problem for us as we can
> explicitly handle JYTHONPATH ourselves. My current solution is doing
> that on Python side and calling the function that does it as part of
> creating the runner on Java side. You can see it here if you are
> interested:https://github.com/robotframework/robotframework/commit/cce18967c8b27a14239112b74b66e57e4584f3b0
>
> I also looked at configuring `python.path` via `PythonInterpreter`. If
> I understood it correctly, I should call
> `PythonInterpreter.initialize` before creating a `PythonInterpreter`
> instance and the `initialize` method needs also arguments in addition
> to properties. Due to how our code is structured and arguments are
> passed nowadays, that looked rather complicated. If there's some
> easier way to set `pytohn.path` perhaps it could work. That said, I'm
> fine with the above solution that seems to work fine in our tests.
>
> Thanks again for Jython 2.7.2 everyone involved!
>
> Cheers,
>     .peke
>
> la 28. maalisk. 2020 klo 13.48 Jeff Allen (ja...@fa...) kirjoitti:
>
>
> I think this is because you are no longer running the interpreter via the jython.main() programme. Try setting in the Java System property python.path, what you might have put in JYTHONPATH.
>
> If you are initialising Jython with your own properties object(s) it should go in the earliest consulted, I suspect.
>
> Rationale
>
> The design intent in Jython is that it use the registry (Java properties) as the means of configuring the interpreter. (Well, it seems to have been that from early on: I'm inferring a principle from the implementation.) Java promotes a platform-independent world where the Java interpreter can be launched any number of ways, and there isn't necessarily a shell environment in the way Unix and C have led us to expect. System properties, however, are a Java feature so it must always be possible to set them.
>
> The main program, that you might invoke from the console (even if it is via the java command rather than the launcher), sits as a bridge between console world and Java world, and so I think it is only there that environment variables should be consulted, rather than in a scattered way. (This was mostly true already, but maybe not for JYTHONPATH.) Implementation of the -E option (ignore environment variables), and of trying to be more faithful to CPython in our main program, is behind making this absolute.
>
> Jeff
>
> On 27/03/2020 21:59, Pekka Klärck wrote:
>
> Hi,
>
> In the Robot Framework project
> (https://github.com/robotframework/robotframework) one of our
> distributions is a standalone JAR that is built on top of standalone
> Jython. We've earlier used Jython 2.7.0, but there have been lot of
> fixes since that and we are now planning to switch to Jython 2.7.2. I
> have already changed our build scripts and have been running all our
> acceptance tests using the new JAR.
>
> Things have worked pretty well with the new JAR otherwise, but it
> seems it doesn't obey JYTHONPATH set externally before execution.
> Executing Python code can see the environment variable, but Python
> modules in directories listed in it cannot be imported. I just tested
> that if I build a JAR from same sources with Jython 2.7.0, JYTHONPATH
> works as expected.
>
> The strange thing is that when I tested with the standalone Jython
> 2.7.2 alone, it did handle JYTHONPATH just fine. This got me thinking
> that perhaps we are somehow embedding Jython wrong. Are there some
> know changes related to embedding Jython using PythonInterpreter?
> Should we perhaps configure it somehow to get JYTHONPATH processed
> correctly? The code currently just initialized PythonInterpreter
> without any arguments and then calls `interpreter.exec(code)`. You can
> find the full code here:https://github.com/robotframework/robotframework/blob/master/src/java/org/robotframework/RobotRunner.java
>
> One workaround for us is processing JYTHONPATH in our code and I
> already tested that it works. If that turns out to be the only
> solution, I just need to find a way to do that only when using the JAR
> distribution.
>
> Cheers,
>     .peke
>
>
>
>  _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Custom JAR using standalone Jython 2.7.2 doesn't obey JYTHONPATH

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

I find initialisation difficult to follow too, although I have 
single-stepped it a hundred times. It may help to see where the 
environment is picked up now in the main program:

https://github.com/jythontools/jython/blob/f77cc106afc4b0b61426ae4212c1e38d20ec942d/src/org/python/util/jython.java#L498

and this simply involves getting things from the variables and setting 
them in the Java properties that get passed into initialisation:

https://github.com/jythontools/jython/blob/f77cc106afc4b0b61426ae4212c1e38d20ec942d/src/org/python/util/jython.java#L709

These are just the system properties in this case, although the 
initialisation is designed to allow them to come from elsewhere. (This 
is where I get lost, but the simple case is simple enough.)

The manifest in the standalone JAR makes org.python.util.jython the main 
class, so it runs when you run the JAR with java -jar, therefore it 
picks up JYTHONPATH in the places I've linked, to be the default value 
of python.path. Or you could (I think) have given -Dpython.path=... to 
java instead.

Sorry this change was a surprise. Of course, there are no major releases 
to come (no 2.8, I mean).

Jeff

Jeff Allen

On 29/03/2020 10:06, Pekka Klärck wrote:
> Hi,
>
> I understand the idea to isolate the JAR from the environment, but I'm
> still a bit surprised that this was changed in a minor release and
> that when I use `java -jar jython-standalone-2.7.2.jar` JYTHONPATH is
> actually obeyed. Anyway, this isn't a big problem for us as we can
> explicitly handle JYTHONPATH ourselves. My current solution is doing
> that on Python side and calling the function that does it as part of
> creating the runner on Java side. You can see it here if you are
> interested:
> https://github.com/robotframework/robotframework/commit/cce18967c8b27a14239112b74b66e57e4584f3b0
>
> I also looked at configuring `python.path` via `PythonInterpreter`. If
> I understood it correctly, I should call
> `PythonInterpreter.initialize` before creating a `PythonInterpreter`
> instance and the `initialize` method needs also arguments in addition
> to properties. Due to how our code is structured and arguments are
> passed nowadays, that looked rather complicated. If there's some
> easier way to set `pytohn.path` perhaps it could work. That said, I'm
> fine with the above solution that seems to work fine in our tests.
>
> Thanks again for Jython 2.7.2 everyone involved!
>
> Cheers,
>      .peke
>
> la 28. maalisk. 2020 klo 13.48 Jeff Allen (ja...@fa...) kirjoitti:
>> I think this is because you are no longer running the interpreter via the jython.main() programme. Try setting in the Java System property python.path, what you might have put in JYTHONPATH.
>>
>> If you are initialising Jython with your own properties object(s) it should go in the earliest consulted, I suspect.
>>
>> Rationale
>>
>> The design intent in Jython is that it use the registry (Java properties) as the means of configuring the interpreter. (Well, it seems to have been that from early on: I'm inferring a principle from the implementation.) Java promotes a platform-independent world where the Java interpreter can be launched any number of ways, and there isn't necessarily a shell environment in the way Unix and C have led us to expect. System properties, however, are a Java feature so it must always be possible to set them.
>>
>> The main program, that you might invoke from the console (even if it is via the java command rather than the launcher), sits as a bridge between console world and Java world, and so I think it is only there that environment variables should be consulted, rather than in a scattered way. (This was mostly true already, but maybe not for JYTHONPATH.) Implementation of the -E option (ignore environment variables), and of trying to be more faithful to CPython in our main program, is behind making this absolute.
>>
>> Jeff
>>
>> On 27/03/2020 21:59, Pekka Klärck wrote:
>>
>> Hi,
>>
>> In the Robot Framework project
>> (https://github.com/robotframework/robotframework) one of our
>> distributions is a standalone JAR that is built on top of standalone
>> Jython. We've earlier used Jython 2.7.0, but there have been lot of
>> fixes since that and we are now planning to switch to Jython 2.7.2. I
>> have already changed our build scripts and have been running all our
>> acceptance tests using the new JAR.
>>
>> Things have worked pretty well with the new JAR otherwise, but it
>> seems it doesn't obey JYTHONPATH set externally before execution.
>> Executing Python code can see the environment variable, but Python
>> modules in directories listed in it cannot be imported. I just tested
>> that if I build a JAR from same sources with Jython 2.7.0, JYTHONPATH
>> works as expected.
>>
>> The strange thing is that when I tested with the standalone Jython
>> 2.7.2 alone, it did handle JYTHONPATH just fine. This got me thinking
>> that perhaps we are somehow embedding Jython wrong. Are there some
>> know changes related to embedding Jython using PythonInterpreter?
>> Should we perhaps configure it somehow to get JYTHONPATH processed
>> correctly? The code currently just initialized PythonInterpreter
>> without any arguments and then calls `interpreter.exec(code)`. You can
>> find the full code here:
>> https://github.com/robotframework/robotframework/blob/master/src/java/org/robotframework/RobotRunner.java
>>
>> One workaround for us is processing JYTHONPATH in our code and I
>> already tested that it works. If that turns out to be the only
>> solution, I just need to find a way to do that only when using the JAR
>> distribution.
>>
>> Cheers,
>>      .peke
>
>

Re: [Jython-dev] Custom JAR using standalone Jython 2.7.2 doesn't obey JYTHONPATH

[Pekka K. <pe...@ik...>]

Hi,

I understand the idea to isolate the JAR from the environment, but I'm
still a bit surprised that this was changed in a minor release and
that when I use `java -jar jython-standalone-2.7.2.jar` JYTHONPATH is
actually obeyed. Anyway, this isn't a big problem for us as we can
explicitly handle JYTHONPATH ourselves. My current solution is doing
that on Python side and calling the function that does it as part of
creating the runner on Java side. You can see it here if you are
interested:
https://github.com/robotframework/robotframework/commit/cce18967c8b27a14239112b74b66e57e4584f3b0

I also looked at configuring `python.path` via `PythonInterpreter`. If
I understood it correctly, I should call
`PythonInterpreter.initialize` before creating a `PythonInterpreter`
instance and the `initialize` method needs also arguments in addition
to properties. Due to how our code is structured and arguments are
passed nowadays, that looked rather complicated. If there's some
easier way to set `pytohn.path` perhaps it could work. That said, I'm
fine with the above solution that seems to work fine in our tests.

Thanks again for Jython 2.7.2 everyone involved!

Cheers,
    .peke

la 28. maalisk. 2020 klo 13.48 Jeff Allen (ja...@fa...) kirjoitti:
>
> I think this is because you are no longer running the interpreter via the jython.main() programme. Try setting in the Java System property python.path, what you might have put in JYTHONPATH.
>
> If you are initialising Jython with your own properties object(s) it should go in the earliest consulted, I suspect.
>
> Rationale
>
> The design intent in Jython is that it use the registry (Java properties) as the means of configuring the interpreter. (Well, it seems to have been that from early on: I'm inferring a principle from the implementation.) Java promotes a platform-independent world where the Java interpreter can be launched any number of ways, and there isn't necessarily a shell environment in the way Unix and C have led us to expect. System properties, however, are a Java feature so it must always be possible to set them.
>
> The main program, that you might invoke from the console (even if it is via the java command rather than the launcher), sits as a bridge between console world and Java world, and so I think it is only there that environment variables should be consulted, rather than in a scattered way. (This was mostly true already, but maybe not for JYTHONPATH.) Implementation of the -E option (ignore environment variables), and of trying to be more faithful to CPython in our main program, is behind making this absolute.
>
> Jeff
>
> On 27/03/2020 21:59, Pekka Klärck wrote:
>
> Hi,
>
> In the Robot Framework project
> (https://github.com/robotframework/robotframework) one of our
> distributions is a standalone JAR that is built on top of standalone
> Jython. We've earlier used Jython 2.7.0, but there have been lot of
> fixes since that and we are now planning to switch to Jython 2.7.2. I
> have already changed our build scripts and have been running all our
> acceptance tests using the new JAR.
>
> Things have worked pretty well with the new JAR otherwise, but it
> seems it doesn't obey JYTHONPATH set externally before execution.
> Executing Python code can see the environment variable, but Python
> modules in directories listed in it cannot be imported. I just tested
> that if I build a JAR from same sources with Jython 2.7.0, JYTHONPATH
> works as expected.
>
> The strange thing is that when I tested with the standalone Jython
> 2.7.2 alone, it did handle JYTHONPATH just fine. This got me thinking
> that perhaps we are somehow embedding Jython wrong. Are there some
> know changes related to embedding Jython using PythonInterpreter?
> Should we perhaps configure it somehow to get JYTHONPATH processed
> correctly? The code currently just initialized PythonInterpreter
> without any arguments and then calls `interpreter.exec(code)`. You can
> find the full code here:
> https://github.com/robotframework/robotframework/blob/master/src/java/org/robotframework/RobotRunner.java
>
> One workaround for us is processing JYTHONPATH in our code and I
> already tested that it works. If that turns out to be the only
> solution, I just need to find a way to do that only when using the JAR
> distribution.
>
> Cheers,
>     .peke



-- 
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

Re: [Jython-dev] Custom JAR using standalone Jython 2.7.2 doesn't obey JYTHONPATH

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

I think this is because you are no longer running the interpreter via 
the jython.main() programme. Try setting in the Java System property 
python.path, what you might have put in JYTHONPATH.

If you are initialising Jython with your own properties object(s) it 
should go in the earliest consulted, I suspect.

*Rationale**
*

The design intent in Jython is that it use the registry (Java 
properties) as the means of configuring the interpreter. (Well, it seems 
to have been that from early on: I'm inferring a principle from the 
implementation.) Java promotes a platform-independent world where the 
Java interpreter can be launched any number of ways, and there isn't 
necessarily a shell environment in the way Unix and C have led us to 
expect. System properties, however, are a Java feature so it must always 
be possible to set them.

The main program, that you might invoke from the console (even if it is 
via the java command rather than the launcher), sits as a bridge between 
console world and Java world, and so I think it is only there that 
environment variables should be consulted, rather than in a scattered 
way. (This was mostly true already, but maybe not for JYTHONPATH.) 
Implementation of the -E option (ignore environment variables), and of 
trying to be more faithful to CPython in our main program, is behind 
making this absolute.

Jeff

On 27/03/2020 21:59, Pekka Klärck wrote:
> Hi,
>
> In the Robot Framework project
> (https://github.com/robotframework/robotframework) one of our
> distributions is a standalone JAR that is built on top of standalone
> Jython. We've earlier used Jython 2.7.0, but there have been lot of
> fixes since that and we are now planning to switch to Jython 2.7.2. I
> have already changed our build scripts and have been running all our
> acceptance tests using the new JAR.
>
> Things have worked pretty well with the new JAR otherwise, but it
> seems it doesn't obey JYTHONPATH set externally before execution.
> Executing Python code can see the environment variable, but Python
> modules in directories listed in it cannot be imported. I just tested
> that if I build a JAR from same sources with Jython 2.7.0, JYTHONPATH
> works as expected.
>
> The strange thing is that when I tested with the standalone Jython
> 2.7.2 alone, it did handle JYTHONPATH just fine. This got me thinking
> that perhaps we are somehow embedding Jython wrong. Are there some
> know changes related to embedding Jython using PythonInterpreter?
> Should we perhaps configure it somehow to get JYTHONPATH processed
> correctly? The code currently just initialized PythonInterpreter
> without any arguments and then calls `interpreter.exec(code)`. You can
> find the full code here:
> https://github.com/robotframework/robotframework/blob/master/src/java/org/robotframework/RobotRunner.java
>
> One workaround for us is processing JYTHONPATH in our code and I
> already tested that it works. If that turns out to be the only
> solution, I just need to find a way to do that only when using the JAR
> distribution.
>
> Cheers,
>      .peke

[Jython-dev] Custom JAR using standalone Jython 2.7.2 doesn't obey JYTHONPATH

[Pekka K. <pe...@ik...>]

Hi,

In the Robot Framework project
(https://github.com/robotframework/robotframework) one of our
distributions is a standalone JAR that is built on top of standalone
Jython. We've earlier used Jython 2.7.0, but there have been lot of
fixes since that and we are now planning to switch to Jython 2.7.2. I
have already changed our build scripts and have been running all our
acceptance tests using the new JAR.

Things have worked pretty well with the new JAR otherwise, but it
seems it doesn't obey JYTHONPATH set externally before execution.
Executing Python code can see the environment variable, but Python
modules in directories listed in it cannot be imported. I just tested
that if I build a JAR from same sources with Jython 2.7.0, JYTHONPATH
works as expected.

The strange thing is that when I tested with the standalone Jython
2.7.2 alone, it did handle JYTHONPATH just fine. This got me thinking
that perhaps we are somehow embedding Jython wrong. Are there some
know changes related to embedding Jython using PythonInterpreter?
Should we perhaps configure it somehow to get JYTHONPATH processed
correctly? The code currently just initialized PythonInterpreter
without any arguments and then calls `interpreter.exec(code)`. You can
find the full code here:
https://github.com/robotframework/robotframework/blob/master/src/java/org/robotframework/RobotRunner.java

One workaround for us is processing JYTHONPATH in our code and I
already tested that it works. If that turns out to be the only
solution, I just need to find a way to do that only when using the JAR
distribution.

Cheers,
    .peke
-- 
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Jython-dev] Summary of Jython tracker Issues

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

ACTIVITY SUMMARY (2020-03-20 - 2020-03-27)
Jython tracker at https://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     332 ( +0)
  closed  2484 ( +0)
  total   2816 ( +0)

Open issues with patches: 22   


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

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2792: Failures in test_import_jy from Java 13
https://bugs.jython.org/issue2792

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790

#2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7
https://bugs.jython.org/issue2770

#2760: How to call procedure with use zxjdbc and get back OUT paramet
https://bugs.jython.org/issue2760

#2754: Failure in Py.initProxy for class not at module level
https://bugs.jython.org/issue2754

#2752: Allow Python functions to be used as a java.lang.FunctionalInt
https://bugs.jython.org/issue2752

#2750: Make PyFunction implement java.util.concurrent.Callable<PyObje
https://bugs.jython.org/issue2750

#2734: Re-work package scanning and cache for modules
https://bugs.jython.org/issue2734

#2723: Unusual behavior in SimpleCookie when '=' and '@'  is used in 
https://bugs.jython.org/issue2723

#2722: run-time issue while trying to reach external endpoint (Weathe
https://bugs.jython.org/issue2722



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

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

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

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

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

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

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

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

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

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

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

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

Re: [Jython-dev] Jython 2.7.2 final

[Yaqiang W. <yaq...@gm...>]

Thanks to the developers of Jython 2.7.2, which has been used in MeteoInfo
2.1.5 (http://www.meteothink.org/downloads/index.html). Everything is ok at
present!

Regards
Yaqiang

On Sun, Mar 22, 2020 at 5:13 PM Jeff Allen <ja...@fa...> wrote:

> Thanks Jim. At a quick count, 12 people have contributed to the progress
> since 2.7.1 (June 2017). It is good, at last, to be able to say their work
> is able to reach its full set of users.
>
> If you have an OSX machine to try it on, that would complete the set of
> post-staging hosts. Travis CI is currently giving us a falure for OSX:
>
> https://travis-ci.org/github/jythontools/jython/builds/665248611?utm_medium=notification&utm_source=github_status
>
> Nothing relevant has changed since this was passing, and this is a failure
> to run, rather than a test failure per se, so I regard it as a false alarm.
> The timing is unfortunate, as we all prefer green ticks, especially on a
> release point
>
> Jeff
>
> Jeff Allen
>
> On 22/03/2020 07:03, Jim Baker wrote:
>
> Jeff,
>
> Thanks for putting this release together. In my limited testing so far,
> everything is working great! I plan to hammer it on more, but it seems
> ready to announce to our user community.
>
> - Jim
>
> On Sat, Mar 21, 2020 at 3:08 PM Jeff Allen <ja...@fa...> wrote:
>
>> All:
>>
>> We arrive at last. All your efforts will shortly bear fruit in a public
>> release of Jython. :)
>>
>> Installer: https://oss.sonatype.org/content/repositories/orgpython-1095
>>
>> Standalone: https://oss.sonatype.org/content/repositories/orgpython-1094
>>
>> Slim JAR (Gradle/Maven):
>> https://oss.sonatype.org/content/repositories/orgpython-1093
>>
>> Fat JAR (dependencies):
>> https://oss.sonatype.org/content/repositories/orgpython-1092
>>
>> These are temporary staging locations, the last step before public
>> release. All being well, in the tiny bubble of normality that is the
>> Jython project, I propose to release these for public use tomorrow (22
>> March).
>>
>> 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
>


-- 
*************************************************
Dr. Yaqiang Wang
Chinese Academy of Meteorological Sciences (CAMS)
46, Zhong-Guan-Cun South Avenue
Beijing, 100081
China

yaq...@gm...

www.meteothink.org
**************************************************

Re: [Jython-dev] Jython 2.7.2 final

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

Thanks Jim. At a quick count, 12 people have contributed to the progress 
since 2.7.1 (June 2017). It is good, at last, to be able to say their 
work is able to reach its full set of users.

If you have an OSX machine to try it on, that would complete the set of 
post-staging hosts. Travis CI is currently giving us a falure for OSX:

https://travis-ci.org/github/jythontools/jython/builds/665248611?utm_medium=notification&utm_source=github_status 


Nothing relevant has changed since this was passing, and this is a 
failure to run, rather than a test failure per se, so I regard it as a 
false alarm. The timing is unfortunate, as we all prefer green ticks, 
especially on a release point

Jeff

Jeff Allen

On 22/03/2020 07:03, Jim Baker wrote:
> Jeff,
>
> Thanks for putting this release together. In my limited testing so 
> far, everything is working great! I plan to hammer it on more, but it 
> seems ready to announce to our user community.
>
> - Jim
>
> On Sat, Mar 21, 2020 at 3:08 PM Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     All:
>
>     We arrive at last. All your efforts will shortly bear fruit in a
>     public
>     release of Jython. :)
>
>     Installer:
>     https://oss.sonatype.org/content/repositories/orgpython-1095
>
>     Standalone:
>     https://oss.sonatype.org/content/repositories/orgpython-1094
>
>     Slim JAR (Gradle/Maven):
>     https://oss.sonatype.org/content/repositories/orgpython-1093
>
>     Fat JAR (dependencies):
>     https://oss.sonatype.org/content/repositories/orgpython-1092
>
>     These are temporary staging locations, the last step before public
>     release. All being well, in the tiny bubble of normality that is the
>     Jython project, I propose to release these for public use tomorrow
>     (22
>     March).
>
>     Jeff
>
>     -- 
>     Jeff Allen
>
>
>
>     _______________________________________________
>     Jython-dev mailing list
>     Jyt...@li...
>     <mailto:Jyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Jython 2.7.2 final

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

Jeff,

Thanks for putting this release together. In my limited testing so far,
everything is working great! I plan to hammer it on more, but it seems
ready to announce to our user community.

- Jim

On Sat, Mar 21, 2020 at 3:08 PM Jeff Allen <ja...@fa...> wrote:

> All:
>
> We arrive at last. All your efforts will shortly bear fruit in a public
> release of Jython. :)
>
> Installer: https://oss.sonatype.org/content/repositories/orgpython-1095
>
> Standalone: https://oss.sonatype.org/content/repositories/orgpython-1094
>
> Slim JAR (Gradle/Maven):
> https://oss.sonatype.org/content/repositories/orgpython-1093
>
> Fat JAR (dependencies):
> https://oss.sonatype.org/content/repositories/orgpython-1092
>
> These are temporary staging locations, the last step before public
> release. All being well, in the tiny bubble of normality that is the
> Jython project, I propose to release these for public use tomorrow (22
> March).
>
> Jeff
>
> --
> Jeff Allen
>
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

[Jython-dev] Jython 2.7.2 final

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

All:

We arrive at last. All your efforts will shortly bear fruit in a public 
release of Jython. :)

Installer: https://oss.sonatype.org/content/repositories/orgpython-1095

Standalone: https://oss.sonatype.org/content/repositories/orgpython-1094

Slim JAR (Gradle/Maven): 
https://oss.sonatype.org/content/repositories/orgpython-1093

Fat JAR (dependencies): 
https://oss.sonatype.org/content/repositories/orgpython-1092

These are temporary staging locations, the last step before public 
release. All being well, in the tiny bubble of normality that is the 
Jython project, I propose to release these for public use tomorrow (22 
March).

Jeff

-- 
Jeff Allen

[Jython-dev] Summary of Jython tracker Issues

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

ACTIVITY SUMMARY (2020-03-13 - 2020-03-20)
Jython tracker at https://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     332 ( +0)
  closed  2484 ( +0)
  total   2816 ( +0)

Open issues with patches: 22   


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

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2792: Failures in test_import_jy from Java 13
https://bugs.jython.org/issue2792

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790

#2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7
https://bugs.jython.org/issue2770

#2760: How to call procedure with use zxjdbc and get back OUT paramet
https://bugs.jython.org/issue2760

#2754: Failure in Py.initProxy for class not at module level
https://bugs.jython.org/issue2754

#2752: Allow Python functions to be used as a java.lang.FunctionalInt
https://bugs.jython.org/issue2752

#2750: Make PyFunction implement java.util.concurrent.Callable<PyObje
https://bugs.jython.org/issue2750

#2734: Re-work package scanning and cache for modules
https://bugs.jython.org/issue2734

#2723: Unusual behavior in SimpleCookie when '=' and '@'  is used in 
https://bugs.jython.org/issue2723

#2722: run-time issue while trying to reach external endpoint (Weathe
https://bugs.jython.org/issue2722



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

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

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

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

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

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

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

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

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

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

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

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336



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

#2870: PrePy.getJarFileNameFromURL fails hard when Jython jar is embe
https://bugs.jython.org/issue2870   3 msgs

Re: [Jython-dev] Jython 2.7.2rc1

[Pekka K. <pe...@ik...>]

Awesome! Thanks for your and others work getting Jython 2.7.2 ready!

Cheers,
    .peke

ke 18. maalisk. 2020 klo 20.54 Jeff Allen (ja...@fa...) kirjoitti:
>
> I've a day free this week so I think I shall use that for Jython 2.7.2, which with due care, means it should be public by Monday.
>
> Jeff Allen
>
> On 17/03/2020 09:21, Pekka Klärck wrote:
>
> H,
>
> JAVA_OPTS seems to work pretty well in our case. Somewhat unfortunate
> that value that works with Java 11 causes and error with Java 8 and we
> thus need to set it conditionally before test execution starts.
>
> Console encodings are hard. Just using UTF-8 would be a good choice,
> that's what CPython nowadays does on Windows as well. I hope this
> insn't changed in future Jython 2.7.x releases, though. It would be
> quite badly backwards incompatible change.
>
> Do you have plans when Jython 2.7.2 final would be released?
>
> Cheers,
>     .peke
>
> pe 13. maalisk. 2020 klo 22.24 Jeff Allen (ja...@fa...) kirjoitti:
>
> Thanks for testing that, and for the feedback (especially as it's not a blocker).
>
> It may help to look at where we test violating accessibility rules deliberately. There we prepare the ground like this: https://hg.python.org/jython/file/v2.7.2rc1/Lib/test/test_java_visibility.py#l240 . Note also that Jython respects the environment variable JAVA_OPTS, see https://github.com/jythontools/jython/issues/171#issuecomment-598889263.
>
> Console encoding has been such a pain. I spent a long time getting it as "right" as possible, even for Greek and Chinese, but at the expense of some buffering that proved unacceptable later. ISTR the solution to that partly undid the complicated layer-cake I'd built. I'm pretty sure there's a mistake here too involving multiple system states.
>
> If I touch this again, console encoding will be fixed at utf-8 as far as Python knows and Java will translate to whatever system encoding it would use for strings. (At least, ... if that can be made satisfactory for users.) Thanks for your tolerance!
>
> Jeff Allen
>
> On 12/03/2020 11:22, Pekka Klärck wrote:
>
> Hi,
>
> We run Robot Framework's
> (https://github.com/robotframework/robotframework/) acceptance tests
> with 2.7.2rc1 both on Linux and Windows with Java 8 and results look
> very good. On Linux there were no failures and on Windows the only
> regression we encountered was change to `sys.stdxxx.encoding` in some
> special cases (https://bugs.jython.org/issue2868). I personally don't
> consider that a release blocker as the bug only occurs if outputs are
> redirected and we could argue that the value has always been wrong.
> With Python 2 the encoding is `None` in this case and with Python 3
> you get the encoding of the created file.
>
> We also run tests with Java 11, but due to illegal reflective access
> warnings logged to the console
> (https://github.com/jythontools/jython/issues/171) all tests
> validating console output fail and it's hard to tell are there real
> failures. Being able to disable these warnings would be great but I
> wouldn't post-pone the great looking release due to that.
>
> Cheers,
>     .peke
>
> to 5. maalisk. 2020 klo 22.12 Jeff Allen (ja...@fa...) kirjoitti:
>
> Now published. See: https://www.jython.org/download
>
> Are we all content for this to go out with our names on it? I've tried
> to arrange we make only safe changes between beta and rc, but it would
> be good to try it on as many platforms as we have amongst us.
>
> I built and it on Windows 10 and ran on Java 8 and 11 there. I also
> downloaded (the -install version) on Ubuntu with Java 11.
>
> How long an interval would you like? Precedents run from 2 days to we're
> still waiting, but I was thinking a week or two. Then I might try
> migrating to GitHub as we have said previously that we would.
>
> The CI does a good job, but of course does not install the way a user might.
>
> Jeff Allen
>
> On 02/03/2020 08:23, Jeff Allen wrote:
>
> On 23/02/2020 21:50, Jeff Allen wrote:
>
> It's beginning to look like we might be ready for a release
> candidate. Does anyone object? Have I missed a treasured patch?
>
> ...
>
> Bit busy this week, so probably this will be late in the week, and
> appear over next weekend.
>
> As we were all content, Jython 2.7.2rc1 is now staged at:
>
> https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar
>
>
> Other 3 jars at corresponding URLs. This this is the temporary
> location, "pre-publication", although publicly accessible.
>
> Jeff
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
>


-- 
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

Re: [Jython-dev] Jython 2.7.2rc1

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

I've a day free this week so I think I shall use that for Jython 2.7.2, 
which with due care, means it should be public by Monday.

Jeff Allen

On 17/03/2020 09:21, Pekka Klärck wrote:
> H,
>
> JAVA_OPTS seems to work pretty well in our case. Somewhat unfortunate
> that value that works with Java 11 causes and error with Java 8 and we
> thus need to set it conditionally before test execution starts.
>
> Console encodings are hard. Just using UTF-8 would be a good choice,
> that's what CPython nowadays does on Windows as well. I hope this
> insn't changed in future Jython 2.7.x releases, though. It would be
> quite badly backwards incompatible change.
>
> Do you have plans when Jython 2.7.2 final would be released?
>
> Cheers,
>      .peke
>
> pe 13. maalisk. 2020 klo 22.24 Jeff Allen (ja...@fa...) kirjoitti:
>> Thanks for testing that, and for the feedback (especially as it's not a blocker).
>>
>> It may help to look at where we test violating accessibility rules deliberately. There we prepare the ground like this: https://hg.python.org/jython/file/v2.7.2rc1/Lib/test/test_java_visibility.py#l240 . Note also that Jython respects the environment variable JAVA_OPTS, see https://github.com/jythontools/jython/issues/171#issuecomment-598889263.
>>
>> Console encoding has been such a pain. I spent a long time getting it as "right" as possible, even for Greek and Chinese, but at the expense of some buffering that proved unacceptable later. ISTR the solution to that partly undid the complicated layer-cake I'd built. I'm pretty sure there's a mistake here too involving multiple system states.
>>
>> If I touch this again, console encoding will be fixed at utf-8 as far as Python knows and Java will translate to whatever system encoding it would use for strings. (At least, ... if that can be made satisfactory for users.) Thanks for your tolerance!
>>
>> Jeff Allen
>>
>> On 12/03/2020 11:22, Pekka Klärck wrote:
>>
>> Hi,
>>
>> We run Robot Framework's
>> (https://github.com/robotframework/robotframework/) acceptance tests
>> with 2.7.2rc1 both on Linux and Windows with Java 8 and results look
>> very good. On Linux there were no failures and on Windows the only
>> regression we encountered was change to `sys.stdxxx.encoding` in some
>> special cases (https://bugs.jython.org/issue2868). I personally don't
>> consider that a release blocker as the bug only occurs if outputs are
>> redirected and we could argue that the value has always been wrong.
>> With Python 2 the encoding is `None` in this case and with Python 3
>> you get the encoding of the created file.
>>
>> We also run tests with Java 11, but due to illegal reflective access
>> warnings logged to the console
>> (https://github.com/jythontools/jython/issues/171) all tests
>> validating console output fail and it's hard to tell are there real
>> failures. Being able to disable these warnings would be great but I
>> wouldn't post-pone the great looking release due to that.
>>
>> Cheers,
>>      .peke
>>
>> to 5. maalisk. 2020 klo 22.12 Jeff Allen (ja...@fa...) kirjoitti:
>>
>> Now published. See: https://www.jython.org/download
>>
>> Are we all content for this to go out with our names on it? I've tried
>> to arrange we make only safe changes between beta and rc, but it would
>> be good to try it on as many platforms as we have amongst us.
>>
>> I built and it on Windows 10 and ran on Java 8 and 11 there. I also
>> downloaded (the -install version) on Ubuntu with Java 11.
>>
>> How long an interval would you like? Precedents run from 2 days to we're
>> still waiting, but I was thinking a week or two. Then I might try
>> migrating to GitHub as we have said previously that we would.
>>
>> The CI does a good job, but of course does not install the way a user might.
>>
>> Jeff Allen
>>
>> On 02/03/2020 08:23, Jeff Allen wrote:
>>
>> On 23/02/2020 21:50, Jeff Allen wrote:
>>
>> It's beginning to look like we might be ready for a release
>> candidate. Does anyone object? Have I missed a treasured patch?
>>
>> ...
>>
>> Bit busy this week, so probably this will be late in the week, and
>> appear over next weekend.
>>
>> As we were all content, Jython 2.7.2rc1 is now staged at:
>>
>> https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar
>>
>>
>> Other 3 jars at corresponding URLs. This this is the temporary
>> location, "pre-publication", although publicly accessible.
>>
>> Jeff
>>
>>
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>>
>

[Jython-dev] Release Announcement: General Availability of Java 14 / JDK 14

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

  Hi Alan,


**Release Announcement: General Availability of Java 14 / JDK 14 [1] * *

  * JDK 14, the reference implementation of Java 14, is now Generally
    Available.
  * GPL-licensed OpenJDK builds from Oracle are available here:
    https://jdk.java.net/14
  * JDK 14 Release notes
    <https://www.oracle.com/technetwork/java/javase/14-relnote-issues-5809570.html>



JDK 14  includes sixteen features [2]:

   305: Pattern Matching for instanceof (Preview)
   343: Packaging Tool (Incubator)
   345: NUMA-Aware Memory Allocation for G1
   349: JFR Event Streaming
   352: Non-Volatile Mapped Byte Buffers
   358: Helpful NullPointerExceptions
   359: Records (Preview)
   361: Switch Expressions (Standard)
   362: Deprecate the Solaris and SPARC Ports
   363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector
   364: ZGC on macOS
   365: ZGC on Windows
   366: Deprecate the ParallelScavenge + SerialOld GC Combination
   367: Remove the Pack200 Tools and API
   368: Text Blocks (Second Preview)
   370: Foreign-Memory Access API (Incubator)

Thanks to everyone who contributed to JDK 14, whether by creating 
features or enhancements, logging  bugs, or downloading and testing the 
early-access builds.

OpenJDK 15 EA build 14 is now available at http://jdk.java.net/15 *
*

  * These early access, open source builds are provided under the GNU
    General Public License, version 2, with the Classpath Exception
    <http://openjdk.java.net/legal/gplv2+ce.html>.
  * Significant changes since the last availability email:
      o Build 13 - JDK-8238555
        <https://bugs.openjdk.java.net/browse/JDK-8238555>: Allow
        Initialization of SunPKCS11 with NSS when there are external
        FIPS modules in the NSSDB
      o Build 10 - JDK-8237776
        <https://bugs.openjdk.java.net/browse/JDK-8237776>: Shenandoah:
        Wrong result with Lucene test
          + Reported by Apache Lucene.
      o Build 9 - JDK-8222793
        <https://bugs.openjdk.java.net/browse/JDK-8222793>: Javadoc tool
        ignores "-locale" param and uses default locale for all messages
        and texts
          + Reported by Apache Lucene.

Project Metropolis Early-Access Builds - Build 14-metropolis+1-17 
<http://jdk.java.net/metropolis/> (2020/3/5)

  * These builds are intended for developers looking to test and provide
    feedback on using /Graal,/ in form of native library
    /(libjvmcicompiler.so)/, instead of C2 as HotSpot high optimizing
    JIT compiler.
  * These early-access builds are provided under the GNU General Public
    License, version 2, with the Classpath Exception
    <http://openjdk.java.net/legal/gplv2+ce.html>.
  * Please send feedback via e-mail to met...@op...
    <mailto:met...@op...>. To send e-mail to this
    address you must first subscribe to the mailing list
    <https://mail.openjdk.java.net/mailman/listinfo/metropolis-dev>.


Regards,
Rory

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004089.html
[2] https://openjdk.java.net/projects/jdk/14

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

Re: [Jython-dev] Jython 2.7.2rc1

[Pekka K. <pe...@ik...>]

H,

JAVA_OPTS seems to work pretty well in our case. Somewhat unfortunate
that value that works with Java 11 causes and error with Java 8 and we
thus need to set it conditionally before test execution starts.

Console encodings are hard. Just using UTF-8 would be a good choice,
that's what CPython nowadays does on Windows as well. I hope this
insn't changed in future Jython 2.7.x releases, though. It would be
quite badly backwards incompatible change.

Do you have plans when Jython 2.7.2 final would be released?

Cheers,
    .peke

pe 13. maalisk. 2020 klo 22.24 Jeff Allen (ja...@fa...) kirjoitti:
>
> Thanks for testing that, and for the feedback (especially as it's not a blocker).
>
> It may help to look at where we test violating accessibility rules deliberately. There we prepare the ground like this: https://hg.python.org/jython/file/v2.7.2rc1/Lib/test/test_java_visibility.py#l240 . Note also that Jython respects the environment variable JAVA_OPTS, see https://github.com/jythontools/jython/issues/171#issuecomment-598889263.
>
> Console encoding has been such a pain. I spent a long time getting it as "right" as possible, even for Greek and Chinese, but at the expense of some buffering that proved unacceptable later. ISTR the solution to that partly undid the complicated layer-cake I'd built. I'm pretty sure there's a mistake here too involving multiple system states.
>
> If I touch this again, console encoding will be fixed at utf-8 as far as Python knows and Java will translate to whatever system encoding it would use for strings. (At least, ... if that can be made satisfactory for users.) Thanks for your tolerance!
>
> Jeff Allen
>
> On 12/03/2020 11:22, Pekka Klärck wrote:
>
> Hi,
>
> We run Robot Framework's
> (https://github.com/robotframework/robotframework/) acceptance tests
> with 2.7.2rc1 both on Linux and Windows with Java 8 and results look
> very good. On Linux there were no failures and on Windows the only
> regression we encountered was change to `sys.stdxxx.encoding` in some
> special cases (https://bugs.jython.org/issue2868). I personally don't
> consider that a release blocker as the bug only occurs if outputs are
> redirected and we could argue that the value has always been wrong.
> With Python 2 the encoding is `None` in this case and with Python 3
> you get the encoding of the created file.
>
> We also run tests with Java 11, but due to illegal reflective access
> warnings logged to the console
> (https://github.com/jythontools/jython/issues/171) all tests
> validating console output fail and it's hard to tell are there real
> failures. Being able to disable these warnings would be great but I
> wouldn't post-pone the great looking release due to that.
>
> Cheers,
>     .peke
>
> to 5. maalisk. 2020 klo 22.12 Jeff Allen (ja...@fa...) kirjoitti:
>
> Now published. See: https://www.jython.org/download
>
> Are we all content for this to go out with our names on it? I've tried
> to arrange we make only safe changes between beta and rc, but it would
> be good to try it on as many platforms as we have amongst us.
>
> I built and it on Windows 10 and ran on Java 8 and 11 there. I also
> downloaded (the -install version) on Ubuntu with Java 11.
>
> How long an interval would you like? Precedents run from 2 days to we're
> still waiting, but I was thinking a week or two. Then I might try
> migrating to GitHub as we have said previously that we would.
>
> The CI does a good job, but of course does not install the way a user might.
>
> Jeff Allen
>
> On 02/03/2020 08:23, Jeff Allen wrote:
>
> On 23/02/2020 21:50, Jeff Allen wrote:
>
> It's beginning to look like we might be ready for a release
> candidate. Does anyone object? Have I missed a treasured patch?
>
> ...
>
> Bit busy this week, so probably this will be late in the week, and
> appear over next weekend.
>
> As we were all content, Jython 2.7.2rc1 is now staged at:
>
> https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar
>
>
> Other 3 jars at corresponding URLs. This this is the temporary
> location, "pre-publication", although publicly accessible.
>
> Jeff
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>


-- 
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Jython-dev] __pyclasspath__ not expanded in __file__

[Niemann, H. <har...@si...>]

Hello!

I have written a python program using the graphics library pygal.

There is one module of that library that tries to find a resource file like this
                    css = os.path.join(
                        os.path.dirname(__file__), 'css', css)
This works fine with (c) Python, this works fine with jython.exe (version 2.7.0, if that matters).
But (because of some company standard) the main program of my application is a java class, starting the jython interpreter like this:

                               PythonInterpreter.initialize(null, null, argv.toArray(new String[0]));

                               PythonInterpreter py;
                               py = new PythonInterpreter();

                               //exec
                               py.exec("import icmgen_py");

                               PyObject ret;
                               ret = py.eval("icmgen_py.main()");

To make things even more complicated, the java and python source is packed into one exe with launch4j.
But if I run my application from this launch4j executable, __file__ expands to
__pyclasspath__/pygal/svg.py

Why does jython have proper __file__ values if started with jython.exe, but does not expand __pyclasspath__ to the real (probably temporary root) directory if run from a java class like above?

Any ideas?

With best regards
Hartmut Niemann

Re: [Jython-dev] Jython 2.7.2rc1

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

Thanks for testing that, and for the feedback (especially as it's not a 
blocker).

It may help to look at where we test violating accessibility rules 
deliberately. There we prepare the ground like this: 
https://hg.python.org/jython/file/v2.7.2rc1/Lib/test/test_java_visibility.py#l240 
. Note also that Jython respects the environment variable JAVA_OPTS, see 
https://github.com/jythontools/jython/issues/171#issuecomment-598889263.

Console encoding has been such a pain. I spent a long time getting it as 
"right" as possible, even for Greek and Chinese, but at the expense of 
some buffering that proved unacceptable later. ISTR the solution to that 
partly undid the complicated layer-cake I'd built. I'm pretty sure 
there's a mistake here too involving multiple system states.

If I touch this again, console encoding will be fixed at utf-8 as far as 
Python knows and Java will translate to whatever system encoding it 
would use for strings. (At least, ... if that can be made satisfactory 
for users.) Thanks for your tolerance!

Jeff Allen

On 12/03/2020 11:22, Pekka Klärck wrote:
> Hi,
>
> We run Robot Framework's
> (https://github.com/robotframework/robotframework/) acceptance tests
> with 2.7.2rc1 both on Linux and Windows with Java 8 and results look
> very good. On Linux there were no failures and on Windows the only
> regression we encountered was change to `sys.stdxxx.encoding` in some
> special cases (https://bugs.jython.org/issue2868). I personally don't
> consider that a release blocker as the bug only occurs if outputs are
> redirected and we could argue that the value has always been wrong.
> With Python 2 the encoding is `None` in this case and with Python 3
> you get the encoding of the created file.
>
> We also run tests with Java 11, but due to illegal reflective access
> warnings logged to the console
> (https://github.com/jythontools/jython/issues/171) all tests
> validating console output fail and it's hard to tell are there real
> failures. Being able to disable these warnings would be great but I
> wouldn't post-pone the great looking release due to that.
>
> Cheers,
>      .peke
>
> to 5. maalisk. 2020 klo 22.12 Jeff Allen (ja...@fa...) kirjoitti:
>> Now published. See: https://www.jython.org/download
>>
>> Are we all content for this to go out with our names on it? I've tried
>> to arrange we make only safe changes between beta and rc, but it would
>> be good to try it on as many platforms as we have amongst us.
>>
>> I built and it on Windows 10 and ran on Java 8 and 11 there. I also
>> downloaded (the -install version) on Ubuntu with Java 11.
>>
>> How long an interval would you like? Precedents run from 2 days to we're
>> still waiting, but I was thinking a week or two. Then I might try
>> migrating to GitHub as we have said previously that we would.
>>
>> The CI does a good job, but of course does not install the way a user might.
>>
>> Jeff Allen
>>
>> On 02/03/2020 08:23, Jeff Allen wrote:
>>> On 23/02/2020 21:50, Jeff Allen wrote:
>>>> It's beginning to look like we might be ready for a release
>>>> candidate. Does anyone object? Have I missed a treasured patch?
>>> ...
>>>> Bit busy this week, so probably this will be late in the week, and
>>>> appear over next weekend.
>>>>
>>> As we were all content, Jython 2.7.2rc1 is now staged at:
>>>
>>> https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar
>>>
>>>
>>> Other 3 jars at corresponding URLs. This this is the temporary
>>> location, "pre-publication", although publicly accessible.
>>>
>>> Jeff
>>>
>>
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>

[Jython-dev] Summary of Jython tracker Issues

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

ACTIVITY SUMMARY (2020-03-06 - 2020-03-13)
Jython tracker at https://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     332 ( +2)
  closed  2484 ( +0)
  total   2816 ( +2)

Open issues with patches: 22   


Issues opened (2)
=================

#2868: Value of `sys.stdout.encoding` changed in some cases on Window
https://bugs.jython.org/issue2868  opened by pekka.klarck

#2870: PrePy.getJarFileNameFromURL fails hard when Jython jar is embe
https://bugs.jython.org/issue2870  opened by maku



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

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2792: Failures in test_import_jy from Java 13
https://bugs.jython.org/issue2792

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790

#2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7
https://bugs.jython.org/issue2770

#2760: How to call procedure with use zxjdbc and get back OUT paramet
https://bugs.jython.org/issue2760

#2754: Failure in Py.initProxy for class not at module level
https://bugs.jython.org/issue2754

#2752: Allow Python functions to be used as a java.lang.FunctionalInt
https://bugs.jython.org/issue2752

#2750: Make PyFunction implement java.util.concurrent.Callable<PyObje
https://bugs.jython.org/issue2750

#2734: Re-work package scanning and cache for modules
https://bugs.jython.org/issue2734

#2723: Unusual behavior in SimpleCookie when '=' and '@'  is used in 
https://bugs.jython.org/issue2723

#2722: run-time issue while trying to reach external endpoint (Weathe
https://bugs.jython.org/issue2722



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

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

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

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

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

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

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

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

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

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

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

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336

Re: [Jython-dev] Jython 2.7.2rc1

[Pekka K. <pe...@ik...>]

Hi,

We run Robot Framework's
(https://github.com/robotframework/robotframework/) acceptance tests
with 2.7.2rc1 both on Linux and Windows with Java 8 and results look
very good. On Linux there were no failures and on Windows the only
regression we encountered was change to `sys.stdxxx.encoding` in some
special cases (https://bugs.jython.org/issue2868). I personally don't
consider that a release blocker as the bug only occurs if outputs are
redirected and we could argue that the value has always been wrong.
With Python 2 the encoding is `None` in this case and with Python 3
you get the encoding of the created file.

We also run tests with Java 11, but due to illegal reflective access
warnings logged to the console
(https://github.com/jythontools/jython/issues/171) all tests
validating console output fail and it's hard to tell are there real
failures. Being able to disable these warnings would be great but I
wouldn't post-pone the great looking release due to that.

Cheers,
    .peke

to 5. maalisk. 2020 klo 22.12 Jeff Allen (ja...@fa...) kirjoitti:
>
> Now published. See: https://www.jython.org/download
>
> Are we all content for this to go out with our names on it? I've tried
> to arrange we make only safe changes between beta and rc, but it would
> be good to try it on as many platforms as we have amongst us.
>
> I built and it on Windows 10 and ran on Java 8 and 11 there. I also
> downloaded (the -install version) on Ubuntu with Java 11.
>
> How long an interval would you like? Precedents run from 2 days to we're
> still waiting, but I was thinking a week or two. Then I might try
> migrating to GitHub as we have said previously that we would.
>
> The CI does a good job, but of course does not install the way a user might.
>
> Jeff Allen
>
> On 02/03/2020 08:23, Jeff Allen wrote:
> > On 23/02/2020 21:50, Jeff Allen wrote:
> >> It's beginning to look like we might be ready for a release
> >> candidate. Does anyone object? Have I missed a treasured patch?
> > ...
> >> Bit busy this week, so probably this will be late in the week, and
> >> appear over next weekend.
> >>
> > As we were all content, Jython 2.7.2rc1 is now staged at:
> >
> > https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar
> >
> >
> > Other 3 jars at corresponding URLs. This this is the temporary
> > location, "pre-publication", although publicly accessible.
> >
> > Jeff
> >
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev



-- 
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Jython-dev] Summary of Jython tracker Issues

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

ACTIVITY SUMMARY (2020-02-28 - 2020-03-06)
Jython tracker at https://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     330 ( -1)
  closed  2484 ( +3)
  total   2814 ( +2)

Open issues with patches: 22   


Issues opened (2)
=================

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864  opened by rses

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866  opened by nfalliere



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

#2866: Interface default methods disregarded by the method resolver
https://bugs.jython.org/issue2866

#2864: Importing second instance of httplib causes an error
https://bugs.jython.org/issue2864

#2854: from module import * leads to wild goose chase
https://bugs.jython.org/issue2854

#2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows
https://bugs.jython.org/issue2798

#2794: invocation_tests.py missing from modjy tests
https://bugs.jython.org/issue2794

#2792: Failures in test_import_jy from Java 13
https://bugs.jython.org/issue2792

#2790: Equivalent signal handlers do not test equal using ==
https://bugs.jython.org/issue2790

#2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7
https://bugs.jython.org/issue2770

#2760: How to call procedure with use zxjdbc and get back OUT paramet
https://bugs.jython.org/issue2760

#2754: Failure in Py.initProxy for class not at module level
https://bugs.jython.org/issue2754

#2752: Allow Python functions to be used as a java.lang.FunctionalInt
https://bugs.jython.org/issue2752

#2750: Make PyFunction implement java.util.concurrent.Callable<PyObje
https://bugs.jython.org/issue2750

#2734: Re-work package scanning and cache for modules
https://bugs.jython.org/issue2734

#2723: Unusual behavior in SimpleCookie when '=' and '@'  is used in 
https://bugs.jython.org/issue2723

#2722: run-time issue while trying to reach external endpoint (Weathe
https://bugs.jython.org/issue2722



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

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

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

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

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

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

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

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

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

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

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

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
https://bugs.jython.org/issue1741

#1646: Proxy getInterface not change for more PyObject
https://bugs.jython.org/issue1646

#1612: array.array should use specialized bulk operations to initiali
https://bugs.jython.org/issue1612

#1435: traceback doesn't include Java stack trace in user functions
https://bugs.jython.org/issue1435

#1336: PyDeque should likely subclass PySequence
https://bugs.jython.org/issue1336



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

#2699: Implement PyFile_IncUseCount/PyFile_DecUseCount (?)
https://bugs.jython.org/issue2699  closed by stefan.richthofer

Re: [Jython-dev] Jython 2.7.2rc1

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

Thanks for testing those combinations, James. I was not as thorough with 
my Linux test.

When I'm using others' JARs, I usually find this is the page I want, 
with the next stop being "Browse" to get the JAR, the source and the 
checksum. If you're just citing it as a dependency, this page is good as 
it gives you fragments to paste.

Jeff Allen

On 05/03/2020 22:19, James Mudd wrote:
> Hi Jeff
>
> Firstly thanks for all your work on this. I have has a look at the rc 
> on linux mint 19.3 (5.3.0-40 kernel) and it seems to work great. I 
> tried the stand-alone and installer, both worked as expected. I also 
> tried installing packages with pip which worked. I tried using the 
> slim version in a quick demo app and it also worked. The regression 
> tests also passed for me. So while I can't claim to have done deep 
> testing I, have at least kicked the tyres on all the versions and they 
> look good to me.
>
> I think a week is enough time for people to have a look, but i'm happy 
> to go for a release.
>
> Quick note on the website, currently the download links go to the page 
> rather than the download directly. I'm not sure which is better so 
> just though id point it out to see if there are any opinions.
>
> Thanks again for your work.
>
> James Mudd
>
>
> On Thu, 5 Mar 2020 at 20:12, Jeff Allen <ja...@fa... 
> <mailto:ja...@fa...>> wrote:
>
>     Now published. See: https://www.jython.org/download
>
>     Are we all content for this to go out with our names on it? I've
>     tried
>     to arrange we make only safe changes between beta and rc, but it
>     would
>     be good to try it on as many platforms as we have amongst us.
>
>     I built and it on Windows 10 and ran on Java 8 and 11 there. I also
>     downloaded (the -install version) on Ubuntu with Java 11.
>
>     How long an interval would you like? Precedents run from 2 days to
>     we're
>     still waiting, but I was thinking a week or two. Then I might try
>     migrating to GitHub as we have said previously that we would.
>
>     The CI does a good job, but of course does not install the way a
>     user might.
>
>     Jeff Allen
>
>     On 02/03/2020 08:23, Jeff Allen wrote:
>     > On 23/02/2020 21:50, Jeff Allen wrote:
>     >> It's beginning to look like we might be ready for a release
>     >> candidate. Does anyone object? Have I missed a treasured patch?
>     > ...
>     >> Bit busy this week, so probably this will be late in the week, and
>     >> appear over next weekend.
>     >>
>     > As we were all content, Jython 2.7.2rc1 is now staged at:
>     >
>     >
>     https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar
>
>     >
>     >
>     > Other 3 jars at corresponding URLs. This this is the temporary
>     > location, "pre-publication", although publicly accessible.
>     >
>     > Jeff
>     >
>
>
>     _______________________________________________
>     Jython-dev mailing list
>     Jyt...@li...
>     <mailto:Jyt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Support for interface default methods when selecting an overloaded method

[Nicolas F. <ni...@pn...>]

Jeff,

Thanks for your response. I did file a bug here:
https://bugs.jython.org/issue2866
Unfortunately, I'm afraid I don't have any bandwidth to look into the
details of the projects and submit a patch atm :S

*> working on a 3.x*
AWESOME! For some reason, I thought support for 3.0 was a long lost dream,
I'm super excited to read that Python 3 support is in the works!

Best regards,
--
Nicolas Falliere (ni...@pn...)
JEB Decompiler, Founder and Architect
PNF Software <https://www.pnfsoftware.com/> | Follow us on Twitter
<https://twitter.com/jebdec> | Join us on Slack
<https://www.pnfsoftware.com/chat> | Bulletin Board
<https://www.pnfsoftware.com/forum>


On Thu, Mar 5, 2020 at 11:59 AM Jeff Allen <ja...@fa...> wrote:

> Thanks for trying the RC.
>
> Had it worked, it would have been luck. It has crossed my mind that it
> ought to be a feature, but we haven't attempted to add it. I haven't even
> thought about how default is implemented in Java.
>
> You could raise it as a bug (feature request) on bugs.jython.org. You
> could even submit a patch. (The logic of method resolution is fairly
> complicated.) There will, I think, be a 2.7.3, and if there isn't, it will
> be because we're working on a 3.x. One of them should have this if it can
> be implemented at all.
>
> Jeff Allen
>
> On 05/03/2020 06:30, Nicolas Falliere wrote:
>
> Hello Jython Dev Team,
>
> Per
> https://www.jython.org/jython-old-sites/archive/221/archive/22/userguide.html#overloaded-java-method-signatures:
> *"Java methods are allowed to be overloaded for different signatures
> (types and number of arguments). When different versions of the method
> differ in the number of arguments that they expect, the appropriate method
> can be easily determined from the number of arguments passed to the
> method."*
>
> With Jyhon 2.7 (2.7.1, and the current RC of 2.7.2 as well), this works
> fine for regular class methods, eg:
> class A {
>   void f(int a) {
>     return a + 1;
>   }
>   void f(int a, int b) {
>     return a+b;
>   }
> }
>
> in Jython:
> A().f(4)     # will select the proper overload
> A().f(1, 2)  # will select the proper overload
>
> However, for interfaces:
> interface I {
>   default void f(int a) {
>     return f(a, 1);
>   }
>   void f(int a, int b);
> }
> class A implements I {
>   void f(int a, int b) {
>     return a+b;
>   }
> }
>
> in Jython:
> x = someMethodReturningAnObjectImplementingI()
> x.f(4)     # fail, complains that method should receive 2 args
>
> So it looks like default methods, a language addition of Java 8, may not
> be seen by the Jython interpreter. Is that the case, or am I doing
> something wrong? In the former case, any chance to support that in a coming
> release?
>
> Thank you & Best regards,
> --
> Nicolas Falliere (ni...@pn...)
> JEB Decompiler, Founder and Architect
> PNF Software <https://www.pnfsoftware.com/> | Follow us on Twitter
> <https://twitter.com/jebdec> | Join us on Slack
> <https://www.pnfsoftware.com/chat> | Bulletin Board
> <https://www.pnfsoftware.com/forum>
>
>
> _______________________________________________
> Jython-dev mailing lis...@li...://lists.sourceforge.net/lists/listinfo/jython-dev
>
>

Re: [Jython-dev] Jython 2.7.2rc1

[James M. <jam...@gm...>]

Hi Jeff

Firstly thanks for all your work on this. I have has a look at the rc on
linux mint 19.3 (5.3.0-40 kernel) and it seems to work great. I tried the
stand-alone and installer, both worked as expected. I also tried installing
packages with pip which worked. I tried using the slim version in a quick
demo app and it also worked. The regression tests also passed for me. So
while I can't claim to have done deep testing I, have at least kicked the
tyres on all the versions and they look good to me.

I think a week is enough time for people to have a look, but i'm happy to
go for a release.

Quick note on the website, currently the download links go to the page
rather than the download directly. I'm not sure which is better so just
though id point it out to see if there are any opinions.

Thanks again for your work.

James Mudd


On Thu, 5 Mar 2020 at 20:12, Jeff Allen <ja...@fa...> wrote:

> Now published. See: https://www.jython.org/download
>
> Are we all content for this to go out with our names on it? I've tried
> to arrange we make only safe changes between beta and rc, but it would
> be good to try it on as many platforms as we have amongst us.
>
> I built and it on Windows 10 and ran on Java 8 and 11 there. I also
> downloaded (the -install version) on Ubuntu with Java 11.
>
> How long an interval would you like? Precedents run from 2 days to we're
> still waiting, but I was thinking a week or two. Then I might try
> migrating to GitHub as we have said previously that we would.
>
> The CI does a good job, but of course does not install the way a user
> might.
>
> Jeff Allen
>
> On 02/03/2020 08:23, Jeff Allen wrote:
> > On 23/02/2020 21:50, Jeff Allen wrote:
> >> It's beginning to look like we might be ready for a release
> >> candidate. Does anyone object? Have I missed a treasured patch?
> > ...
> >> Bit busy this week, so probably this will be late in the week, and
> >> appear over next weekend.
> >>
> > As we were all content, Jython 2.7.2rc1 is now staged at:
> >
> >
> https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar
> >
> >
> > Other 3 jars at corresponding URLs. This this is the temporary
> > location, "pre-publication", although publicly accessible.
> >
> > Jeff
> >
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Jython 2.7.2rc1

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

Now published. See: https://www.jython.org/download

Are we all content for this to go out with our names on it? I've tried 
to arrange we make only safe changes between beta and rc, but it would 
be good to try it on as many platforms as we have amongst us.

I built and it on Windows 10 and ran on Java 8 and 11 there. I also 
downloaded (the -install version) on Ubuntu with Java 11.

How long an interval would you like? Precedents run from 2 days to we're 
still waiting, but I was thinking a week or two. Then I might try 
migrating to GitHub as we have said previously that we would.

The CI does a good job, but of course does not install the way a user might.

Jeff Allen

On 02/03/2020 08:23, Jeff Allen wrote:
> On 23/02/2020 21:50, Jeff Allen wrote:
>> It's beginning to look like we might be ready for a release 
>> candidate. Does anyone object? Have I missed a treasured patch?
> ...
>> Bit busy this week, so probably this will be late in the week, and 
>> appear over next weekend.
>>
> As we were all content, Jython 2.7.2rc1 is now staged at:
>
> https://oss.sonatype.org/service/local/repo_groups/staging/content/org/python/jython-installer/2.7.2rc1/jython-installer-2.7.2rc1.jar 
>
>
> Other 3 jars at corresponding URLs. This this is the temporary 
> location, "pre-publication", although publicly accessible.
>
> Jeff
>

Re: [Jython-dev] Support for interface default methods when selecting an overloaded method

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

Thanks for trying the RC.

Had it worked, it would have been luck. It has crossed my mind that it 
ought to be a feature, but we haven't attempted to add it. I haven't 
even thought about how default is implemented in Java.

You could raise it as a bug (feature request) on bugs.jython.org. You 
could even submit a patch. (The logic of method resolution is fairly 
complicated.) There will, I think, be a 2.7.3, and if there isn't, it 
will be because we're working on a 3.x. One of them should have this if 
it can be implemented at all.

Jeff Allen

On 05/03/2020 06:30, Nicolas Falliere wrote:
> Hello Jython Dev Team,
>
> Per 
> https://www.jython.org/jython-old-sites/archive/221/archive/22/userguide.html#overloaded-java-method-signatures: 
> /"Java methods are allowed to be overloaded for different signatures 
> (types and number of arguments). When different versions of the method 
> differ in the number of arguments that they expect, the appropriate 
> method can be easily determined from the number of arguments passed to 
> the method."/
>
> With Jyhon 2.7 (2.7.1, and the current RC of 2.7.2 as well), this 
> works fine for regular class methods, eg:
> class A {
>   void f(int a) {
>     return a + 1;
>   }
>   void f(int a, int b) {
>     return a+b;
>   }
> }
>
> in Jython:
> A().f(4)     # will select the proper overload
> A().f(1, 2)  # will select the proper overload
>
> However, for interfaces:
> interface I {
>   default void f(int a) {
>     return f(a, 1);
>   }
>   void f(int a, int b);
> }
> class A implements I {
>   void f(int a, int b) {
>     return a+b;
>   }
> }
>
> in Jython:
> x = someMethodReturningAnObjectImplementingI()
> x.f(4)     # fail, complains that method should receive 2 args
>
> So it looks like default methods, a language addition of Java 8, may 
> not be seen by the Jython interpreter. Is that the case, or am I doing 
> something wrong? In the former case, any chance to support that in a 
> coming release?
>
> Thank you & Best regards,
> --
> Nicolas Falliere (ni...@pn... <mailto:ni...@pn...>)
> JEB Decompiler, Founder and Architect
> PNF Software <https://www.pnfsoftware.com/>| Follow us on Twitter 
> <https://twitter.com/jebdec> | Join us on Slack 
> <https://www.pnfsoftware.com/chat> | Bulletin Board
> <https://www.pnfsoftware.com/forum>
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev