
PerdianMG
Mitglieder-
Gesamte Inhalte
103 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Alle Inhalte von PerdianMG
-
Aus Datei lesen und gleich wieder in Stream schreiben
PerdianMG antwortete auf ETnachHause's Thema in Java
Naja eigentlich ganz einfach - du brauchst halt eine Quelle, wo deine Daten herkommen (einen InputStream) und ein Ziel, wo die Daten hingeschrieben werde (einen OutputStream). Als Beispiel mal der einfache Weg, eine Datei direkt zu kopieren: public void copyFile(File source, File destination) throws IOException { InputStream in = new BufferedInputStream(FileInputStream(source)); OutputStream out = new BufferedOutputStream(new FileOutputStream(destination)); for(int data = in.read(); data > -1; data = in.read()) { out.write(data); } out.flush(); out.close(); in.close(); } Ciao Christian -
Also selbst wenn hier jemand deine Hausaufgaben machen soll, dann müsstest du schon ein paar mehr Informationen liefern, vor allem _wie_ erfolgt denn die Eingabe? Per Kommandozeile, per GUI, Spracheingabe oder was weiss ich noch alles :-) Ciao Christian
-
Ich würde das nicht als Speicherfresser bezeichnen, sondern als normales Java-Programm. Da kannst du machen was du willst aber sobald die VM erstmal oben ist und du ein paar graphische Elemente erstellt hast wirst du immer schon bei über 10 MB liegen. Aber ich würde mir da auch keinen soooo großen Kopf drum machen. Hab gerade mal bei mir in die Prozesstabelle gesehen und zwei IE Instanzen liegen auch bei 12 und 14 MB - das liegt also auf dergleichen Stufe. Eclispse benötigt bei mir auch schonmal 50 MB und mehr. Aber wir haben ja auch keinen Wettbewerb "Wer benötigt am wenigsten Speicher". Gedanken würde ich mir erst machen, wenn dein Programm merklich langsamer wird und das ganze System mit nach unten zieht. Ciao Christian
-
Ich weiss nicht, ob das mit der Standard URLConnection so ohne weiteres möglich ist. Ich benutze für HTTP Automatisierungs-Geschichten eigentlich immer Jakarta HttpClient oder HttpUnit (http://httpunit.sourceforge.net/) da geht die ganze Verarbeitung deutlich komfortabler mit. Ciao Christian
-
Klaro - ohne Einschränkungen. Ciao Christian
-
Das kommt darauf an, was du genau meinst. Zum Entwickeln darfst du das JDK, JSDK, oder wie es auch gerade heisst, verwenden ohne irgendetwas zu beachten. Wenn du deine Programme weitergibst, dann darfst du jedoch nur das JRE mit verteilen. Ciao Christian
-
Wie man es auch immer drehen will: es gibt in Java keinen Destruktor. Wie auch? Wie willst du ihn aufrufen? Sowas wie .free() gibt's nicht und .finalize() ist protected also kann man das auch nicht als quasi Destruktor sehen. Ciao Christian
-
Nein auch keine Art Ersatz-Destruktur. Bei einem Destruktor bist du sicher, dass er aufgerufen wird, wenn dein Object zerstört wird (sonst würde ihn ja niemand aufrufen *g* aber okay), bei finalize() kannst du nie wirklich wissen, ob sie auch wirklich aufgerufen wird, denn wie in der Doku steht es _sollte_ zwar von der VM immer getan werden, aber wirklich sicher sein kannst du nicht. Ciao Christian
-
Iterativ oder rekursiv? Ciao Christian
-
Hi, Das ist mal einer der wenigen Fälle, wo man einen String-Constructor sinnvoll verwenden kann *g* byte[] byteArray = irgendwoher(); String unicode = new String(byteArray, "CP850"); Sollte eigentlich funktionieren, bei mir klappt das zumindestens immer wenn ich von UTF-8 nach ISO-8859-1 konvertieren muss. Ciao Christian
-
Sieh dir mal das JavaDoc zum GridLayout an, da steht genau drin beschrieben (mit Beispiel), wie du eine NxM breite Matrix definieren kannst. Die einzelnen Objekte fügst du dann dem Container hinzu, auf den du das Layout angewendet hast. Also z.B. JPanel foo = new JPanel(new GridLayout(3,3)); foo.add(new JButton("Bar")); Ciao Christian
-
Meinst du wirklich? Im zweiten Falle vergleichst du ja nur zwei Referenzen miteinander, wogegen du im ersten Falle einen Methodenaufruf plus einen Vergleich hast. Ich hab's auch gerade mal durchgetestet mit String test = "eee"; for(int j=0; j < 10; j++) { long start = System.currentTimeMillis(); for(int i=0; i < 200000000; i++) { // boolean erg = (test == ""); boolean erg = (test.length() == 0); } long end = System.currentTimeMillis(); System.err.println("x: " + (end - start)); } Die test == "" dauert pro Durchlauf ca. 800 ms, die test.length() == 0 dauert ca. 1200 ms. Mal ganz nebenbei: Strings mit == zu vergleichen ist ohnehin nicht der Hit :-) Ciao Christian
-
Das ist wohl auch so eine Sache, die jeder anders sieht - "guter Code" ist ja ziemlich subjektiv. Nimm alleine mal diese Beiden Variationen: public static void main(String[] args) { for(int i=0; i < args; i++) { foo(args[i]); } } und public static void main(String[] args) { for(int i=0; i < args; i++) { foo(args[i]); } } Beide machen _exakt_ dasgleiche aber sehen doch von der Formatierung her anders aus. Ich fand mal das erste supertoll und das zweite grottenschlecht. Inzwischen hat sich das Blatt gewendet und Nr. 1 kann ich nicht mehr sehen *g* Gibt auch sowas hier (wird glaube ich bei GNU gerne so gesehen) public static void main(String[] args) { for(int i=0; i < args; i++) { foo(args[i]); } } Du siehst - alleine bei eigentlich simplen Sachen wie Einrückung prallen schon Welten aufeinander - und wir haben noch nicht einmal von Einzug geredet (wieviele Zeichen, Tabs oder keine Tabs etc.) Es isit also (finde ich) gar nicht mal so wichtig _wie_genau_ dein Stil aussieht - Hauptsache ist, dass es einen Stil gibt, den man wiedererkennen kann und der es einem ermöglicht das Problem relativ schnell und einfach zu verstehen. Ciao Christian
-
Unter welche VM lässt du das Applet dennim IE laufen? Wenn es die Original Uralt-Version von Microsoft ist, dann wirst du unter Verwendung von JButton, Jxxx nicht weit kommen, da die unter 1.1 noch nicht verfügbar waren. Da wirst du dann entweder ein aktuelles JRE installieren müssen, oder dich auf die java.awt.* Klassen beschränken. Ciao Christian
-
Na dann --> info@borland.de Christian
-
Wieso probierst du nicht einfach mal den naheliegensten Weg aus, nämlich bei Borland selber nachzusehen? http://www.borland.com/jbuilder/ Dann auf Personal --> und schon steht ziemlich weit unten "Download JBuilder Personal - FREE!" So einfach ist das Christian
-
Also ein PreparedStatement brauchst du ja eigentlich nur dann, wenn du Objekte, oder andere Werte hast, die du je nach genauer Query einsetzen willst. Wenn dein SQL String wirklich von Anfang an _komplett_ feststeht, dann würde ich immer ein "normales" Statement nehmen und den Code fest reinhacken. Wenn du doch irgendwann merkst, dass du doch das ein oder andere Mal eine andere Version nehmen musst dann kann man immer noch auf Properties umsteigen. Ciao Christian
-
Also ich würde es immer mit Actions machen - dadurch entstehen zwar ein paar Klassen mehr, aber das ganze ist übersichtlicher und angenehmer. Ciao Christian
-
-
Also ich habe bisher noch nie einen Baum selber komplett implementiert aber so abwegig ist mir der rekursive Ansatz gar nicht - ich würde es aus Performance-Sicht aber _immer_ iterativ machen wenn es denn möglich ist. Aber ich hab gesehen wo der Fehler steckt - sind zwei ziemlich einfache Dinge: 01 private Node getNodeIt(Comparable key, Node tree) { 02 03 Node currentNode = tree; 04 while(currentNode != null) { 05 int currentResult = key.compareTo(currentNode.key); 06 if(currentResult == 0) { 07 // Gefunden! 09 return currentNode; 10 } else if(currentResult < 0) { 11 currentNode = currentNode.left; 12 } else { 13 currentNode = currentNode.right; 14 } 15 } 16 17 return null; 18 19 } Die zwei Fehler steckten einmal in Zeile 10 (hier muss natürlich auf 0 und nicht auf 1 verglichen werden) und in den Zeilen 11 und 13, da muss ja von der aktuellen Node ausgegangen werden und nicht vom Ursprungsbaum. Ciao Christian P.S. Lass man folgenden Code laufen und dann sag mir nochmal ob du lieber die iterative oder recursive Variante nehmen würdest :-) public static void main(String[] args) { MyTreeMap treeMap = new MyTreeMap(); treeMap.put("5", "5"); treeMap.put("4", "4"); treeMap.put("3", "3"); treeMap.put("2", "2"); treeMap.put("6", "6"); treeMap.put("7", "7"); treeMap.put("8", "8"); long start = System.currentTimeMillis(); for(int i=0; i < 10000000; i++) { treeMap.getNodeRec("2", treeMap.root); } long end = System.currentTimeMillis(); System.err.println("Milliseconds for recursive run: " + (end - start)); start = System.currentTimeMillis(); for(int i=0; i < 10000000; i++) { treeMap.getNodeIt("2", treeMap.root); } end = System.currentTimeMillis(); System.err.println("Milliseconds for iterative run: " + (end - start)); }
-
Naja dann weiss ich nicht wie's laufen soll... Struktur für's rekursive ist doch die: Du schnappst die die Wurzel und hangelst dich dann die Blätter entlang, solange bist du das Blatt gefunden hast, das für dein gesuchtes Objekt stimmt. Ciao Christian
-
Dann ist dein Baum selber falsch implementiert. Ciao Christian
-
Also ich würde das ganze so probieren (ungetestet): private Node getNodeIt(Comparable key, Node tree) { Node currentNode = tree; while(currentNode != null) { int currentResult = key.compareTo(currentNode.key); if(currentResult == 0) { // Gefunden! return currentNode; } else if(currentResult < 1) { currentNode = tree.left; } else { currentNode = tree.right; } } // Kein Key hat gepasst, oder Tree war direkt am Anfang null also null zurückliefern return null; }
-
Von der Syntax her bin ich auch eher der C-Fan, schön kompakt und klar. Aber genau das kann vielleicht für den ein oder anderen Anfänger auch störend und nicht so übersichtlich wirken. Wenn ich ein BEGIN und END da stehen habe, dann sehe ich auch direkt wo's losgeht und aufhört - von der Übersichtkeit wäre da vielleicht sogar noch ADA ganz interessant, aber wir wollen mal nicht übertreiben. Was gerade auch für Pascal am Anfang spricht ist das - im Vergleich zu C - geradezu kinderleiche String-Handling, denn einen Anfänger auf einen char* loszulassen und dann auch noch zu verlangen, dass er das ganze versteht. Sehe ich auch so. Das prozedurale Denken ist - auch wenn es manch anderer sehen möchte - auch für objektorientiertes Denken dann auch in einer Methode musst du ja letzten Endes irgendwann auch mal wirklich etwas implementieren und das geht ja sei es bei C++, Java oder Delphi eben auch nur prozedural. Ciao Christian
-
Also mit VisualBasic würde ich nicht anfangen - ganz einfach deshalb, weil du dort viele Dinge machen kannst, die bei anderen Sprachen (aus guten Gründen) nicht funktionieren. Auch wenn es sich "Visual" schimpft ist halt immer noch viel von guten alten BASIC mit drin und diese Sprache ist nunmal einfach prädestiniert dafür unüberischtliche und sehr schlecht verständliche Programme zu schreiben. Wenn es nur um die Prinizpien der Programmierung im Allgemeinen geht würde ich mit einer übersichtlichen Sprache wie beispielsweise Pascal oder Modula anfangen. Die werden zwar in dieser Art und Weise in der Arbeitswelt nicht wirklich eingesetzt (Okay, Pascal bei Delphi aber das geht auch oft zu sehr Richtung Visual und man lernt dadurch am Anfang wenig). Wenn man damit einmal die Konzepte begriffen hat dann fällt der umstieg auf eine andere Sprache ungeheuer einfach. Wenn du diese Zeit nicht hast sondern direkt produktiv anfangen willst dann würde ich aber auch von C oder C++ abraten - ganz einfach deshalb weil der Super-Assembler einfach für den Anfang zu abgehoben und zu kompliziert ist (meine Meinung, aber immer auch Einstellungssache). Mein Fazit: Pascal und Modula bieten (auch wenn oft als Kindersprachen abgestempelt) immer noch den besten Einstieg um Grundlegende Konzepte zu lernen - und dann kann man zu "richtigen" Sprachen wie C oder Java wechseln. Ciao Christian