"java suck"

Meine Hände zittern vor Wut nach dem Lesen von diesem Artikel
Wie kann man nur so über meine Lieblingssprache herziehen!

Ist eclipse immer noch so lahm?

Meine Erfahrungen:
- braucht 2 min zum Starten auf Hochleistungsrechner
- belegt gerne mal 2 GB RAM
- wenn man eine Klammer auf macht, rechnet er erst mal 2 s, bis man
weiterschreiben kann

Daher haben wir uns entschlossen, eclipse als völlig unbrauchbar im
harten Tagesgeschäft des internationalen Wettbewerbs anzusehen. Mit
VisualStudio+VisualAssistX kann man viel produktiver arbeiten.

Stimmt doch so weit.

sothis_

mal davon abgesehen, dass der artikel 9 jahre alt ist, hat er aber dennoch nichts an aktualität eingebüßt

Heinzelotto

Two identical byte[] arrays aren't equal and don't hash the same. Maybe this is just a bug, but:

You can't fix this by subclassing Hashtable.

You can't fix this by subclassing Array because it's not really an object. What you can do is wrap an Object around an Array and let that implement hashCode and equals by digging around in its contained array, but that adds not-insignificant memory overhead (16 bytes per object, today.)

Gee, I know, I'll write my own hash table. I've only done that a thousand times.

musste ich heute selbst wieder an eigener Haut erfahren.

rüdiger

C (the PDP-11 assembler that thinks it's a language) and C++ (the PDP-11 assembler that thinks it's an object system)

sothis_ schrieb:

mal davon abgesehen, dass der artikel 9 jahre alt ist, hat er aber dennoch nichts an aktualität eingebüßt

String has length+24 bytes of overhead

OMG

sothis_ schrieb:

mal davon abgesehen, dass der artikel 9 jahre alt ist, hat er aber dennoch nichts an aktualität eingebüßt

doch, hat er. seitdem hat sich vieles getan.

byto

Heinzelotto schrieb:

Two identical byte[] arrays aren't equal and don't hash the same. Maybe this is just a bug, but:

You can't fix this by subclassing Hashtable.

You can't fix this by subclassing Array because it's not really an object. What you can do is wrap an Object around an Array and let that implement hashCode and equals by digging around in its contained array, but that adds not-insignificant memory overhead (16 bytes per object, today.)

Gee, I know, I'll write my own hash table. I've only done that a thousand times.

musste ich heute selbst wieder an eigener Haut erfahren.

Die Lösung ist recht simpel (Arrays.equals(array1, array2)) und existiert seit Version 1.2, also seit rund 11 Jahren.

Shade Of Mine

byto schrieb:

Die Lösung ist recht simpel (Arrays.equals(array1, array2)) und existiert seit Version 1.2, also seit rund 11 Jahren.

Das Problem ist nicht 2 Zeichenketten auf gleichheit zu überprüfen sondern den hash einer bytefolge zu nehmen.

habe ich persönlich nie gebraucht, aber wenn 2 identische bytearrays unterschiedlichen hash code liefern, ist das ein fehler.

Mit Operatorenüberladung wär das nicht passiert!

Shade Of Mine schrieb:

habe ich persönlich nie gebraucht, aber wenn 2 identische bytearrays unterschiedlichen hash code liefern, ist das ein fehler.

das ist kein fehler. der hashcode bezieht sich auf die objekte, nicht deren inhalt.

// hashcodes von a und c sind gleich, b ist unterschiedlich
byte[] a = {1,2,3,4,5};
byte[] b = {1,2,3,4,5};
byte[] c = a;

Shade Of Mine

~fricky schrieb:

das ist kein fehler. der hashcode bezieht sich auf die objekte, nicht deren inhalt.

in der tat.
das macht hashCode für arrays natürlich ziemlich nutzlos - aber wenn es so definiert wurde... tja, dann kann man nichts machen.

IMHO auch eine sehr fragwürdige definition von equals - denn für identity ist eigentlich == zuständig...

byto

Doch, da kann man was machen: Arrays.hashcode(array)

Hilft natürlich wenig, wenn man Arrays z.B. in HashSets schmeissen will, macht aber eh kein normaler Mensch, von daher.

Jeder vernünftig denkende Mensch programmiert nach den Interfaces der Collection API und verwendet (bei Bedarf) ArrayList statt Arrays.

Shade Of Mine schrieb:

~fricky schrieb:

das ist kein fehler. der hashcode bezieht sich auf die objekte, nicht deren inhalt.

in der tat.

bei strings könnte man meinen, es wäre anders. das liegt aber nur daran, dass strings unveränderlich sind und daher dürfen alle strings mit gleichem inhalt auch das gleiche objekt sein. beispiel:

String a = "hallo";
String b = "hallo";
String c = a;
String d = a.substring(0);

^^ sieht nach 3 oder 4 verschiedenen objekten aus. tatsächlich gibt es "hallo" aber nur ein mal.

~fricky schrieb:

Shade Of Mine schrieb:

~fricky schrieb:

das ist kein fehler. der hashcode bezieht sich auf die objekte, nicht deren inhalt.

in der tat.

bei strings könnte man meinen, es wäre anders. das liegt aber nur daran, dass strings unveränderlich sind und daher dürfen alle strings mit gleichem inhalt auch das gleiche objekt sein. beispiel:
String a = "hallo";
String b = "hallo";
String c = a;
String d = a.substring(0);
^^ sieht nach 3 oder 4 verschiedenen objekten aus. tatsächlich gibt es "hallo" aber nur ein mal.

Lol? Und dann über C++ lästern

Wie sinnvoll ist es denn bitte Objekte nach Identität und nicht nach Gleichheit zu hashen?

C++-Progger schrieb:

Wie sinnvoll ist es denn bitte Objekte nach Identität und nicht nach Gleichheit zu hashen?

sehr sinnvoll. kommt so ein objekt z.b. über eine netzwerkverbindung angeflogen, kannste es sofort identifizieren. seine daten, sein innerer zustand etc. sind dafür erstmal zweitrangig. was bedeutet für dich eigentlich 'gleichheit'?

C++-Progger schrieb:

Lol? Und dann über C++ lästern

das lass mal bleiben. hier ist doch der java-lästerthread.

byto

C++-Progger schrieb:

Wie sinnvoll ist es denn bitte Objekte nach Identität und nicht nach Gleichheit zu hashen?

Objekte werden in Java nach Gleichheit gehasht. Aber der Hash von Arrays geht halt per Default nicht auf die Elemente. Anders ist das bei Collections (List, Set, Map). Der Hash von Arrays ist aber trotzdem konsistent mit der Gleichheit von Arrays, denn equals() geht auch hier nicht auf die Elemente. Möchte man dieses Verhalten für Arrays haben, dann benutzt man Arrays.equals(array1, array2) bzw. Arrays.hashcode(array1, array2). Oder man programmiert nach Schnittstellen und nimmt gleich ne (Array)List. Dann hat man Gleichheit / Hashcode auf den Elementen + Array Realisierung.

DEvent

Shade Of Mine schrieb:

byto schrieb:

Die Lösung ist recht simpel (Arrays.equals(array1, array2)) und existiert seit Version 1.2, also seit rund 11 Jahren.

Das Problem ist nicht 2 Zeichenketten auf gleichheit zu überprüfen sondern den hash einer bytefolge zu nehmen.

habe ich persönlich nie gebraucht, aber wenn 2 identische bytearrays unterschiedlichen hash code liefern, ist das ein fehler.

Was hinder dich daran sowas zu schreiben:

class ArrayContainer {
    private byte[] bytes;

    public ArrayContainer(byte[] bytes) { ... }

    public int hashCode() { return Arrays.hashcode(bytes); }

    public boolean equals(Object that) {return Arrays.equals(that); }
}

Und dann ArrayContainer anstatt dem Array in deine HashMap aufzunehmen? In dem Artikel wird zwar das Ableiten von Hashtable, Ableiten von Array und das Schreiben einer eigener HashMap vorgeschlagen, aber sowas einfach wie das Kapseln von Array wird natuerlich nicht erwaehnt.

Der ganze Artikel ist einfach Bloedsinn. Der Author ist bestimmt ein C/C++ Programmierer und erwartet das alle Sprachen sich wie diese verhalten muessen. Das faengt ja schon mit dem ersten Punkt an

It's hard to live with none of: lexically scoped local functions; a macro system; and inlined functions.

dafür, dass java so schlecht ist, ist es viel zu weit verbreitet

looooooooool schrieb:

dafür, dass java so schlecht ist, ist es viel zu weit verbreitet

ist doch mit vielen dingen so. suboptimales zeug stirbt nicht einfach aus, weil es besseres gibt. gerade bei programmiersprachen scheint's sowas wie 'natürliche selektion' nicht zu geben.
btw, ^^das soll nicht gegen java gerichtet sein. ich mag java ganz gern.

&quot;java suck&quot;

"java suck"