I found out (by analyzing the somewhat messy gnu/kawa/util/PreProcess.java)
that the reason why I hand to edit gnu/expr/Mangling.java by hand was that
- in addition to --with-android -- I was also using --with-java-source to
./configure.

The jar produced without that flag was able to build the HelloKawa project
(provided that I did the trick with injecting --release 8 to javac).

However, the d8 tool still issues its warnings, and the member field names
containing 'mangled' characters are still invisible from the subclasses.

While this isn't something I can't live with - because I don't have that
many such use cases - I wanted to ask about the chances of resolving that
issue?

If it's a problem that would take a lot of time, I can just rename those
few identifiers that are in my code and carry on with the development.

pt., 21 paź 2022, 07:14 użytkownik Panicz Maciej Godek <
godek.maciek@gmail.com> napisał:

> I can confirm this:
>
> when I replaced the superclass' member identifiers shift-left, shift-top,
> clip-left, clip-top, clip-width, clip-height, selection-drawing-mode?, with
> - respectively - shiftLeft, shiftTop, clipLeft, clipTop, clipWidth,
> clipHeight and selectionDrawingMode, they are again visible in the subclass.
>
>
> czw., 20 paź 2022, 22:48 użytkownik Panicz Maciej Godek <
> godek.maciek@gmail.com> napisał:
>
>> I've noticed several more issues with the kawa.jar that I produced by
>> manually changing gnu/expr/Mangle.java:
>> when I try to run the terminal version of GRASP, I get a bunch of
>> warnings like:
>>
>> "no declaration seen for shift-left"
>> "no declaration seen for shift-top"
>>
>> etc.
>>
>> Those identifiers are names of fields in a superclass. The superclass in
>> this case is CharPainter:
>>
>> https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/text-painter.scm#L16
>>
>> I use a "define-object" macro which - rather trivially - expands to
>> "define-class":
>>
>> https://github.com/panicz/grasp-android/blob/master/stages/retreat/GRASP/src/define-object.scm
>>
>> (define-object (ClassName constructor-args ...)::Interface
>>   (define name :: type value)
>>   (define (method args ...) ...)
>>   (SuperClass super-constructor-args ...)
>>   init-code ...)
>>
>> expands to something like
>>
>> (define-class ClassName (Interface SuperClass)
>>   (name :: type init: value)
>>   ((method args ...) ...)
>>   ((*init* constructor-args ...)
>>    (invoke-special SuperClass (this) '*init super-constructor-args ...)
>>    init-code ...))
>>
>> (and it certainly worked with the previous kawa.jar)
>>
>> Anyway, it seems that the code of the subclass is unable to see the slots
>> defined in its parent class.
>> I suspect that this might have something to do with mangling/unmangling.
>>
>> I will try to verify this tomorrow by replacing the identifiers like
>> shift-left with something more like shiftLeft
>> to see if that helps.
>>
>