Re: [Jython-users] Jython documentation

[Diez B. R. <de...@we...>]

> I was thinking specifically of the case of interacting with existing
> java libraries. Java methods still demand correct typing when used
>
> from jython. You get errors when doing things like:
>  >>> d = java.util.Date("'100")
>
> And the same would be true for methods on any java classes one has
> written. However misusing a java generic will give no such error. So
> you may get a deferred type error in java code which a java
> programmer would think has been prevented by specifying the generic.
>
> So the issue isn't  the lack of type safety in jython, which I agree
> is generally a gain, but the "odd" behavior of generic typing in java
> code called from jython. Without thinking carefully about it one
> might start looking for bugs in the wrong places.

I see what you mean. However, the type errors are thrown by the JVM - which 
isn't the case for generics, where it doesn't do anything because of the type 
erasure.

So I still find it odd to add typechecking in jython. Especially since the 
latent classcast-exceptions that can result from it are known for ages in 
java-development. Sure, generics can remedy that to a certain extent - but 
just compile-time. One has to deal with runtime errors in jython anyway, as 
they are the only thing (besides syntax errors) you get.

And the added typecheck doesn't come for free, either. And things can get ugly 
pretty fast, as in java I often have generics as parameters of generics... 
So, when creating instances of java collections for e.g.

Map<String, Map<Foo, Bar>> 

like this:

my_map['key'] = {Foo() : Bar()}

one has to ensure that the jython dict is properly type annotated... Something 
I'm not even sure it can be done.

nope. still not convinced ;)

Diez