I wonder if fixing this is a 2.4 thing or a 2.3.17 thing. The problem is, 2.3.x-es has to be backward compatible down to 2.3.0. Not being Jython user I'm not 100% sure what the consequences would be, but I have to suppose that it's not fully backward compatible. Other than really old Jython versions don't have PyInstance (which BTW?), some 3rd party code that runs even on as fresh Jython as 2.4 might expect that the model "implements" PyJavaInstance, and updating FM to 2.3.17 would break those applications. Dynamic class loading tricks could be applied however... Note that I can't accept patches without a signed (paper!) CLA.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, a don't understand sentence about accepting patches. Patch is very simple, You may not use it, but please fix it, compatible is broken :(
Possible solution: try to load PyJavaInstance dynamically and if it fail try use PyInstance, but it is bad practice
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the patch issue... it's not an issue in this case, since I can replace PyJavaInstance with PyInstance without looking at your diff. It's just if by any chance you plan to send something more complicated... I really feel bad when someone spends even half an our with a patch, only to find that he has to do paper job for that being accepted that he decides not to do.
Anyway... I will allocate time to finish 2.3.17, and then 2.4.0. 2.4.0 is the same as 2.3.17, except it stops supporting some old API-s, hence the 2nd version number increase. So I guess it will be a good place to fix this Jython thing as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Patch for JythonModelCache.java
I wonder if fixing this is a 2.4 thing or a 2.3.17 thing. The problem is, 2.3.x-es has to be backward compatible down to 2.3.0. Not being Jython user I'm not 100% sure what the consequences would be, but I have to suppose that it's not fully backward compatible. Other than really old Jython versions don't have PyInstance (which BTW?), some 3rd party code that runs even on as fresh Jython as 2.4 might expect that the model "implements" PyJavaInstance, and updating FM to 2.3.17 would break those applications. Dynamic class loading tricks could be applied however... Note that I can't accept patches without a signed (paper!) CLA.
Sorry, a don't understand sentence about accepting patches. Patch is very simple, You may not use it, but please fix it, compatible is broken :(
Possible solution: try to load PyJavaInstance dynamically and if it fail try use PyInstance, but it is bad practice
Regarding the patch issue... it's not an issue in this case, since I can replace PyJavaInstance with PyInstance without looking at your diff. It's just if by any chance you plan to send something more complicated... I really feel bad when someone spends even half an our with a patch, only to find that he has to do paper job for that being accepted that he decides not to do.
Anyway... I will allocate time to finish 2.3.17, and then 2.4.0. 2.4.0 is the same as 2.3.17, except it stops supporting some old API-s, hence the 2nd version number increase. So I guess it will be a good place to fix this Jython thing as well.
Actually, can't I just use PyInstance even in old Jythons? The oldest release I could get is 2.0, and it already have the PyInstance class.
Fixed in 2.3.19. (Now FM should work with all Jython version starting from 2.0.x up to 2.5.x.)