Although I would prefer to have large code objects too, I don't see this as a high priority for Java 7. For Python, such code objects are invariably generated code, typically for initializing data structures, and are not performance critical. I'd imagine that's the typical use case seen in other languages. So unless the required changes are truly minimal, it may make more sense to invest development attention in areas with greater payoff.
It helps that we have already a solution under development. Still, Jython's interpreted mode (implemented through a VM that executes CPython bytecode) is useful for many other purposes. Incidentally, it would be nice if large switches got faster... :) - Jim On Mon, Jul 6, 2009 at 6:18 PM, Frank Wierzbicki <[email protected]>wrote: > > On Mon, Jul 6, 2009 at 2:49 PM, Per Bothner<[email protected]> wrote: > > > However, let's not make the perfect be the enemy of the good > > - at the very least we really should fix the size limitations, > > because that is a hard limit. Having all these 16-bit limits > > when the world is moving to 64-bit is ridiculous. > This would indeed be great - the C implementation of Python can handle > very large method bodies, but Jython currently can't. So we see code > in the wild that we can't run. We will grow an interpreted mode in > the next few months, and so will be able to handle this (but with a > performance hit I'm sure). It would be much better if it just worked. > > -Frank > > > > -- Jim Baker [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
