Beiträge von JohnFoo

    Das ist Einstellungssache. Ich finds mehr Hui ;)

    Geht mehr darum, nicht auf Java einzuprügeln, bis es ausschaut, wie die Sprache, von der man her kommt. Gibt genug furchtbare Java-Programme, die aussehen wie C. Besser die Gepflogenheiten der Sprache kennen lernen und nach denen arbeiten, bis man versteht, warum die so gelöst worden sind, und nicht so, wie man's kennt. Es ist Geschmackssache, aber so Geschmackssache wie in "ich speib aufn Teller und ess es dann auf" :p.

    Wie Paulchen gesagt hat, Java Logging API wäre die normale Lösung. Für den laufenden Betrieb stellst du den Logger einfach ab.

    Dieser Hack mit dem C-Präprozessor würde es schwer machen, den Code mit einer IDE wie Eclipse zu verwenden, die den Code im Hintergrund laufend kompiliert, und die #-Anweisungen ständig als Fehler erkennen und anzeigen würde. Plus es ist sehr un-Java-like. Pfui.

    In letzter Zeit ist mir immer wieder zu Ohren gekommen, dass Studenten derartige Jobs um ca. 15 Euro machen. Durchschnittliche IT-Freelancer-Stundensätze liegen bei ca. 70 €, also verkauft euch nicht so billig an Firmen! Ihr zerstört die Marktpreise und lasst zu, dass Firmen euch ausnutzen.

    Es kommt ganz darauf an, womit man arbeitet (je nach Branche, Tätigkeit und Technologien wechseln die Stundensätze), was man kann (erklärt sich von selbst) und wie man arbeitet (im Büro alle Stunden bezahlt zu bekommen ist eine andere Sache, als nur die geschätzte effektive Arbeitszeit zu verrechnen). Wer jemand mit "etwas Codier-Erfahrung" sucht, wird nicht viel zahlen, sich aber auch nicht viel erwarten - insofern wird reguliert der Markt sich hier selbst, nicht?

    Dinge wie JAX-RPC würde ich übrigens gerne vermeiden, da das wegen meiner komplexen Datentypen in der KOmmunikation nach viel Aufwand aussieht. Oder täusche ich mich da?

    Verwende JAX-WS, für die Kommunikation zwischen Client und Server schreibst du dir vereinfachte Versionen deiner Objekte als DTOs, die alle Daten auf Basisdatentypen und Strings übersetzen, auf der Gegenseite machst du das Umgekehrte. Damit sparst du dir, unnötig XML-Adapter zu schreiben. Und hast die Freiheit, den Client in einer beliebigen Sprache zu implementieren.

    Eine Lösung von Grund auf mit Sockets und eigenem Protokoll zu schreiben klingt aufwändig, unflexibel und masochistisch - würde ich nur machen, wenn es gute Gründe gibt.

    Am besten dafür geeignet ist ein TreeSet. zB:

    PHP
    @Override
    public int compare(Object o1, Object o2) {
    	return o1.hashCode() - o2.hashCode();
    }

    (wieso subtrahiert man da die hashCodes? Oo)

    Berechtigte Frage.

    Die Implementierung ist so nicht ganz sicher: Der Vertrag von hashCode() sieht in keiner Weise vor, dass zurückgegebene Werte eine Ordnung haben müssen (siehe API).

    Auch wenn man selbst Autor der verglichenen Klasse und des Comparator ist, und selbst weiß, dass hashCode() so implementiert ist, dass die ID geordnet ist, sollte man potentielle Leser nicht damit verwirren, das man so "um die Ecke" programmiert.

    Funktioniert auch soweit, nur fallen mir jetzt doppelte Einträge weg - sprich, wenn zB schon nen Eintrag existiert der 2 ist, kommt kein 2. Eintrag rein, der auch 2 ist (c = 2)


    Das liegt daran, wie sutupud sagt, dass du ein Set verwendest (gleiche Elemente kommen nur einmal vor), wo du eigentlich eine Liste haben möchtest.


    Oki konnte das jetzt auch selber lösen:
    if(o1.weight - o2.weight == 0)
    return o1.weight;


    Hast du so deine compareTo() implementiert? Solltest du aber nicht. Schau dir mal das Interface von Comparable an, der jenes von Comparator. Beide sagen, dass man bei Gleichheit der Objekte 0 zurückzugeben hat.

    Was du machst, ist auf ein Set so lange einzudreschen, bis es sich wie eine Liste verhält. Mach es gleich richtig, und erspare dir zukünftige Fehler, indem du das Set in einer Liste ablegst, und die Liste dann mit einem Comparator über das Gewicht sortierst.

    Wow, der Code ist echt Scheiße!

    Bitte schau dir doch mal Sortieralgorithmen an, z. B. Quick Sort, das Internet ist voll mit Implementierungen davon, und wahrscheinlich enhält die C# Klassenbibliothek ausreichend gute Implementierungen davon.

    lassen sich Klassen auch über den Klassennamen instanzieren. Also in dieser Form:

    Code
    MyClass myClass = createNewInstance("MyClass");


    Der Aufruf wirkt mir etwas widersprüchlich - createNewInstance müsste den Typ MyClass schon kennen, um überhaupt eine Instanz davon als Ergebnis zurück geben zu können. Was man eher machen würde, wäre eine Implementierung eines Interfaces zu instantiieren, z. B. Plugin plugin = createPlugin("PluginImpl").

    Was genau möchtest du machen? Geht es dir bei der Frage nur um die prinzipielle Machbarkeit, oder hast du ein konkretes Problem, das du so lösen möchtest?

    Geht es dir darum, einfach irgendwas möglichst effizient zu Komprimieren (7-Zip rühmt sich, da besonders gut zu sein), oder darum, JARs kleiner zu machen, als gewöhnlich? Wenn es dir darum geht, JARs zu komprimieren, dann solltest du bedenken, dass sie womöglich mit den Java-Methoden zum packen/entpacken von JARs/ZIPs geöffnet werden können (ist mir nicht näher bekannt, aber ich würde damit rechnen), und sollten daher zu ihnen kompatibel sein. Ich würde also annehmen, dass das bestmögliche Verfahren jenes ist, das von der Klassenbibliothek unterstützt wird, und dass die Java-Werkzeuge schon die bestmöglichen unterstützten Ergebnisse liefern. Vielleicht bin ich da aber auch zu optimistisch ..

    Danke für deine Hilfe, aber ich habe mir jetzt java nocheinmal heruntergeladen (die 64-Bit Version), aber es hat leider nicht funktioniert,
    und ich bin auch leider nicht auf die Ursache gekommen.

    Was ich meinte war ja, dass genau die 64-bit Version die Probleme gemacht hat. Weiß gar nicht mehr mit was genau, aber geholfen hat damals nur eine 32-bit Win XP Installation mit 32 bit Java drauf. 32 bit Java auf Win 7 64 bit hat damals keine Änderung gebracht.

    Jetzt eine ganz wilde Vermutung, hatte aber selbst unlängst ein Problem mit 64-bit-Java, das sich letztendlich dadurch lösen lies, dass ich ein 32-bit-Betriebssystem und 32-bit-Java installierte habe.

    Ok, das ist mehr Problemvermeidung als Lösung des Problems, aber vielleicht hilft dir das ja Mal, um die Ursache zu bestimmen. ;)

    imagemagick kann pdf zu jpg konvertieren.


    Ist aber nicht Java-basiert, oder? So muss man zuerst immer sicher stellen, dass imagemagick überhaupt installiert ist, damit das eigene Programm läuft. Nicht so gut.

    Ab Office 2007 Sp2 geht PDF Export out of the box


    Dass es mit Office geht, weiß er vermutlich schon ;). Das Problem ist aber, dass er das programmgesteuert machen will, im Idealfall mit einer Java-Bibliothek.

    Habe damit noch nichts gemacht, aber würde mir vorstellen, dass der Anwendungsfall Word -> Bild weniger häufig vorkommt, als PDF -> Bild; würde also zuerst einen aus einem Programm steuerbaren converter/pdf printer suchen, um danach vom PDF Bilder zu erstellen.

    Sollte ganz einfach gehen, das mit JavaScript zu lösen. Die Datenbank ist vielleicht "sauber", ob sie jetzt sinnvoll ist, hängt ganz davon ab, ob der Kunde z. B. auch immer eine Datenbank verfügbar hat. Falls du weißt, dass der Kunde demnächst sicher keine neuen Anforderungen haben wird, dann ist eine rein HTML/CSS/Javascript-basierte Lösung sicher einfacher in der Anwendung.