Ich hasse Java

[Alexander Kornrumpf]

Oder wir suchen uns ein leichteres Opfer, Perl oder so.

Ich mag das hier:

"PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil, perpetrated by skilled but perverted professionals."

[Schrompf]

Von der gleichen Seite, die ich leider grade nicht mehr finde, stammt Folgendes:

The last good thing written in C was Franz Schubert's Symphony No. 9.

[MasterK]

Oh süss... wenn kinder sich über java auslassen...
Sry leute... ich war ja selber mal auf dem trip. Aber irgendwann holt einen die realität doch ein. Und nun setze ich c++ ein wenn nötig und sinnvoll, oder eben java wenn nötig und sinnvoll. Denn mal ehrlich, keiner schreibt anwendungen für applicationserver in c++.

Und wer den unterschied zwischen c++ pointer und java referencen nicht erkennt... naja... sei's drum.

[Alexander Kornrumpf]

Sei doch nicht so miesepetrig. Ich benutze ja auch die Bahn und rege mich trotzdem darüber auf. Das schließt sich doch nicht aus.

[klickverbot]

Nachdem Alexander vorhin type classes erwähnt hat, hier ein m.E. sehenswertes »post mortem« zu C++0x concepts – Bartosz Milewski vergleicht sie mit bzw. erklärt sie anhand von type classes aus Haskell.

Meinst du hier? :)

Oh, da fehlt aus irgendeinem Grund tatsächlich der Link – eigentlich wollte ich auf diesen Vortrag verweisen: http://bartoszmilewski.wordpress.com/20 ... e-classes/

[dv]

min() und max() sind ganz klar extrinsische Funktionen, und haben in Klassendefinitionen nix verloren.
Ob die Vergleichsoperatoren Klassenmember sind oder nicht, ist (manchmal) einem freigestellt. Ein besseres Beispiel für etwas, was Java nicht gescheit kann, ist aber IMO das Sortieren.
Unter C++ hab ich ein StrictWeakOrdering-Concept, unter Haskell eine äquivalente Typklasse. Unter Java muss der zu sortierende Container von Comparable erben, was völlig unsinnig und allein die Folge der Limits von Java ist. Interfaces/abstrake Basisklassen sind in sehr vielen Fällen eigentlich "poor man's c++ concepts"; wenn man in C++ anfängt, generisch zu coden, verschwinden eine *Menge* Interfaces.

Nein, es muss nicht alles ein Objekt sein. Nein, OOP ist nicht das Maß aller Dinge.

Statische Typen können ein Krampf sein, aber ich habe sie mir stellenweise schon gewünscht bei Sprachen mit Typinferenz, quasi als "Checkpoints". Alternativ dazu finde ich Typinferenz als opt-in ganz nett, z.B. "dynamic x = get_x();". C++0x hilft da aber ganz ordentlich mit Type Deduction (auto iter = map.find("foo") , jawoll).

unique75 hat dahingehend Recht, als das öffentliche Klasseninterfaces minimal sein sollten. Das heisst auch, dass viele Funktionen eben free functions sind. Die Bindung Methode<->Klasse ist eine verdammt starke, eine VIEL ZU starke für die meisten Aufgaben. Wenn ich zB 5 Möglichkeiten habe, einen Status auszugeben, dann geb ich der Klasse einen (!) Member, der mir den Status zurückgibt, und 5 freie Funktionen, die es auf ihre Weise ausgeben. Ich empfehle hierzu http://stackoverflow.com/questions/1692 ... apsulation . Natürlich gibts in der Praxis manchmal Fälle, in denen man ein paar Methoden zuviel reingibt, absichtlich, weil es dann bequemer zu verwenden ist (convenience functions). Dies sollte aber nur mit Maß erfolgen.

unique75s Postings degenerieren aber - wie auch in der Vergangenheit öfters erlebt - zu Polemik. Lass das. Und hör bitte auf mit deiner Smalltalkwerbung.

[eXile]

Wir wissen doch alle, dass man min ausschließlich als #define im globalen Namespace der windows.h haben darf. (Da ich meine technischen Hürden zu Java schon sehr früh in diesem Thread dargelegt habe, lehnte ich mich weiterhin zurück und genieße …) ;)

[kimmi]

Ich finde übrigens, dass die FORTRAN-Programmierer in dem Diagramm viel zu schlecht abgeschnitten haben. Wer mal mit einem 2-3 Mio.-Zeilen-Programm in F77 bearbeiten durfte, weiß, was ich meine. Und wir wollten doch über Java lästern und was uns da nicht gefällt? Mir fällt da spontan Oracle und ihre momentane Politik bezüglich Java-Standard ein.
Und meiner Erfahrung nach macht die "Meine Sprache ist aber viel besser als deine"-Diskussion, die aus dem Läster-Thread geworden ist, keinen Sinn. Am Ende schreien wieder alle und unique75 wird Smalltalk als die Lösung für all die Probleme dieser Welt ( inklusive dem Heilen von Krebs und ein Mittel gegen die kalte Füsse der Freundin ) hochhalten, wetten?
Ich persönlich bin nicht ohne Grund aus der Kirche ausgetreten, religiös motivierte Streitereien führen zu nichts.

Gruß Kimmi

[next]

Wer Java nicht mag sollte mal einen Blick auf Scala werfen. Das löst einige Probleme von Java recht elegant. Hier mal ein Beispiel wie man min() implementieren könnte:

Code: Alles auswählen

object Math {
    def min[T <% Ordered[T]](a: T, b: T) =
        if (a <= b) a else b

    def min[T <% Ordered[T]](seq: T*): T =
        (seq.head /: seq.tail)(min)
}

case class House(numWindows: Int)

object Main extends Application {
    import Math._
    
    implicit def houseOrdering(house: House) = new Ordered[House] {
        override def compare (other: House) = house.numWindows compare other.numWindows
    }

    println("Minimum of integers: " + min(3, 4))
    println("Minimum of houses: " + min(House(4), House(3)))
    println("Minimum of list: " + min(1, 5, -3, 4, 3, -2))
}

[BeRsErKeR]

Manche verstehen glaub ich immer noch nicht um was es geht. min() und max() gehören nicht in eine Klasse bzw. sollten nicht Teil eines Objekts sein. Das sind einfach globale Funktionen, Punkt. Kapselung dient doch nicht dazu, aus allem auf Teufel komm raus ein Objekt zu machen, sondern um flexiblen Code zu schreiben, der bei Änderungen von internem Code noch genauso funktioniert. Darum trennt man das (public) Interface von der internen (private) Struktur. Darum gibt es get- und set-Methoden usw. Aber was soll es bringen min()/max() als Klassenmethode zu implementieren? Wenn man nicht kapseln muss, sollte man das auch nicht tun. dv hat dazu einen guten Link gepostet. Vielleicht sollten sich den mal einige angucken.

Funktionen, die keinen Zugriff auf interne Elemente einer Klasse brauchen, müssen keine Methode sein. Wozu schreibe ich denn einen '<' Operator, wenn ich dann zusätzlich auch noch min/max als Methode implementiere, obwohl ich bequem das Interface von außen nutzen kann und die Funktion einfach global machen kann? Das ist doch total sinnfrei. Für sowas gibts (meistens) namespaces, damit man eine gewisse Zuordnung der globalen Funktionen hat.

Code: Alles auswählen

namespace math
{
    template <typename T>
    const T& min(const T& x, const T& y){return (x<y)?x:y;}

    // oder für Objektliebhaber
    class Object; // Basisklasse für alles
    const Object& min(const Object& x, const Object& y){return (x<y)?x:y;}
} // namespace math

T oder Object müssen nur den '<' Operator definieren und fertig. Dieser Operator ist das Interface nach außen. min muss nicht auch noch Zugriff auf die Interna der Klasse haben. Dadurch wird die Kapselung nur unnötig verschlechtert und die Gefahr auf Fehler und Unflexibilität erhöht. Und durch den namespace gibt es keine Gefahr von Überschneidungen.

[CodingCat]

Wer braucht schon typedef?

Code: Alles auswählen

writer.writeStartElement(GraphInfoFormat.NavigationGraph.NavigationGraphPage.Metrics.XML_TAG);
writer.writeAttribute(GraphInfoFormat.NavigationGraph.NavigationGraphPage.Metrics.TYPE, GraphInfoFormat.NavigationGraph.NavigationGraphPage.Metrics.Types.TIME);
if (m_timeRegionBitFile != null)
	writer.writeAttribute(GraphInfoFormat.NavigationGraph.NavigationGraphPage.Metrics.REGION_BIT_FILE, m_timeRegionBitFile.toString());
if (m_timeWeightFile != null)
	writer.writeAttribute(GraphInfoFormat.NavigationGraph.NavigationGraphPage.Metrics.WEIGHT_FILE, m_timeWeightFile.toString());
writer.writeAttribute(GraphInfoFormat.NavigationGraph.NavigationGraphPage.Metrics.COUNT, Integer.toString(m_timeCount));
writer.writeEndElement();

[joggel]

Also ich habe kaum Erfahrung mit Java.
Was mich aber verwundert, das viele anderen hier Erfahrungen damit haben.
Ich will mich auch etwas mit JavaProgrammierung auseinander setzen, weil ich denke das Browser-Games was echt tolles ist, bzw. es erreicht mehr Leute.
Ja, so kann ich meine unzähligen Projekte besser präsentieren ... :P

Btw: mit was wurde eigentlich QuakeLive gemacht?

[Aramis]

Oh nein. Bitte, bitte mach keine Browser-Games mit Java. Java–Applets sind ueblicherweise lahm, unansehnlich und sofort als solche zu identifizieren.

Fuer Browser–Games, nimm Flash oder HTML5/JavaScript.
Und fuer serverseitige Logik gibt es genuegend Alternativen zu Java/JSP.

[Despotist]

Ergänzend möchte ich noch erwähnen dass du mit Unity3d auch Webgames entwickeln kannst die sogar echtes 3d anzeigen (benötigt Unity3d Plugin im Browser). Im Normalfall hast du ein Game dass du auf vielen Platformen releasen kannst (Web, PC, Mac, Android, IPad usw.) solange die Systemvorraussetzungen stimmen und einige kleinere Voraussetzungen erfüllt sind.
Beispiele kannst du dir mal hier anschauen:
http://www.wooglie.com/
http://unity3d.com/gallery/game-list/ (nicht alle webfähig)
http://musegames.com
http://dimerocker.com
http://blurst.com

[Chromanoid]

Da es hier mal wieder um was Wichtiges geht :P:
Naja, dass man auch mit Java Webstart erfolgreich sein kann zeigt ja minecraft eindeutig. Ist das Spiel beliebt, wird auch eine JRE Abhängigkeit in Kauf genommen :). Und Jagex ist mit Java scheinbar auch gut gefahren, schließlich sind sie mit RuneScape seit 2001 dabei und haben im Gegensatz zu vielen anderen auch finanziell Erfolg. Und Java serverseitig einzusetzen ist sicherlich eine sehr gute Idee. Die SmartFoxServer Leute stoßen augenscheinlich jedenfalls auf zahlreiche Abnehmer...

Und wenn du HTML5 entwickeln willst, ist doch GWT eigentlich fast die einzige vernünftige Wahl. Und da programmiert man halt mit Java... JavaScript sollte man da nur in speziellen Fällen anfassen. Der HTML5 Port von Quake 2 ist auch in Java entwickelt worden (schließlich wurde jake einfach nur für gwt umgebaut).

Bei 3D im Browser würde ich übrigens auf Java + irgendeinen OGL Wrapper oder eine Engine wie Unity setzen - Zumindest bis 3D in Flash hardwarenah überall möglich ist (Anfang 2012?). AFAIK wird IE9 WebGL nicht unterstützen. Und IE ist schließlich trotz Kritik ein recht beliebter Browser... Für 3D auf mobilen Endgeräten wären UDK, Unity und Java meine Qual der Wahl :).

Edit-> @CodingCat: mit imports könntest du das ganze aber ziemlich verkürzen.

Code: Alles auswählen

//z.b.
import package.GraphInfoFormat.NavigationGraph.NavigationGraphPage.Metrics;
//...
writer.writeAttribute(Metrics.TYPE, Metrics.Types.TIME);

[CodingCat]

Code: Alles auswählen

	private <DataType extends Page> PageLock<DataType> lockAndFetch(DataType data)
	{
		PageLock<DataType> lock = new PageLock<DataType>(data);
		PageLock<DataType> cleanUpLock = lock;
		
		try
		{
			m_scheduler.fetchPage(data);
			cleanUpLock = null;
			return lock;
		}
		finally
		{
			if (cleanUpLock != null)
				cleanUpLock.release();
		}
	}

Warum? Weil das nicht geht:

Code: Alles auswählen

	private <DataType extends Page> PageLock<DataType> lockAndFetch(DataType data)
	{
		PageLock<DataType> lock = new PageLock<DataType>(data);
			
		try
		{
			m_scheduler.fetchPage(data);
			return lock;
		}
		catch(Exception e)
		{
			lock.release();
			throw e; // Error: Exception ist checked.
		}
	}

[CodingCat]

OK, ich bin gerade darauf gekommen, dass fetchPage ja praktisch auch keine checked Exception werfen kann, sonst müsste sie explizit angegeben sein. Damit bleiben nach der aktuellen Spezifikation wohl nur RuntimeExceptions und Errors übrig, die ich auch weiterwerfen könnte. Wenn ich jetzt nicht selbst miterlebt hätte, wie MappedByteBuffer.force (checked) IOExceptions wirft, ohne diese explizit zu spezifizieren... ich bleibe bei meinem finally...

[Chromanoid]

http://bugs.sun.com/bugdatabase/view_bu ... id=6539707

[CodingCat]

OK, ich gebs auf. Ich habe heute nochmal mit PhantomReferences dafür gesorgt, dass beim Memory-Mapped IO wirklich alle gemappten Bereiche ungemappt werden, bevor irgendein überlappender Bereich auch nur wieder gemappt werden könnte. Das gab am Ende richtig komplizierten Code, ich hab mich gefreut, weils in meinem mit Zuckerwatte gepolsterten Test Bed endlich bei gigantischen Dateigrößen super lief, aber als ich dann die bösen Real-World-Daten in all ihrer Zufälligkeit und Inkohärenz in meine Mega-Hash-Tabelle geworfen habe, wars wieder aus und vorbei: der Cleaner stürzt, jetzt immerhin da wo ich kontrolliert und deterministisch die gemappten Bereiche aufräume, mit Blitz und Donner ab, weil sich angeblich überlappende Bereiche gegenseitig vom Freigeben ausschließen.

Ich habe dann noch weiter nachgeforscht, um zu sehen, dass der Absturz selbst dann, wenn sich über die gesamte Testlaufzeit hinweg kein einziger gemappter Bereich je überlappt hat, immer wieder auftritt. Der Schluss, den ich daraus ziehe, ist, dass es wohl gar nicht möglich ist, mittels Java MMIO an verschiedenen Stellen derselben Datei auszuführen.

[CodingCat]

Tja, wie das so ist, kaum hat man aufgegeben, kommt der entscheidende Einfall. Da der Cleaner offenbar durch eine IOException wegen Zugriffsverletzung bei Zugriff auf einen gesperrten Dateibereich abstürzt, und das in einem Thread bzw. einer Java-Sphäre irgendwo dort passiert, wo man als armseliges Java-Coder-Würstchen nicht mal im Traum hingelangt, hilft es, diesen potentiell illegalen Zugriff vorzuverlegen, indem man nach der letzten Schreiboperation in einen freizugebenden Bereich erstmal MappedByteBuffer.force() aufruft.

Wie in vorangegangen Posts bereits erwähnt, ist das diese Methode, die IOExceptions wirft, obwohl sie das laut Spezifikation gar nicht darf. Der Trick ist nun, dem Java Compiler klar zu machen, dass da tatsächlich Exceptions fliegen, diese dann abzufangen, zu ignorieren, und so lange in einer Endlosschleife via force() die Daten reinzuwürgen, bis keine Exception mehr fliegt.

Damit euch genauso schlecht wird wie mir, hier noch ein paar Happen Code:

Code: Alles auswählen

// MappedByteBuffer.force() in eigene Methode verpacken, die deren fehlerhafte Exceptionspezifikation um IOException ergänzt
static void throwingForce(MappedByteBuffer buffer) throws IOException
{
   buffer.force();
}

static void forceDownAllTheWayDown(MappedByteBuffer buffer)
{
   boolean success = false;
   
   while(!success)
   {
      try
      {
         throwingForce(buffer);
         success = true;
      }
      catch(IOException e) { }
   }
}

Randbemerkung: Die ID-Verteilung in den Open-Street-Map-Daten steht einem Zufallsgenerator leider nur in wenig nach, weswegen ich nun zwar eine lauffähige Lösung habe, deren Performance mit dem Konzept der Riesen-"Hash"-Map auf der Festplatte aber so unterirdisch ist, dass dieser grauenhafte Code wohl doch keinen Einzug in das Endprodukt finden wird.

[Krishty]

Hammer.
(Sinnleerer Kommentar, aber irgendwas musste ich auf all die Posts antworten.)

[Krishty]

Hmm … nach den Statistiken der Kaspersky Labs ist Java nach Microsoft Office die zweithäufigste Quelle für Sicherheitslücken. Flash und Acrobat sind aber auch nicht schlecht dabei – wenn das so weiter geht liefern sie in ein paar Jahren zusammen so viele Lücken wie das Office-Paket heute.

[CodingCat]

Brilliantere Momente...

Code: Alles auswählen

public static int readInt()
{
	while (true)
		try
		{
			return Integer.parseInt(readLine());
		}
		catch(NumberFormatException e) { }
}

[CodingCat]

Heute war mal wieder eine absolute Java Sternstunde, ich konnte meinen Algorithmus um 400% beschleunigen, indem ich Finalizers aus den beteiligten Klassen entfernt habe. Ziemlich viel, dafür dass die Finalizers nur nice-to-have waren, aber keine wichtige Aufgabe hatten...

[Chromanoid]

Hier mal eine interessante Meldung auf GamesMarkt (siehe Bigpoint schaltet "Poisonville" bald ab). Das Browsergame PoisonVille von BigPoint soll laut des Geschäftsführers vornehmlich aufgrund der Technologiewahl Java für den Client gescheitert sein. Ich persönlich hatte in verschiedenen Diskussionen unter Anderem auf dieses Spiel verwiesen (es wurde mit der JMonkeyEngine umgesetzt), um Java als mögliche Spieleplattform zu verteidigen. Der Geschäftsführer moniert, dass Java zwar Hardware-unabhängig sei, deshalb aber auch nicht die Hardware-Nähe, die Spiele benötigen, leisten könne und dass viele Benutzer technische Probleme hatten.
Das Kommentar muss man als Java-Liebhaber wohl erst mal so hin nehmen :D.

Aber ich möchte trotzdem erwähnen, dass
1. PoisonVille's Zielgruppe (das Spiel wurde in Kooperation mit Playboy beworben) sicherlich eher alles andere als technikaffin ist,
2. fast die gleiche Technologie (LWJGL wird auch bei der JMonkeyEngine eingesetzt) bei Minecraft zum Einsatz kommt und der Entwickler wohl recht zufrieden damit ist
und dass
3. das Gameplay des Spiels mir "minderwertig" erscheint und aus meiner Sicht damit eher Management- und Designfehler für den Misserfolg verantwortlich sind.

PS: Soweit ich das beobachtet habe, wendet sich BigPoint jetzt wohl vor allem Unity3D als Plattform für 3D-Spiele zu.

[j.klugmann]

@Poisenville: Das scheitern vom angeblichen "Vorreiter" Poisenville liegt auf jedenfall nicht bei der Technik, sondern an dem grässlichen Game-Design. Total verkorkst und meiner Meinung nach nicht zu gebrauchen.

@Java: Immer wieder lustig hier zu lesen. Zum Glück wurde ich mit Java beruflich wie privat erst einmal konfrontiert, damals ging es um ein kleineres Post-Processing Framework mit JOGL. Ich bleibe da lieber bei meiner gesunden Mischung aus C++,Haskell,Python und Javascript! ;)

[Krishty]

(http://geekandpoke.typepad.com/geekandp ... d-npe.html)


(http://geekandpoke.typepad.com/geekandp ... ading.html)

[joggel]

.... mit JOGL.

Freschheit... immer wenn ich das lese, muss ich an Mich denken!
Ja, genau deswegen hasse ich auch schonmal Java.

[jrk]

Ich hasse Java, als ihr noch alle nicht wusstet, was Java ist.

Ein Jahr J2ME Spieleewnticklung (im Jahre 2003, auf Handsets mit 32kb ram) hat mich fuer immer zum Javahater gemacht.

[jrk]

JAVA IST GEIL OMG! NOTCH BENUTZT JAVA! MINECRAFT NOTCH! DER NOTCH! OMG JAVA OMG NOTCH!