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

RE: [Jython-dev] Re: Problem calling protected method

[Garcia, M. <mg...@Bu...>]

Thanks for your advice.  For my purposes (writing an EJB test client) I
think I'll just leave the respectJavaAccessibility to false even though this
may not be the preferred technique.  

In the future I'll try to keep the setting to true by using this technique.
Can I find any documentation at SourceForge pertaining to Jython's handling
of private and protected members?

thanks again.
sincerely,
Michael


-----Original Message-----
From: Robert W. Bill
To: jyt...@li...
Cc: Garcia, Michael
Sent: 1/8/01 6:53 PM
Subject: Re: [Jython-dev] Re: Problem calling protected method


[Adam Burke]
> You are very much on the right track.
> 
> This is an FAQ:
  <snip>
>
> If you want to leave respectJavaAccessibility = true, could you
inherit
> from java.util.Calendar and expose the functionality that way?  It may
> require adding a public method that simply does
>  return self.x() 

Or use the lazy way, avoid the abstract class, and inherit from
GregorianCalendar, i.e.-

>>>from java.util import GregorianCalendar
>>>class myTime(GregorianCalendar):
...	def ms(self):
...		return self.getTimeInMillis()
...
>>>t = test()
>>>t.ms()
978997877490L
>>>

If you still have respectJavaAccessibility = true, you can confirm
protected status with:

>>>g = GregorianCalendar()
>>>g.getTimeInMillis()
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: getTimeInMillis


(I actually sent this earlier, but received an service unavailable
error- 
I apologize if I'm repeating myself...again :)

cheers,
-Robert

Re: [Jython-dev] Re: Problem calling protected method

[Robert W. B. <rb...@di...>]

[Adam Burke]
> You are very much on the right track.
> 
> This is an FAQ:
  <snip>
>
> If you want to leave respectJavaAccessibility = true, could you inherit
> from java.util.Calendar and expose the functionality that way?  It may
> require adding a public method that simply does
>  return self.x() 

Or use the lazy way, avoid the abstract class, and inherit from
GregorianCalendar, i.e.-

>>>from java.util import GregorianCalendar
>>>class myTime(GregorianCalendar):
...	def ms(self):
...		return self.getTimeInMillis()
...
>>>t = test()
>>>t.ms()
978997877490L
>>>

If you still have respectJavaAccessibility = true, you can confirm
protected status with:

>>>g = GregorianCalendar()
>>>g.getTimeInMillis()
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: getTimeInMillis


(I actually sent this earlier, but received an service unavailable error- 
I apologize if I'm repeating myself...again :)

cheers,
-Robert

[Jython-dev] Re: Problem calling protected method

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

You are very much on the right track.

This is an FAQ:

FAQ index:
http://jython.sourceforge.net/cgi-bin/faqw.py?req=index



3.3. I'm trying to execute a 'protected' or 'private' Java Instance
Method
or attribute in a Java package. How can I get access?

By default, as in Java, these methods are protected from external
access, but there may be reasons, such as test scaffolding
scripts, that this feature is not wanted. In the [jython home]/registry
file: 

  # Setting this to false will allow Jython to provide access to
  # non-public fields, methods, and constructors of Java objects.
  python.security.respectJavaAccessibility = false

---

If you want to leave respectJavaAccessibility = true, could you inherit
from java.util.Calendar and expose the functionality that way?  It may
require adding a public method that simply does
 return self.x() 

Hope this helps

Adam Burke
www.gbst.com

Garcia, Michael wrote:
> 
> I am trying to call a protected method in the java.util.Calendar class
> and am getting:
> 
> >>> l = cal.getTimeInMillis()
> Traceback (innermost last):
>   File "<console>", line 1, in ?
> AttributeError: getTimeInMillis
> 
> Why am I getting this AttributeError?  I suspect that it has to do with
> python.security.respectJavaAccessibility = true.  Do I have to set it to
> false to get this to work or am I missing something so that I can leave
> respectJavaAccessibility set to true?
> 
> thank you,
> Mick

[Jython-dev] Problem calling protected method

[Garcia, M. <mg...@Bu...>]

I am trying to call a protected method in the java.util.Calendar class and
am getting:

>>> l = cal.getTimeInMillis()
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: getTimeInMillis

Why am I getting this AttributeError?  I suspect that it has to do with
python.security.respectJavaAccessibility = true.  Do I have to set it to
false to get this to work or am I missing something so that I can leave
respectJavaAccessibility set to true?

thank you,
Mick

Re: [Jython-dev] registry-file how is it handled?

[<bc...@wo...>]

On Mon, 8 Jan 2001 14:06:02 +0100, you wrote:

>Hello,
>I have a small question.
>A standard Jython installation uses some information from the Jython
>registry-file.
>If I embedd the Jython interpreter in a application, the registry file will
>might not be accessible any more.

Instead you can manually initialize the jython runtime by calling
PySystemState.initialize(preProperties, postProperties, argv):

- preProperties is useally System.getProperties().
- postProperties can be a java.util.Properties with your own 
  property values.
- argv will be copied to sys.argv

>So is the registryfile executed as a python script, 
>or is it read in as a java.util.Properties table?

Both registry files (<python.home>/registry & <user.home>/.jython) are
java.util.Properties files.

>Can I place Jython command in there?

No.

>Can I reread the registry file?

No. You can't meaningfully modify the sys.registry object either. After
the property files are read (and merged with Properties arguments to
PySystemState.initialize()) the static fields in org.python.core.Options
is initialized. The rest of the jython runtime are looking at these
fields when it needs some configuration information.

>if yes How can I do that?
>
>Assume I have multiple interpreter embedded in one JVM. Do they all share
>the same registry information?

They all share the static values of the org.python.core.Options fields.

regards.
finn

[Jython-dev] registry-file how is it handled?

[Schmidmeier, A. <Arn...@si...>]

Hello,
I have a small question.
A standard Jython installation uses some information from the Jython
registry-file.
If I embedd the Jython interpreter in a application, the registry file will
might not be accessible any more.

So is the registryfile executed as a python script, 
or is it read in as a java.util.Properties table?

Can I place Jython command in there?

Can I reread the registry file?
if yes How can I do that?

Assume I have multiple interpreter embedded in one JVM. Do they all share
the same registry information?

Thanks
Arno Schmidmeier


***********************************************************************
*
***********************************************************************
Arno Schmidmeier
Sirius Software GmbH
Kolpingring 18
82041 Oberhaching
Tel. 	089/6136760		
E-Mail 	    Arn...@si...
Fax 	089/61367633		
Internet	    www.sirius-eos.com

Re: [Jython-dev] exec <file> in <dictionary>

[<bc...@wo...>]

[brian zimmer]

>I was trying to use the following syntax in Jython but I get an exception:
>
>>>> t = {}
>>>> exec open(filename) in t
>
>Traceback (innermost last):
>  File "install.py", line 381, in ?
>  File "install.py", line 47, in run
>  File "install.py", line 71, in detectComponents
>  File "install.py", line 89, in readProperties
>TypeError: exec: argument 1 must be string or code object
>
>This works in CPython and appears to be part of the spec:
>
>"The first expression should evaluate to either a string, an open file
>object, or a code object. ...  If it is an open file, the file is parsed
>until EOF and executed."
>
>http://python.org/doc/current/ref/exec.html

Yep, and jython should support this as well.

>Additionally, in CPython 2.0, if the file is closed it is re-opened and
>executed.

I can't reproduce this behaviour in CPython 2.0. Instead it appears that
CPython treats a closed file as an empty file (no exception is thrown).
Do you have an example that show that the file is reopened?

>Given this, I've enclosed a working diff which mimics the exact behaviour of
>CPython 2.0.

If I'm correct regarding the reopen thing, I would rather do something
like:

                if (fp.closed)
                    return;
                contents = fp.read().toString();

to avoid the "I/O operation on closed file" exception.

regards,
finn

[Jython-dev] exec <file> in <dictionary>

[brian z. <bz...@zi...>]

I was trying to use the following syntax in Jython but I get an exception:

>>> t = {}
>>> exec open(filename) in t

Traceback (innermost last):
  File "install.py", line 381, in ?
  File "install.py", line 47, in run
  File "install.py", line 71, in detectComponents
  File "install.py", line 89, in readProperties
TypeError: exec: argument 1 must be string or code object

This works in CPython and appears to be part of the spec:

"The first expression should evaluate to either a string, an open file
object, or a code object. ...  If it is an open file, the file is parsed
until EOF and executed."

http://python.org/doc/current/ref/exec.html

Additionally, in CPython 2.0, if the file is closed it is re-opened and
executed.

I also tested whether StringIO could be substited for a file and it appears
to fail:

>>> from StringIO import StringIO
>>> s = StringIO("a = 'x'")
>>> s
<StringIO.StringIO instance at 007E1C1C>
>>> t = {}
>>> exec s in t
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: exec 1st arg must be string, code or file object
>>>

Given this, I've enclosed a working diff which mimics the exact behaviour of
CPython 2.0.

thanks,

brian

[Jython-dev] Static functions in jython classes

[Gurunath R. (EWU) <EW...@am...>]

Hi,
 I am developing a scripting interface and one major roadblock
to using Jython seems to be the lack of static functions in jython classes. It would be good if this can be incorporated in
future jython releases.
Thanks,
Guruunath R

 Gurunath R.
 (858) 332 6263
  

Re: [Jython-dev] Re: [Bug #127200] Incorrect code for method returning inner class instance.

[<bc...@wo...>]

>> I just hoped there were a better way. Does any know if there is?
>
>I have not tried this but is it not possible to achieve the same
>through the Class reflection methods:
> getClasses
> getDeclaredClasses
> and getDeclaringClass?
>They are all since 1.1 and seem at first sight to do the needed things.

Yes, the name of getDeclaringClass() will allow me to recreate a
compiler friendly version of the innerclass name. Thanks.

regards,
finn

Re: [Jython-dev] Re: [Bug #127200] Incorrect code for method returning inner class instance.

[Samuele P. <pe...@in...>]

Hi.

> I have made a patch which will retrieve the class as a resource and
> parse the bytecode to find the "InnerClasses" attributes. From the
> "InnerClasses" that correspond to this_class, I can get the outerclass
> and the innerclass names.
> 
> I just hoped there were a better way. Does any know if there is?

I have not tried this but is it not possible to achieve the same
through the Class reflection methods:
 getClasses
 getDeclaredClasses
 and getDeclaringClass?
They are all since 1.1 and seem at first sight to do the needed things.

regards, Samuele Pedroni.

Re: [Jython-dev] Jython glob/re modules

[<bc...@wo...>]

[Seshu Nimmala]

>However, since the glob module doesn't form part of jython.jar, how could this
>be supplied to user/customer (not that I'm intending, but just  curious to know!)

The usual way is by using some kind of installer (InstallShield, Wyse,
LiftOff, ...) and copy the required python modules to the custumer
computer. Perhaps you can also use jythonc to freeze the application
with the --deep option. All dependent modules will then be frozen
together with the application and can be placed in a .jar file.

regards,
finn

[Jython-dev] Re: [Bug #127200] Incorrect code for method returning inner class instance.

[<bc...@wo...>]

[In a bug report we got:]

>For example.  If jython class Log inherits javax.swing.text.PlainDocument
>we get this code:
>
>public javax.swing.text.AbstractDocument$AbstractElement 
>createDefaultRoot() {
>        return super.createDefaultRoot();

where the '$' in the inner class name confuses the java compiler in
JDK1.3. Does anyone know how we can get a more compiler friendly class
name (When replacing the '$' with a '.', even JDK1.3 is happy). Keep in
mind that a $ is valid (if somewhat unlikely) character in class names.

I have made a patch which will retrieve the class as a resource and
parse the bytecode to find the "InnerClasses" attributes. From the
"InnerClasses" that correspond to this_class, I can get the outerclass
and the innerclass names.

I just hoped there were a better way. Does any know if there is?

regards,
finn

Re: [Jython-dev] Jython glob/re modules

[Seshu N. <Ses...@sd...>]

Robert,

Thank you very much for suggesting more than one way to solve this issue.
As you rightly guessed,  I moved the jar file elsewhere and .py files in
installed lib directory are not seen by the Interpreter. Copying the lib files
(such as glob.py) into right location solved the problem!
Your code examples are really good to understand the issue.

However, since the glob module doesn't form part of jython.jar, how could this
be supplied to user/customer (not that I'm intending, but just  curious to know!)

Thanks,
Seshu
"Robert W. Bill" wrote:

> Seshu Nimmala wrote:
> > Thanks finn. I downloaded the latest jython-2.0b1 and it
> > imports the glob/re modules as stand-alone execution (at
> > command line).
> >
> > However, the glob module still cannot be imported when tried
> > as below in Java code:
> > Is there any special command to be used or something like
> > special setting for PYTHONPATH or someother env
> > variables to be used to run this Java source:
> > Any help will be appreciated.
> > Thanks.
> > __________________________________________
> > import org.python.util.PythonInterpreter;
> > import org.python.core.*;
> > import java.util.*;
> >
> > public class
> > PythonInterpreterTest{
> >   PythonInterpreter interp =
> >     new PythonInterpreter();
> >    public void test() throws PyException  {
> >     :
> >     interp.exec("import glob");   //Cannot import glob here
> >     interp.exec("files = glob.glob('*.java')");
> > }
> > }
> > __________________________________________________
>
> Hello  Seshu,
> I tried a slightly modified version of your code
> and it worked fine (in jython-2.0b1).  Here's what I used:
> ==========================================================
> import org.python.util.PythonInterpreter;
> import org.python.core.*;
>
> public class
> test{
>     public static void main(String[] args) throws PyException {
>         PythonInterpreter interp =
>             new PythonInterpreter();
>         interp.exec("import glob");
>         interp.exec("files = glob.glob('*.java')");
>         interp.exec("print  files");
>     }
> }
> ===========================================================
> When I run this I get the output:
> ['test.java']
>
> I'm curious what happens when you run something like this:
> ==========================================================
> import org.python.util.PythonInterpreter;
> import org.python.core.*;
>
> public class
> test{
>     public static void main(String[] args) throws PyException {
>         PythonInterpreter interp =
>             new PythonInterpreter();
>         interp.exec("import sys");
>         interp.exec("print sys.path");
>     }
> }
> ===============================================================
>
> For me, I get the following path, which is good because that is where
> glob.py is:
> ['.', '/usr/local/jython-2.0b1/Lib']
>
> This is just a guess, but I suspect that this path will be wrong for
> you.   Could you have moved jython.jar out of it's installation
> directory?  You can try running your test with-
> "java -Dpython.home=/path/to/jythondir test"
>
> You can guaruntee that this path is correct by initializing a sys.path
> list in your java file.  This example is from Finn Bock (tnx Finn for
> your amazing work)-
>
>     Properties props = new Properties();
>     props.setProperty("python.path", "/home/modules:scripts");
>     PySystemState.initialize(System.getProperties(), props,
>                                  new String[] {""});
>
> The value for python.path must follow the operating system conventions
> for the PATH environment var (':' separator for unix, ';' for windows)
>
> regards,
> Robert

Re: [Jython-dev] Jython glob/re modules

[Robert W. B. <rb...@di...>]

Seshu Nimmala wrote:
> Thanks finn. I downloaded the latest jython-2.0b1 and it
> imports the glob/re modules as stand-alone execution (at
> command line).
> 
> However, the glob module still cannot be imported when tried
> as below in Java code:
> Is there any special command to be used or something like
> special setting for PYTHONPATH or someother env
> variables to be used to run this Java source:
> Any help will be appreciated.
> Thanks.
> __________________________________________
> import org.python.util.PythonInterpreter;
> import org.python.core.*;
> import java.util.*;
> 
> public class
> PythonInterpreterTest{
>   PythonInterpreter interp =
>     new PythonInterpreter();
>    public void test() throws PyException  {
>     :
>     interp.exec("import glob");   //Cannot import glob here
>     interp.exec("files = glob.glob('*.java')");
> }
> }
> __________________________________________________

Hello  Seshu,
I tried a slightly modified version of your code
and it worked fine (in jython-2.0b1).  Here's what I used:
==========================================================
import org.python.util.PythonInterpreter;
import org.python.core.*;

public class
test{
    public static void main(String[] args) throws PyException {
	PythonInterpreter interp =
	    new PythonInterpreter();
	interp.exec("import glob");
	interp.exec("files = glob.glob('*.java')");
	interp.exec("print  files");
    }
}
===========================================================	
When I run this I get the output:
['test.java']

I'm curious what happens when you run something like this:
========================================================== 
import org.python.util.PythonInterpreter;
import org.python.core.*;

public class
test{
    public static void main(String[] args) throws PyException {
	PythonInterpreter interp =
	    new PythonInterpreter();
	interp.exec("import sys");
	interp.exec("print sys.path");
    }
}
===============================================================

For me, I get the following path, which is good because that is where
glob.py is:
['.', '/usr/local/jython-2.0b1/Lib']

This is just a guess, but I suspect that this path will be wrong for
you.   Could you have moved jython.jar out of it's installation
directory?  You can try running your test with- 
"java -Dpython.home=/path/to/jythondir test"

You can guaruntee that this path is correct by initializing a sys.path
list in your java file.  This example is from Finn Bock (tnx Finn for
your amazing work)- 
    
    Properties props = new Properties();
    props.setProperty("python.path", "/home/modules:scripts");
    PySystemState.initialize(System.getProperties(), props, 
                                 new String[] {""});

The value for python.path must follow the operating system conventions
for the PATH environment var (':' separator for unix, ';' for windows)

regards,
Robert

Re: [Jython-dev] Jython glob/re modules

[Seshu N. <ses...@sd...>]

Thanks finn. I downloaded the latest jython-2.0b1 and it
imports the glob/re modules as stand-alone execution (at
command line).

However, the glob module still cannot be imported when tried
as below in Java code:
Is there any special command to be used or something like
special setting for PYTHONPATH or someother env
variables to be used to run this Java source:
Any help will be appreciated.
Thanks.
__________________________________________
import org.python.util.PythonInterpreter;
import org.python.core.*;
import java.util.*;

public class
PythonInterpreterTest{
  PythonInterpreter interp =
    new PythonInterpreter();
   public void test() throws PyException  {
    :
    interp.exec("import glob");   //Cannot import glob here
    interp.exec("files = glob.glob('*.java')");
}
}
__________________________________________________

[Seshu Nimmala]

>I'm not able to import "glob" module or "re" module for use in jython.
>I'm using jython-2.0a2.
>Is it a bug or a current limitation?

It was a bug in alpha2. The re.py from CPython2.0 wasn't included in the
installer. It is fixed in beta1.

regards,
finn

>

Re: [Jython-dev] Jython glob/re modules

[<bc...@wo...>]

[Seshu Nimmala]

>I'm not able to import "glob" module or "re" module for use in jython.
>I'm using jython-2.0a2.
>Is it a bug or a current limitation?

It was a bug in alpha2. The re.py from CPython2.0 wasn't included in the
installer. It is fixed in beta1.

regards,
finn

RE: [Jython-dev] Jython glob/re modules

[Ivan K. <iv...@ko...>]

speaking of unsupported modules..
prior to the release of the final version of jython, it would be nice to
have a list of all of the supported modules. Also, it would be great to
somehow coordinate the integration/functionality/unit testing of those
modules, or at least to see a list of modules that have been or haven't been
tested.
Thanks,
_I

-----Original Message-----
From: jyt...@li...
[mailto:jyt...@li...]On Behalf Of Seshu
Nimmala
Sent: Wednesday, January 03, 2001 12:14 PM
To: jyt...@li...
Cc: ses...@sd...
Subject: [Jython-dev] Jython glob/re modules


Hi,
I'm not able to import "glob" module or "re" module for use in jython.
I'm using jython-2.0a2.
Is it a bug or a current limitation?
Thanks,
Seshu


_______________________________________________
Jython-dev mailing list
Jyt...@li...
http://lists.sourceforge.net/mailman/listinfo/jython-dev

RE: [Jython-dev] Jython glob/re modules

[Ivan K. <iv...@ko...>]

module "re" seems to be working fine for me. ("glob" is not working)
I'm using Jython 2.0 pre-alpha on java 1.3.0

_I

-----Original Message-----
From: jyt...@li...
[mailto:jyt...@li...]On Behalf Of Seshu
Nimmala
Sent: Wednesday, January 03, 2001 12:14 PM
To: jyt...@li...
Cc: ses...@sd...
Subject: [Jython-dev] Jython glob/re modules


Hi,
I'm not able to import "glob" module or "re" module for use in jython.
I'm using jython-2.0a2.
Is it a bug or a current limitation?
Thanks,
Seshu


_______________________________________________
Jython-dev mailing list
Jyt...@li...
http://lists.sourceforge.net/mailman/listinfo/jython-dev

[Jython-dev] Jython glob/re modules

[Seshu N. <ses...@sd...>]

Hi,
I'm not able to import "glob" module or "re" module for use in jython.
I'm using jython-2.0a2.
Is it a bug or a current limitation?
Thanks,
Seshu

Re: [Jython-dev] reloading...

[<bc...@wo...>]

On Sun, 31 Dec 2000 03:48:45 +0100, you wrote:

>I'm about to start working on some experimental support for reloading of
>java classes.
>The interface will be somehow different - as already discussed long time
>ago - to that for python modules.
>Now the required primitives are in place in the codebase, and the class name
>clash bug is fixed.
>
>    For the moment I imagine three levels/ways of support for reload
>These are illustrated in the form of some examples of usage (the interface
>is clearly not definitive):

This is just my initial thoughts.

>0)
>    import reload
>    reload.createLoadSet("XLS",['d:/exp','d:/exp2'])

Does this automaticly bind the XLS name in locals()? I would rather see
some kind of explicit binding:

   XLS = reload.createLoadSet("XLS",['d:/exp','d:/exp2'])

>    import XLS.com.xyz.utils.BlobReader
>    from XLS.com.xyz.utils import Blob
>
>    print XLS.com.xyz.utils.BlobWriter.getVersion()
>
>    reload(XLS)
>
>   # Blob still refers to the old/same version

Ofcourse it does. Users will be surprised at this, but that is
unavoidable. IMO it is more interesting what happen here:

    from XLS.com.xyz import utils
    b1 = utils.Blob()
    reload(XLS)
    b2 = utils.Blob() # would this Blob also be the old version?

If this will get the new version of Blob, I don't mind the explicit
reference to the XLS loadset in imports.

>    print XLS.com.xyz.utils.BlobWriter.getVersion() # refers to new version
>    # XLS.com.xyz.utils.BlobReader
>1)
>    import reload
>    xls =
>reload.createLoadSet('<anononymous>',['d:/exp','d:/exp2'],topExport=['com.xy
>z'])
>    # works only if com.xyz is not an existing package under the hierarchy
>    # controlled by the system package manager
>
>    print com.xyz.utils.BlobWriter.getVersion() # this works without
>prefixing with the load-set
>
>    xls.reload()

Similarly; Is it only com.xyz.__dict__ that is reloaded or is it also
and automaticly a locally bound utils package?

>   print com.xyz.utils.BlobWriter.getVersion() # new version
>2) # same as 1, but should work for packages that are also under control of
>the system package manager
>    # with that is not meant that we have reloading from classpath or
>sys.path
>    # but that package content could be splitted between a fixed part coming
>from classpath, sys.path
>    # and a reloadable one coming from a separated set of directories
>
>Clearly a possibility is to have all them together.
>0) I feel is the "more pythonic" being a load set some kind of package that
>can be reloaded as a whole.

That is my feeling too.

>It also the less confusing for the user.
>1) This has the big advantage that the code for the development/test phase
>and the final code contain the same imports.
>  Can be a bit more confusing.
>*)  Clearly the idea is that the reload.createLoadSet are idempotent. To
>have the "same" call in many modules
>  should report no error... Clearly at least one call should be issued
>before trying to import things from
>  the load-set.
>2) Is more complicated to implement and can be very confusing. I do not know
>wheter it's worth the effort.

IMO, it isn't worth it for the first effort.

>I think 0+1 make sense.

I would prefer just the 0 solution initially. As we (by that I mean I)
gain more experience with reloading, we can always add more ways.

regards,
finn

[Jython-dev] Jython is making my life too easy!!

[Mike G. <mgb...@rm...>]

Hi Jython developers, Happy New Year!!

I just wanted to drop a line and tell you what an awesome job you guys =
have done with Jython.  I use it on almost a daily basis for unit =
testing EJB clients, validating sql statements, and exploring API's.  It =
has really impacted my unit testing on the project I am working on =
because I can whip out a client with about 20 to 30 lines of code.  Once =
the release is made I'd like to use it to write production code and =
deploy the class files generated. =20
=20
Thank you for this great development tool and I wish you lots of =
prosperity in 2001.  We'll see you on the lists.

Sincerely,
Mike G.

Re: [Jython-dev] Re: java2 security support: remarks

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> [Samuele]
....
> >In Sun doc it is stated that the use of doPrivileged should be very
limited
> >and also the amount of code executed inside
> >such a privileged context should be limited too. The patch does something
> >very different using doPrivileged for every "jython function call" and
> >having the privileged region encompass the whole "call".
>
> I think (I'm not sure) that the advice SUN is giving only covers the
> doPrivileged method without an explicit AccessControlContext. The
> example SUM is supplying is that of a worker thread, and I assume that
> the complete work that the worker thread is about to perform should be
> executed with a doPrivileged call *with* explicit AccessControlContext.
(Just for general interest)
I think they intend that at some very specific places the thread code
uses doPriviled passing the needed (somewhere else captured) context.

> >a) A bad news about the patch is the perfomance cost of it:
> >On my machine with the patch in place the pystones number (using 50000
> >iters ) goes down from ~4950 to ~2900.
> >I do know very little about how to read pystone results: but this seems
to
> >me a "big" performance cost that is paid
> >globally.
> >[In any case I continue to list the "problems" of the patch, maybe there
is
> >a solution that I do not see, and I think some
> >remarks are of more general interest]
>
> I'm sure some optimizing is possible. OTOH, even a high performance hit
> is acceptable as long as it is only incurred in very controlled
> situations:
> - Only when running under a seurity manager, and
> - Only if specificly enabled with a property / jythonc option or
> - Only when using dynamicly compiled code through exec.
In general I agree with this.
But if we cannot limit this penalty only to the case of the real use
of dynamicly loaded code, I think we need a different approach.
I imagine that offering the feature this way - to fully trusted applications
running under  the plug-in - but at the price of this global performance
loss make few sense.

> >e) Given that our support should work in a general setup:
> > - The patch solves the problem of reducing the permissions back to the
ones
> >of the context of the code that used exec.
> >   So if the created code is called from a context with more permissions
it
> >cannot exploit any of these. That was the issue
> >   showed by my example.
> >-  On the other hand if the exec-created code is called from a context
with
> >less permissions, given doPrivileged
> >   definition, it will anyway run with the permissions of its creation
> >context.
>
> Yes, unfortunate; but I don't think it is a security problem. The high
> permission code that made the exec could just run the code itself.
> Still, it is bad design to run any code with too high permission.
I do not understand your comment.
For me that's a security problem because the users then *must* understand
the issue and deal with it.
I repeat
 > >   In general java2 security design avoids this kind of situation (but
gives
> >through doPrivileged a way to obtain this)
> >   because then the user during coding should explicitly think about the
> >possible security holes that this behaviour opens.
The situation that I imagine is the use of exec to create/define a function.
Then this function will always be executed with the permissions
of the creation (exec) context.
From my viewpoint that's bad.
In general - with java2 security - code in a protection domain that do not
have
the permission to do something cannot achieve that, even calling code
in another protection domain. The patch as it is breaks that in a too
broad way.

...
> >The constructor logic will do the following:
> >- if there is no security manager in place just define the class.
> >- if there is a security manager in place: define the class inside a
> >protection domain,
> > the permissions to grant will be computed this way:
> >
> > Only the permissions from the global set PermsCands for which
> >acc.checkPermission do not throw an exception
> > will be granted.
>
> Would this create a new ProtectionDomain for each dynamicly loaded
> class? What CodeSource would be used for the ProtectionDomain?
Yes and that's ugly too.I imagine that we will need to produce some
kind of fake URL, I have not studied that yet.

The problem is clear: the security api as it is is not well suited
to support the dynamic creation/loading of code/classes at runtime.
So we are not using it, we are hacking with it.

> >Clearly all this checks have a performance cost, especially when the
> >negative result exc is thrown.
> >The code can test wheter already AllPermission is ok to gain some speed
in
> >this case.
> >The assumption is that the set will not be that big and in any case the
cost
> >is local to the dynamic
> >creation of code. And zero if there is no security manager in place.
>
> That is good enough. Don't worry about the performance if the hit is
> only incurred when actually used.
>
> >So the permissions granted are all actually in place for the code that
> >issued the creation request.
>
> Yes, I think this is a safe way to store and later recreate the
> permissions of the code that wants to create code dynamicly. And yes,
> it's ugly <wink>.
Yes, really ugly <wink>, but if we do not find a solution for the problems
above
we will have to try this too.
Further, given that adapters are created lazily I imagine they will need
some special treatment. I think just putting them in jython runtime prot-dom
should be ok.

> ---------------------------------
>
> Only slightly releated: what would happen if an evil applet could
> somehow get hold of a PyProxy or PyObject (perhaps through
> Applet.getAppletContext().getApplet("foo") ) and then started making
> modification to the applet with __setattr__ and __setitem__. The evil
> applet cannot introduce new code into the "foo" applet, but if foo it
> trusted and is a large application, the evil applet may find enough
> usefull methods and functions to build an attack. I haven't tried this
> yet, it's just a scary thought.
A "secure" applet context impl should allow mutual access only between
applets that comes
from  the same code-source.
It should be checked if that's the case of sun plug-in. Not tried yet.
But reading the doc it seems to be the case.
The fact that for implementation reasons and python philosophy all member of
a python class are "public"
from java side is somehow a general "security" issue.

regards, Samuele Pedroni.

Re: [Jython-dev] ANN: First beta release of Jython-2.0

[Jim H. <hu...@pa...>]

From: "Finn Bock" <bc...@wo...>
> This beta release falls on the 3-year birthday of the first JPython
> beta.
>
>
http://mail.python.org/pipermail/jpython-interest/1997-December/000059.html
>
> What better time to say: Jim you're still da man.
>
> JPython have come a long way since then, but it is still your work, your
> code and your ideas that is behind it all. Thanks. I hope I haven't
> messed it up too badly since then.

Thanks for the credit, Finn.  When I left JPython almost two years ago I
underestimated how much support and development it still needed (especially
in jpythonc).  If you hadn't stepped forward and essentially taken over the
continuing development and user support, I think that JPython could easily
have faded from the world.

Instead, you managed to keep the development moving forward through a very
difficult time and are now poised to make what will arguably be the first
non-beta JPython/Jython release under a true open source license and
development model.  Thank you for keeping this project alive and kicking and
now ready to continue moving forward.

Happy New Year - Jim

Re: [Jython-dev] ANN: First beta release of Jython-2.0

[<bc...@wo...>]

I wrote:

>I am happy to announce the first beta release of Jython 2.0. 
>   http://jython.sourceforge.net/

And the CVS is tagged and ready for new commits. I hope we can release a
2.0 final in about 2 weeks.

This beta release falls on the 3-year birthday of the first JPython
beta.


http://mail.python.org/pipermail/jpython-interest/1997-December/000059.html

What better time to say: Jim you're still da man.

JPython have come a long way since then, but it is still your work, your
code and your ideas that is behind it all. Thanks. I hope I haven't
messed it up too badly since then.

Happy New Year 
finn