perdian

Du solltest dich dringend genauer mit den Grundlagen von objektorientierter Programmierung auseinandersetzen, wenn du dir nicht dein gesamtes Design auf Jahre hinaus versauen willst. Eine Methode kann nicht losgelöst von der Klasse existieren, von der sie definiert worden ist und dynamisches Laden von Klassen ist eher eine Ausnahmesituation, als eine angenehme Lösung für das erreichen der meisten Ziele.

Wir (in NRW) ebenfalls. Und selbst das hätte man sich eigentlich sparen können. Wenn ich mir ansehe, dass das, was uns dort "beigebracht" worden ist maximal Stoff des zweiten Lernjahres (also normalerweise 6. Schuljahr) war, dann frage ich mich schon, wieso man das ganze überhaupt mit in den Lehrplan aufgenommen hat. Noch mehr zu denken gegeben hat mir dann allerdings die Tatsache, dass es tatsächlich bei der Mehrzahl der Leute in meiner damaligen Berufsschulklasse massive Lücken in dem Bereich gab. Das ging soweit, dass manch einer nichtmal einen einfachen Satz konstruieren konnte, der halbwegs grammatikalisch korrekt war. Da fragt man sich dann schon, wie so jemand sich tief in bestimmte Applikationen/Frameworks einarbeiten können will, wenn er/sie nichtmal in der Lage ist die (meistens eben nur in englisch vorhandene) Dokumentation verstehen zu können.

Na dann isses doch ganz einfach: Mal abschalten und gucken, ob's daran liegt. Ich finde sowieso furchtbar, wie so manche Software meint sich tief in mein System einklinken zu dürfen

Natürlich! https://bugzilla.mozilla.org/ ist ein Beispiel dafür, wie man einen allgemeine Bugzilla Installation auf das eigene CI anpassen kann. Ich kenne die genauen Interna von Bugzilla nicht aber solange es nur um das Logo geht reicht wahrscheinlich schon aus sich einfach mal die Perl Quelldatei von Bugzilla anzusehen. Sobald es etwas komplexer wird einfach mal bei Bugzilla selber nachschauen, würde mich eigentlich wundern, wenn es dort keinen Extension-Guide oder ähnliches geben würde.

Eine weitere Vermutung: Windows XP mit eingeschalteter ZIP Unterstützung und großen Archiven im Hauptverzeichnis? Mehr auch hier: http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=5050516

Vorsicht: Was heisst überflüssig? Selbst wenn du z.B. sagen würdest Product und Component interessieren dich an einem Bug momentan nicht, so heisst das noch lange nicht, dass das auch nächste Woche noch der Fall sein muss. Dann stehst du wieder vor dem Problem, dass du die Änderungen wieder rückgängig machen musst. Definiere "alles anpassen". Heisst das nun einfach nur ein eigenes Logo in den Seitenheader, Anpassung der Schriftarten, generelle Umgestaltung der kompletten Eingabe- und Reporting-Masken oder komplettes Aufsetzen einer neuen GUI, die nur noch die Datenstrukturen von Bugzilla verwendet?

Nein, tut es nicht. Verwechsle nicht Vererbung mit Sichtbarkeit. Vererbung geht in Java (und jeder anderen Sprache, die keine Mehrfachvererbung unterstützt) nur in genau eine Richtung, das heisst eine Klasse hat genau eine Superklasse. Genauso kann auch nur die Superklasse Methoden an angeleitete Klassen vererben. Was aber nichts mit der Sichtbarkeit zu tun hat. Wenn ich mir folgende Klassenhierarchie ansehe: class A { protected int integerInA; } class B extends A { protected int integerInB; } class C extends B{ protected int integerInC; } So kann ein Objekt einer Klasse auf jedes Property von Objekten der anderen Klassen zugreifen. Ganz einfach deshalb, weil die Sichtbarkeit von protected Methoden und Attributen definiert ist als: Genau dieser Teil impliziert allerdings, dass der Zugriff von Klassen im gleichen Package ohne weiteres möglich ist.

Ist doch in diesem Falle absolut egal. Ob ich jetzt ein b minus a von der Datenbank machen lasse oder mich selber darum kümmere bringt mir weder einen Performance-Vorteil, noch irgendwo ein besseres Design. Oder aus welchen Gründen würdest du gerade diese Lösung bevorzugen?

Dann ganz einfach: Wieso setzt den den L&F nicht einfach bevor das erste Fenster geöffnet wird?

Das müsste WindowListener#windowOpened() (Invoked the first time a window is made visible) sein. In welcher Art und Weise rufst du denn die Aktualisierung nach dem Setzen des L&F auf?

-> Zeiten aus der Datenbank auslesen, z.B. nach java.sql.Timestamp -> Timestamp in long (=Unixtime) umwandeln. -> Differenz t2-t1 = Vergangende Zeit in Millisekunden -> Millisekunden / (1000 * 60) = Vergangene Zeit in Mqinuten

Idee: Könnte es sein, dass du mehrere Netzlaufwerke gemountet hast, wo es jeweils eine ganze Weile dauern, bis diese reagieren? Und/oder austauschbare Datenträger in den Laufwerken? Wenn ich das richtig im Kopf habe lädt der JFileChooser alle root Einträge im Filesystem und das könnte bei o.g. Dingen teilweise ein wenig dauern.

http://www.google.com/search?q=tutorial+%22java+mysql+jdbc%22

Kilometerweit offtopic, aber die Technik 'Rechtschreibung' gibt immer noch vor, dass Standard mit 'd' geschrieben wird Das hängt immer stark vom Aufbau der HTML Datei selber ab. Es kann durchaus Sinn machen, wenn keine anderen Schnittstellen auf das System zur Verfügung stehen auf ein HTML Parsing zurückzugreifen um automatisiert an bestimmte Daten zu kommen.

Das sehe ich anders. Es geht hier um Planung und Strukturierung zur Entwicklungszeit. Reflection macht allerdings nur dann wirklich Sinn, wenn sich erst zur Laufzeit bestimmte Parameter ändern bzw. erst ergeben, die einen Einfluss auf die Klassengestaltung an sich haben. Wie gesagt: Es gibt viel weniger Fälle, wo man tatsälich Reflection einsetzen muss, als es auf den ersten Blick den Anschein macht. Woraus folgerst du das denn? Und selbst wenn jemand etwas auf den ersten Blick nicht will heisst doch noch lange nicht, dass man nicht durch eine überzeugende Argumentation rüberbringen kann: "Doch, genau das ist der richtige Weg". Wenn mir ein neuer Kollege ankommt und aufgrund von mangelnden Designkenntnissen und mangelnder Kenntnis von objektorientierter Programmierung alles direkt mit Reflection erschlagen will, der kann direkt vergessen irgendwelche verantwortungsvollen Aufgaben an einem Projekt übertragen zu bekommen, bis er nicht die nötigen Grundlagen beherrscht.

Möglich ja! Der Aufwand hängt vom jeweiligen Format ab, in dem die Daten gespeichert werden sollen - und ohne dieses Format genau anzugeben sind alle einfach/aufwändig Angaben nur geraten. Für den Zugriff Microsoft Word Dokumente gibt es beispielweise: Jakarta POI - Java API To Access Microsoft Format Files OpenOffice bietet ebenfalls eine Schnittstelle an: http://api.openoffice.org/SDK/

Und wo ist dann das Problem? Hast du denn bisher überhaupt verstanden, was ein JAR Archiv eigentlich ist? Wenn nein, dann solltest du dir da erstmal die nötigen Grundkenntnisse verschaffen. Um ein einziges Application JAR zu erzeugen reicht es - simpel gesprochen - aus alle benötigten Klassen mit in das Archiv zu packen, so dass dann in etwa ein Struktur wie diese ensteht: ... de/foo/bar/ClassName.class org/hsqldb/jdbcDriver.class ... Damit findet dann der ClassLoader auch die JDBC Treiberklassen zur Laufzeit. Was mich aber mal interessieren würde: Warum gehst du nicht den Standardweg und bindest alle externen Libraries (ich denke mal da dürften im Laufe der Zeit auch bei dir nicht nur JDBC Treiber zusammenkommen) nicht als getrennte Files in einem lib Verzeichnis aus? Ein FatJAR ist zwar hier und da eine praktische Sache, aber gerade wenn es darum geht das Deployment aktuell zu halten und immer die neuesten Versionen der einzelnen Libraries zu verwenden halte ich das für sehr auufwändig - von der Übersicht mal ganz zu schweigen.

Nein, Pointer sind in richtiger objektorientierter Programmierung unnötig. Letzten Endes ist alles ein Objekt, und daher kann man auch eigentlich alle Abläufe damit behandeln. Das von dir angesprochene Konzept eines Funktionszeigers wird in der objektorientierten Programmierung durch das Delegate Pattern abgebildet. Hierzu wird ein Interface oder eine Klasse als Basisklasse verwendet, die in irgendeiner Art und Weise eine Schnittstelle (= eine Methode) definiert, die von der ausführenden Instanz aufgerufen wird. Durch Vererbung kann dann der Delegate Instanz selber jeder beliebige Ausführungsfluss gegeben werden. Das ist durchaus normal. Gerade bei GUI Projekten hast du in der Regel eine ganze Reihe von Klassen, die für sich genommen so gut wie keinen Inhalt haben, allerdings trotzdem vorhanden sind. Ein Beispiel für so etwas wäre bieten sich immer Zugriffe auf den EventDispatcher Thread, also so etwas in der Art: package xx; import java.awt.BorderLayout; import javax.swing.JFrame; import javax.swing.JLabel; import javax.swing.JPanel; import javax.swing.SwingUtilities; public class EventDispatcherExample { public static void main(String[] args) { final JLabel label = new JLabel("START"); final JPanel contentPane = new JPanel(new BorderLayout()); contentPane.add(label, BorderLayout.CENTER); JFrame frame = new JFrame(); frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); frame.setSize(200, 150); frame.setContentPane(contentPane); frame.setLocationRelativeTo(null); frame.setVisible(true); // Thread starten und Zeit ausgeben new Thread() { [color=blue] public void run() { while(true) { try { // GUI updaten SwingUtilities.invokeLater(new Runnable() { [color=green] public void run() { label.setText(new java.util.Date().toString()); }[/color] }); // Warten Thread.sleep(1000); } catch(InterruptedException e) { // Ignore } } }[/color] }.start(); } } Alles definiert in einer Klassendatei. Durch die Verwendung von anonymen inneren Klassen (der Thread + die Runnable Impementierung zum Zugriff auf den EDT) erzeugen folgende Klassen (die Farben zeigen dabei an, welcher Codebereich durch welche Klasse hinterher im Bytecode repräsentiert wird). EventDispatcherExample.class EventDispatcherExample$1.class EventDispatcherExample$1$1.class Machbar ja - aber kilometerweit am eigentlichen Ziel vorbei. Bei jeder Verwendung von Reflection sollte man sich vorher immer überlegen: Geht das nicht auch anders? Durch Reflection-Aufrufe verliert das Programm nämlich nicht nur an Performance (das ist in der Regel zu verschmerzen) sondern an allererster Stelle massiv an Übersichtlichkeit. Reflection ist ein Feinmechanikerwerkzeug und sollte daher auch nur fein dosiert eingesetzt werden und nicht bei jedem Problem direkt als "damit kann man das auch machen" Lösung präsentiert werden.

Ich gebe dir vollkommen recht. Nur muss man sich aus Azubi Sicht überlegen, wie man damit umgehen will. Will man seine Energie in die "Aufdeckung" der schlechten Ausbildung stecken, bei der IHK Druck machen und auf irgendeine Art und Weise dafür sorgen, dass sich was ändert - oder will man genau diese Energie für das eigene Fortkommen einsetzen? Mir wäre wichtiger selber vernünftige die Ausbildung abzuschließen, denn was hilft es mir, wen nich hinterher sagen kann "ich habe aber dafür gesorgt, dass $Arbeitgeber jetzt nicht mehr ausbilden darf" oder aber, dass ich eine Ausbildung hinter mir habe, die mich fit für das Berufsleben gemacht hat? Auch wenn es letzten Endes der Weg des geringsten Widerstandes ist würde ich mich da ganz klar für die zweite Möglichkeit entscheiden.

Das ist (leider) immer mal wieder in so manch einer Firma der Fall. Du hast jetzt zwei Möglichkeiten: Entweder du regst dich auf und versuchst irgendjemand für diesen Missstand verantwortlich zu machen, oder aber du begreifst das ganze als Chance und versucht dich selbst weiterzubringen. Ich habe während meiner Ausbildung fachlich auch eher wenig von meinem damaligen Chef gelernt - den überwiegenden Teil habe ich mir selbst erlesen oder einfach ausprobiert, ob es so funktioniert, wie ich mir das gedacht habe. An Literatur und sonstigen Quellen, wo das Wissen sozusagen "auf Abruf" bereitsteht mangelt es (garade im IT Bereich) nun wirklich nicht. Du hast also die Wahl: Mach das beste aus deiner Situation und sieh das ganze als Ansporn selbst aktiv zu werden oder warte weiterhin darauf, dass irgendjemand dein Leben für dich in die Hand nimmt.

Ich auch nicht, und würde auch immer sagen "lass es". Das Programmieren selbst ist "nur" das Werkzeug, mit dem das Ziel (das Projekt) erreicht wird. Und nirgendwo sonst wird das Werkzeug mit in eine Dokumentation übernommen. Ein Elektriker wird auch nirgendwo Kabel oder den Schraubendreher, mit dem er gearbeitet hat, mit in eine Dokumentation einfügen. Selbst über ein Struktogramm lässt sich streiten - sobald es hier über ein paar sehr einfache Befehle hinausgeht wird sowas nämlich auch sehr schnell sehr unübersichtlich. Ich habe (als AE) damals ein Diagramm zusammengestellt, in dem grob der Ablauf der Applikation dargestellt ist, ohne mich dabei an irgendwelche formalen PAP oder Flussdiagramm Regeln zu halten. Es geht schließlich darum fundiert zu belegen, wie man sein Projekt erledigt hat und nicht darum zu beweisen wie tollen Code man schreiben kann.

Eigentlich ganz einfach (allerdings ungetestet) SELECT * FROM foo WHERE date(field) = date(now())

Das ist das generelle Problem einer (Berufs)Schule - du kannst es nicht jedem recht machen. Und nur, weil etwas für dich uninteressant erscheint muss das noch lange nicht heissen, dass es auch tatsächlich im späteren (Berufs)Leben nicht wichtig werden kann. Ich wundere mich immer wieder, was sich manch einer von einer Berufsschule erwartet. Und selbst die Inhalte keinen direkten Fachbezug haben: Was hindert dich daran trotzdem das, was du vermittelt bekommst, aufzunehmen und als "interessant und vielleicht später von nutzen" abzuspeichern? Andere Leute zahlen für das, was man in der Berufsschule quasi kostenlos vermittelt bekommt eine Menge Geld.

Umsatzsteuer (=Mehrwertsteuer) darfst du nur dann ausweisen, wenn du gewerblich tätig bist. Ausserdem musst du sie dann auch tatsächlich ans Finanzamt abführen! Du kannst ja nicht einfach als Privatmann hingehen, eine Rechnung schreiben, 16% Umsatzsteuer draufpacken und trotzdem alles in die eigene Tasche stecken - das wäre nichts anderes als Steuerhinterziehung und damit strafbar. Zu deiner Ursprungsfrage: http://www.google.com/search?q=%22rechnung%20schreiben%20als%20privatperson%22