Ok, ich habe es ausprobiert. Die Erklärung liegt wahrscheinlich mal wieder tief in der JLS?
So tief gar nicht.
[QUOTE=Clayn]
Meine begründung schlicht und einfach die Darstellung von floatzahlen. Da dort ja immer ungenauigkeiten auftreten können nund 0,5 einfacher bzw genauer darstellbar ist als 0,7. Dadurch wird 0,7 eben nicht genau 0,7 sein. [/QUOTE]
Das stimmt. 0.5 ist exakt darstellbar. 0.7 ist nicht genau darstellbar. Und bei floatWert += 0.7 kommt der float-Wert raus, der der 0.7 am nächsten kommt. Der ist aber kleiner als der double-Wert für 0.7, der in dem Vergleich verwendet wird.
(Inspiriert von http://stackoverflow.com/questions/7011184/floating-point-comparison/7011243#7011243 )
Nö.
Decimal Representation: 0.7
Binary Representation: 00111111001100110011001100110011
Hexadecimal Representation: 0x3f333333
After casting to double precision: 0.699999988079071
Ok, auf float vs double hereingefallen 
Ich gebe zu, dass mich viele der Fragen hier überfordern, was das tiefere Wissen um die Sprache Java angeht. Trotzdem eine Frage mal von mir, die mir ebenaufgefallen ist. Ich nehme an, den Profis hier ist das schonmal begegnet und deshalb keine Herausforderung mehr. Aber dennoch.
Was passiert hier?
String [] strings = {"a", "b" , "c"};
List<String> stringList = Arrays.asList(strings);
Iterator<String> stringIter = stringList.iterator();
while(stringIter.hasNext()){
String tmp = stringIter.next();
if(tmp.equals("a")){
stringIter.remove();
}
}
System.out.println(stringList.size());
[SPOILER]ich vermute eine Exception (Wahrscheinlich eine NotImplementedException oder so) beim Aufruf von remove. Da Arrays.asList eine Miniimplementierung zurueckliefert. Die diese Methoden nicht implementiert hat. Daher besser in dieser Situation eher so ein Konstruct machen new ArrayList(Arrays.asList(strings))[/SPOILER]
Das wird wohl eine ConcurrentModificationException werfen, da man die List nicht bearbeiten kann während man durch sie iteriert.
MfG,
~Oneric
Wenn der Iterator die optionale remove() unterstützt, dann geht das schon. Ich denke aber, AmunRa hat recht.
[QUOTE=Oneric]Das wird wohl eine ConcurrentModificationException werfen, da man die List nicht bearbeiten kann während man durch sie iteriert.[/QUOTE]Und weil genau das passiert, wenn man es auf der LISTE macht, gibt es die Methode remove() im Iterator, die einem das Löschen trotzden erlaubt. Sonst wäre es ja reichlich sinnfrei eine Methode auf dem Interator anzubieten, wenn es schon eine in der Liste gibt, oder?
Ich tippe drauf, dass eine UnsupportedOperationException fliegt (die Standard-Exception für nicht implementierte Methoden halt)
AmunRa hat recht. Ist mir vorher noch nie aufgefallen.
So ich denke es ist wieder mal Zeit für ne Frage (mal schaun obs zu einfach ist oder ähnliches^^):
Undzwar geht es darum welche Ausgabe folgender Code erzeugen wird:
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
public class ReflectQuiz
{
public static final int FOO = 1;
public static int BAH = 2;
/**
* @param args the command line arguments
*/
public static void main(String[] args) throws Exception
{
System.out.println("Test FOO");
testFoo();
System.out.println("Test BAH");
testBah();
}
static void testFoo() throws Exception
{
Field f = ReflectQuiz.class.getDeclaredField("FOO");
int fieldValue = f.getInt(null);
System.out.println(fieldValue);
System.out.println(FOO);
changeField(f, null, 42);
fieldValue = f.getInt(null);
System.out.println(fieldValue);
System.out.println(FOO);
}
static void testBah() throws Exception
{
Field f = ReflectQuiz.class.getDeclaredField("BAH");
int fieldValue = f.getInt(null);
System.out.println(fieldValue);
System.out.println(BAH);
changeField(f, null, 1337);
fieldValue = f.getInt(null);
System.out.println(fieldValue);
System.out.println(BAH);
}
static void changeField(Field fl, Object inst, Object val) throws
SecurityException, NoSuchFieldException, IllegalArgumentException,
IllegalAccessException
{
fl.setAccessible(true);
Field modField = Field.class.getDeclaredField("modifiers");
int modold = fl.getModifiers();
modField.setAccessible(true);
modField.setInt(fl, fl.getModifiers() & ~Modifier.FINAL);
fl.set(inst, val);
modField.setInt(fl, modold);
}
}
Mal schaun wie lang es dauert bis die richtige Antwort ohne ausprobieren kommt^^
Edit:
Ich hoffe das kam bisher noch nicht so vor. Falls doch Schande über mein Haupt
Da kommt ziemlich viel zusammen. Aber ich tippe auf
1,1,42,1,2,2,1337,1337
weil das static final Field zwar beim Complilieren “Ge-inlinet” werden darf (und deswegen auch nach der Änderung noch 1 rauskommt), aber die fieldValue trotzdem aktualisiert werden dürfte. Beim nicht-final sollte es keine Überraschungen geben (und wenn doch, schiebe ich das darauf, dass ich das Uhrzeitbedingt übersehen habe :D)
Ganz genau. Aufgefallen ist mir das, als ich letztens mal spaßenshalber versucht haben Konstanten aus KeyEvent z.B. zu Verändern um zu gucken ob dann bei Tastatureingaben “falsche” Events bei rauskommen^^
Konstanten aus KeyEvent z.B. zu Verändern um zu gucken ob dann bei Tastatureingaben „falsche“ Events […]
haha, das wäre doch mal ein lustiger „virus“… xD
Ohne auszuprobieren, was macht folgender Code:
map.put("a", "A");
map.put("b", "B");
map.put("c", "C");
for(String key : map.keySet()){
map.put(key, map.get(key).toLowerCase());
}
System.out.println(map);```Nach meiner Erfahrung mit dem Iterieren über Collections und deren gleichzeitiger Modifikation über etwas anderes als den Iterator (hier indirekt über put) tippe ich, dass…
[spoiler]…eine ConcurrentModificationException geworfen wird.[/spoiler]
EDIT: Ok, hab’s ausprobiert. Hatte Unrecht, weil…
[spoiler]das put weder das KeySet noch das EntrySet selbst verändert, sondern nur das Mapping innerhalb des jeweiligen Entry. Wenn man innerhalb der for-Schleife allerdings einen neuen key einfügt, dann passiert das von mir Erwartete.[/spoiler]
Ohne ausprobieren… ich würde mit einer ConcurrentModificationException rechnen, aber wenn’s die nicht ist, sehe ich nichts, würde ich da nichts unerwartetes erwarten ( 
)
Ja, eine ConcurrentModificationException hätte ich auch erwartet. Laut Doku ist das Verhalten undefiniert, wenn man die Map während der Iteration über das Set ändert. Sich darauf verlassen, dass KEINE ConcurrentModificationException fliegt, sollte man sich also auch nicht. ^^
Ist jetzt die Frage, ob man sowas produktiv einsetzen “darf” oder nicht.
wie viele testläufe braucht man denn bei sowas bis man sicher sein könnte? ^^
Keine. Nur den Satz „You may do this-and-that with this map“ in der Doku/Spec