60a1f3b220
Merge branch 'targetBytecode' of https://gitea.hb.dhbw-stuttgart.de/JavaTX/JavaCompilerCore into targetBytecode
Interessant, hab noch nie was von den Flags gehört aber du hast recht, jetzt funktioniert es. Was sagst du dazu @pl ?
Also ich habe es jetzt ausprobiert und es entsteht folgender Fehler wenn man versucht die Methode hashCode aufzurufen:
Java.java:4: Fehler: Referenz zu hashCode ist mehrdeutig
…Ich muss das mal ausprobieren. Bin mir tatsächlich nicht sicher was da passiert.
Man könnte vielleicht Object inferieren. Ich bin allerdings der Meinung, dass man bei einer neuen Sprache nicht unbedingt die Fehler von Java übernehmen sollte. Wie siehst du das, @pl ?
Das Problem ist, dass ich momentan wann immer Fun1$$<Number, Number> kommt das ganze direkt in Fun1$$Ljava$lang$Number$_$Ljava$lang$Number$_$ übersetze. Ich glaube es gibt momentan gar keine…
Ich kann ohne weiteres feststellen ob eine Methode mit einer anderen kollidieren würde. Ich denke mal man müsste die TPHs der beiden Methoden vergleichen und da irgendwie feststellen welche…
Ich kann die Methode nicht überladen weil die dann zweimal die selbe Signatur hat. Sieht so aus als würde ich hier die erste Lösung nehmen und die andere wegschmeißen.
Ich glaube das mit den Bridge Methods ist keine gute Idee. Was passiert, wenn man versucht die Klasse von normalem Java-Code aufzurufen?
50f2a29e1e
Merge branch 'targetBytecode' of https://gitea.hb.dhbw-stuttgart.de/JavaTX/JavaCompilerCore into targetBytecode
Die Signatur ist immernoch falsch, selbes Problem wie #332
Der Test schlägt fehl, weil java.lang.Class importiert wird. Die Klasse benutzt Generics mit Wildcards, die scheinbar noch nicht supported werde.
Schwieriger als gedacht da es scheinbar sehr kompliziert ist alle Klassen aus einem Package zu finden. Bisher funktioniert es nicht für Klassen in java.lang. Ich arbeite dran.
Keine Ahnung warum da ein Check dabei war für Ordner aber jetzt scheint es zu funktionieren.