(funcall (java:jfield org.armedbear.lisp.Function FUNCTION_CLASS_BYTE…

[alanruttenberg]

…S) function) vs (java:jcall getFunctionClassBytes classloader class), which didn't work in all cases

[easye]

1. Rework and move change to probing available disassemblers to a separate commit.

2. Explain/change why calling getFunctionClassBytes() should be modified.

[easye]

One cannot assume the presences of a the ABCL-INTROSPECT in the core implementation. Additionally, the presence of the function in a file does not necessarily mean the assembler is available, as it might have unsatisfied Maven load dependencies.

[alanruttenberg]

If there aren't any disassemblers then available-disassemblers will be nil. It's a directory probe which simply fails. The require loads the appropriate system, which resolves the maven dependencies.

[easye]

Why this better than calling getFunctionClassBytes on the classloader? Perhaps it is an additional strategy, rather than a strict replacement?

[alanruttenberg]

getFunctionClassBytes didn't work sometimes and I couldn't figure out why, but this works. Should be tracked down. By someone else ;-)

[easye]

So, we should modify by adding the strategy to an (or (ignore-errors [CASE A]) (ignore-errors … clause as it will break even less often…

[alanruttenberg]

That's fine with me.

[easye]

Contains changes from #43

[easye]

I separated out the FUNCALL fallback into #462.

The dependency on the ABCL-INTROSPECT contrib should not be present in the core ANSI code, so if you wish to rework that as part of a load of ABCL-INTROSPECT, I will consider such a patch separately.