Oder selbst getested zu haben: Zeile 31 - possible loss of precision dürfte wohl entweder von einer IDE oder einem Compiler kommen da der explizite cast auf den kleineren Datentyp fehlt - ergo: dürfte also, abhängig vom compiler, gar nicht erst compilen (und mit ner relativ eindeutigen Fehlermeldung abbrechen).
Da TMII aber geschrieben hat er habe etwas länger gebraucht um den Fehler zu finden gehts entweder nicht darum - oder seine Umgebung in der er den Code zumindest mal syntaktisch hat überprüfen lassen (really - copy’n’paste und mal mit nem compiler ran - setzt voraus die Source-Files zur Verfügung zu haben - sonst erwischt man sich ggf bei nem eigenen Tippfehler) hat dies ignoriert. Dürfte sich aber in der JLS was finden lassen wie hier zu entscheiden ist.
Und wo du das schreibst, frage ich mich, warum ich, als ich
someFloat = someFloat + someDouble
geschrieben habe, nicht gemerkt habe, dass das Unfug ist… :o
Geklaut von stackoverflow:
private void eat() {
System.out.println("animal eating");
}
public static void main(String args[]) {
Animal a = new Horse();
a.eat();
}
}
class Horse extends Animal {
public void eat() {
System.out.println("Horse eating");
}
}
Was wird beim Ausführen der main-Methode angezeigt, und vor allem: Warum?
Mein Versuch
[spoiler]Meine Vermutung ist nun , dass “animal eating” ausgegeben wird, da die Methode eat private ist und somit nicht von Horse überschrieben wird. (nennt man das dann trotzdem überladen?)
da a von statischen Typ Animal ist, wird die Animal.eat() methode gerufen. [/spoiler]
Stimmt. Ist schon etwas seltsam, wenn das hier:
Horse h = new Horse();
h.eat();
Animal a = h;
a.eat();
zwei unterschiedliche Ausgaben liefert…
[quote=Landei]Stimmt. Ist schon etwas seltsam, wenn das hier:
Java Code:
Horse h = new Horse();
h.eat();
Animal a = h;
a.eat();
zwei unterschiedliche Ausgaben liefert…[/quote]Das klappt aber nur, weil Du in der inneren Klasse von (oder wenigstens in der selben Datei wie) Animal bist.
Aus einer anderen Klasse(-ndatei) geht das nicht.
bye
TT
Nun… wenn es anders wäre, wäre der Sinn von private ja auch irgendwie ad absurdum geführt. Inbesondere könnte man ja NIE eine private Methode zu einer Klasse hinzufügen, weil man NIE sicher sein könnte, dass nicht irgendjemand schon von der Klasse erbt und die gleiche Methode implementiert hat (die ja dann die zu erstellende Methode überschreiben würde). Um das ganze klarer zu machen, gibt es ja @Override.
wenn es nur etwas gäbe, um Methoden (oder gar die Klasse, String…) final zu machen 
(schon klar was du meinst, aber der Punkt darf bei der Aufzählung nicht recht fehlen)
(edit: ok, doch nicht ganz richtig beim ersten Lesen gelesen, du meinst nachträglich in der Oberklasse, dennoch…)
[quote=SlaterB]wenn es nur etwas gäbe, um Methoden (oder gar die Klasse, String…) final zu machen[/quote]Das ist doch gar nicht die Lösung, sondern “jede Klasse in einer eigenen Datei”…
bye
TT
… was aber nochmal unabhängig von der Frage ist, wo denn die main() steht.
Ich denke, es ist klar, worauf mit der Frage abgezielt wurde.
[QUOTE=Marco13]… was aber nochmal unabhängig von der Frage ist, wo denn die main() steht.
Ich denke, es ist klar, worauf mit der Frage abgezielt wurde.[/QUOTE]
Die main-Methode muss entweder in Animal stehen, oder man macht beide Klassen zu inneren statischen Klassen, dann kann sie in der äußeren Klassen stehen.
public class Test<T>{
public Hashtable<Integer,String> getElements(){
return new Hashtable<Integer,String>();
}
public T getParent(){
return null;
}
public static void main(String[] args) {
Test test = new Test();
System.out.println(test.getParent().toString());
for (String p: test.getElements().values()){
System.out.println("inside the loop");
}
System.out.println("Finished");
}
}```
Was ist die Ausgabe dieses Programms wenn man es compiliert und laufen lässt.ist der Code wirklich so gedacht?
weiter
[spoiler]wie nur schwer zu erkennen kompiliert die Schleife gar nicht ohne Änderung, wegen nicht gesetzten generischen Typ, komplizierte Regeln
wie recht gut zu erahnen, liefert getParent() null, ergo Ausgabe dazu NullPointerException,
ändert man auch das dann liefert die Schleife natürlich nichts mangels Elemente, nur Ausgabe dahinter erscheint
wo ist der Witz oder waren es diese Erkenntnisse? ok, das erste mit Generics wohl
[/spoiler]
[SPOILER]
Der Code war absichtlich so, da man, wie du selbst geschrieben hast, den Compile-Fehler sehr leicht übersieht. Daher hab ich einfach die NPE als “falsche” Antwort dazugegeben.
So ein Ähnlicher Code ist bei mir produktive gewesen. Zuerst war die Klassen nicht generisch, getParent() hatte immer Object zurückgegeben. Aber sie hatte eine Methode, die eine generische Hashtable zurückgegeben hat, so wie in diesem Bsp die Methode getElements();
Als ich dann die Klasse gerefactored habe und die Klasse generisch wurde, sodass getParent() nicht mehr Object sondern eben den Generischen Type zurück gegeben hat, dachte ich mir dass das kein Problem sein sollte. War aber nicht so. Aus einem für mich unerklärlichen Grund verliert die Methode getElements() ebenfalls die generische Information, wenn Test ohne Type Parameter erstellt wird, und das obwohl getElements nichts mit dem Type Parameter zu tun hat.
[/SPOILER]
public static void main(String[] args) {
boolean b = true;
b = b || test();
b = b | test();
b |= test();
System.out.println("b: " + b);
}
public static boolean test() {
System.out.println("test");
return Math.random() < 3;
}
}
wie oft erscheint die Ausgabe ‘test’?
[spoiler]2x. Der Aufruf aus Zeile 4 wird aufgrund der lazy evaluation nicht ausgeführt. Die anderen beiden Operationen arbeiten bitweise und werden daher ausgeführt.[/spoiler]
Die Antwort von Herrn cmrudolph hab ich auch:
[SPOILER]Zeile 3 gibt nix aus.
Zeile 4 gibt auch nix aus, weil der Operator kurzschließend ist.
Zeile 5 und 6 gibt jeweils „test“ aus, da der Operator nicht kurzschließend ist.
Zeile 7 gibt dann „b: true“ aus, da die veroderung basierend auf true keinen Effekt hat. 
Antwort : 2x .[/SPOILER]
Rückmeldung braucht es ja nicht unbedingt,
wer es zu genau wissen will und Zweifel hat kann es ausprobieren 
,
schade manchmal dass es nicht ||= gibt, aber die Gründe wie schlechte Lesbarkeit sind auch nicht ganz ohne
Bin zwar sonst eher lesend unterwegs, meinen :scheiterhaufen:-Moment der Woche will ich aber mal teilen 
import java.io.InputStream;
public class Test {
private static class NotSoReliableInputSource extends InputStream {
private String string;
private int pos = 0;
public NotSoReliableInputSource(String string) {
this.string = string;
}
@Override
public int read() throws IOException {
if (pos < string.length() / 2) {
return string.charAt(pos++);
} else {
throw new IOException("Timeout!");
}
}
}
public static void main(String[] args) throws IOException {
String result;
String string = "Timeout?";
try (NotSoReliableInputSource in = new NotSoReliableInputSource(string)) {
byte[] b = new byte[string.length()];
in.read(b, 0, string.length());
result = new String(b);
} catch (IOException e) {
result = e.getMessage();
}
System.out.println(result);
// [a] Timeout?
// ** Timeout!
// ``` ???
}
}```Intuitive Antwort: Was ist die Ausgabe?
import java.util.Arrays;
import java.util.BitSet;
public class BitSetTest
{
public static void main(String[] args)
{
BitSet bitSet = new BitSet();
int bitIndex = 0;
bitSet.set(bitIndex++, true);
bitSet.set(bitIndex++, false);
bitSet.set(bitIndex++, true);
bitSet.set(bitIndex++, false);
int expected[] = { 1, 0, 1, 0 };
int array[] = bitSet.stream().toArray();
System.out.println(Arrays.equals(expected, array));
}
}