* Jython uses the following methods
* Usually used transparently
* *Sometimes* significant overhead because of boxing/unboxing
Use of overloaded methods
-What happens when you call
-Simplified use of closures
-* FIXME What do we mean by that?
-Under the hood - conversion
+* What happens when you call overloaded methods? How does Jython pick the one you want?
+* Sometimes the runtime picks wrong
+* Force it by using constructors from `java.lang` - `Boolean`, `Integer`, `Double`, etc
JSR-223: Scripting for the Java platform
+* Callbacks are commonly used in Java
+* Generally requires a fair amount of boilerplate code, even with anoymous classes
+* And generally you need to pass in some state
* Java methods that take objects of single method interfaces
* Useful for working with `Callable` or `Runnable` interfaces
How does that actually work?
+* We need to support Python -> Java -> Python
+* For lexically closed variables, you are actually using a closure
+* For globally scoped variables, Python can look up the right state referenced by a thread local, transparent to the using Python code
Using Python code from Java: Object factories
* Java code can use the Jython runtime to construct Python objects
* Object factories use Jython-specific APIs to efficiently build Python objects
-* Ask the Jython runtime to
-. With some more wrapping, they can also work around the lack of Java annotation support.
-Controlling generated proxies
-* Enables such specific support as `copy.copy` support of Java objects; `__iter__` protocol
-* Exposing Java classes as Python types for better performance. You can make your Java class look and behave like a Python type, just by using the same mechanisms the Jython runtime does. This exposure also reduces the overhead of the Java integration, by removing boxing/unboxing overhead.
-Using Jython's public API
-* But first, what is the public API of Jython?!!!
-* Part of object factory support, but it's possible to use in a variety of ways, mMuch like the Python C extension API.
* A new type system proposed by Jeremy Siek & Walid Taha; extended by others
-* Introduces a dynamic type in a static language
* Seamless integration between statically typed parts and dynamically
typed parts of code in the language
* Guarantees that statically typed part (after type checking) will not