28.05.2012, 17:08, "Alessio Stalla" alessiostalla@gmail.com:

On Mon, May 28, 2012 at 2:57 PM, Anton Vodonosov avodonosov@yandex.ru wrote:

...

28.05.2012, 16:22, "Anton Vodonosov" avodonosov@yandex.ru:

...

If independent version of new-class is not ready, probably it's possible to   deliver runtime-class a a contrib [...]

I've checked the ABCL sources and see that runtime-class.lisp is now   included into ABCL. So we don't even need to create a contrib for it.

Could anyone help me understand the problem with new-class, why removing   it? Namely, when the asm.jar will be needed,

What I understand now:

1. abcl-jfli function jrc calls java:jnew-runtime-class.   2. java:jnew-runtime-class needs asm.jar.

2. is wrong. jnew-runtime-class used to require asm, was disabled, and  was reintroduced (incomplete) without a dependency to asm and with a  slightly different API. In other words, jrc right now is probably  broken.

To restore jrc right now, you'd need to restore runtime-class.lisp  from version control, and bundle it in contrib under a different  package (assuming it still works with present-day asm).

Ah I see, it's different runtime-class. Thanks for the explanation.

That would be possible, but I object that having 2 different APIs for  the same thing is a potential source for confusion.

Yes, but it's also the way of software evolution: we use some API, notice it's deficiencies, deprecate it and introduce new, better API. Let me note that it could have been called runtime-class2 to avoid confusion and compatibility issues.

Probably now, if packaging the old runtime-class as a contrib, we will need to rename it to old-runtime-class, or even deprecated-runtime-class.

Could you explain about the asm.jar dependency in case of the deprecated-runtime-class? Would it be a load-time dependency, or a call-time dependency?

Best regards, - Anton