perdian

Ohne MS Jet näher zu kennen bieten sich für JDBC eigentlich immer java.sql.Date, java.sql.Time und java.sql.Timestamp an.

Da sagt die XML Schema Spezifikation etwas anderes:

http://forum.fachinformatiker.de/fragen-anregungen-zum-board/7236-boardregeln.html

Wieso guckst du nicht einfach kurz vor einem solchen Posting in die API? Nein, es werden nicht nur public Methoden unterstützt.

Das ist ja immer eine sehr persönliche Wahl. Ich hätte den Satz genau andersherum gesagt ;-) Aber auch im Java Bereich gibt es ja Grabenkämpfe, ob man nun Netbeans oder Eclipse verwenden sollte. Da muss jeder mit seiner eigenen Wahl glücklich werden. Ist es sicherlich auch. Wenn ich nicht das notwendige Toolset "drumherum" habe ist die eigentliche Arbeit deutlich unproduktiver und damit deutlich unangenehmer. Mehr oder weniger direkt: Language Integrated Query - Wikipedia, the free encyclopedia

Was habe ich da eigentlich für einen Mist geschrieben? ;-) Ich meine natürlich "recht leistungsfähig, dafür aber auch recht komplex".

Dann ganz klar erkennen lassen, dass du für einen begrenzten Zeitraum bereit bist da mitzuspielen, aber auch für dich eine perspektive, das heisst eine "richtige" Ausbildung haben willst. Wenn die Firma nicht bereit ist das zu tun und ihren Teil der Vereinbarung einzuhalten, dann durchaus durchblicken lassen, dass du bereit bist dich nach Alternativen umzusehen.

Rechtzeitig bei deiner IHK anrufen, den Fall schildern und dir dort erläutern lassen, wie das weitere Vorgehen ist.

Nein. Und bei Threadpushing sowieso nicht.

Das "mal eben" in ein paar Absätzen zu erklären dürfte doch sehr schwierig werden. Am bestens suchst du dir daher jemanden, der den Job für dich übernimmt.

Durchdacht. Im ernst: Formulier die Frage nochmal so, dass der Einsatz einer Glaskugel nicht notwendig wird und unter Umständern wird dir dann auch geholfen.

Ja, gibt es. Dein Stichwort heisst Reflection. Wenn du allerdings gerade erst mit Java angefangen hast dürfte das alles andere als einfacher Stoff sein - das ganze ist recht komplex, dafür aber auch recht komplex.

Es gibt keine allgemeine Aussage oder Bewertung C# ist besser als C++ (oder andersherum). Beide haben (heute) unterschiedliche Anwendungsbereiche und damit auch unterschiedliche Anforderungen, was von den entsprechenden Applikationen erreicht werden soll. Zur Frage: Wie gesagt, wenn man sich nicht darauf versteift die Feinheiten einer bestimmten Sprache zu lernen sondern sich auf die Konzepte dahinter einlässt ist ein späterer Wechsel relativ schmerzlos möglich. Gleicher Fall wie oben: Allgemein nicht zu sagen. Der Großteil der Entwickler heutzutage wird sicherlich mit Cobol sehr wenig bis überhaupt nicht mehr in Kontakt kommen. Wer allerdings im Banken- oder Versicherungsbrereich zu tun hat wird sehr schnell merken, dass eine gefühlt antiquierte Sprache wie Cobol noch auf deutlich mehr Systemen im Einsatz ist, als man das landläufig annimmt. Wenn du also vor hast, die in diesem Bereich zu bewegen ist es sicherlich sinnvoll sich auch mit Cobol zu befassen. Die Spezialisten hierfür gehen inzwischen deutlich auf das Rentenalter zu (oder haben es bereits erreicht) und damit entsteht hier eine klare Chance sich zu positionieren. Ebenso, wenn man sich mit der Migration von Altsystemen beschäftigt - wer mehr von dem System weiß, das er da ablösen soll, der wird seinen Job besser machen als derjenige, der relativ unbedarft dort heran geht. Von daher: Cobol ist sicherlich nicht tot aber auch keine Must-Know-Technologie, ohne die man heute nicht mehr bestehen kann.

Sicherlich nicht in einem Satz und ausführlich. Immer eine gute Quelle: http://lmgtfy.com?q=unterschied+c%2B%2B++c%23 Natürlich. Eine Sprache ist immer nur die Spitze dessen, was es an Kenntnissen benötigt um Software zu entwickeln. Wer die Konzepte verstanden hat muss sicherlich die genaue Syntax und ein paar Feinheiten lernen aber ein Umstieg ist jederzeit möglich.

Natürlich werde ich mein Programm nie absolut fehlerfrei bekommen. Darum geht es auch nicht. Böse Zungen würden behaupten, das sei auch gar nicht das Ziel - wofür bräuchte ich schließlich sonst umfangreiche (und teilweise nicht unbedingt billige) Supportveträge. Ich kann allerdings potentielle Fehlerquellen und problematische Komponenten von vorneherein minimieren - und darum geht es ja.

Überhaupt nicht. Wenn die Firma sich nicht innerhalb einer vernünftigen Frist (spontan würde ich da mal zwei Wochen sagen) meldet, dann ist die Sache für mich erledigt und wird als "kein Interesse, anderer Firma zusagen" interpretiert.

Um das auf die Ursprungsfrage zu beziehen: Ist mit .net auch nicht anders. Und um es ein wenig weiter zu fassen: Kommt drauf an. Wenn ich eine große Serveranwendung habe, die ohnehin eine ganze Weile benötigt, bis alles initialisiert ist und in einem lauffähigen ist (oder der Rest der Applikation einfach wahnsinnig schneller ist als in vorkompiliertem Code) fällt die Startup-Zeit für die VM überhaupt nicht mehr ins Gewicht. Naja mono existiert ja, allerdings wäre ich doch sehr vorsichtig, ob ich so etwas in Produktion einsetzen würde. Es sind ja immer zwei Dinge, ob etwas funktioniert, oder ob es so gut funktioniert, dass man auch guten Gewissens einem Kunden gegenüber Fehlerfreiheit garantieren kann.

Tun sie das? Wie willst du wissen, welche Aussagekraft die hinter den Diagrammen liegenden Tests haben, wenn du dir nichtmal die Zeit nimmst, die Erklärung durchzulesen, die beschreibt, wie die Ergebnisse zustande gekommen sind? Nur anhand ein paar Excel-Diagrammen zu sagen "Ah ja, ich habe ja immer schon gewusst, dass A zu B führt" halte ich doch für reichlich unsachlich.

Ja? Dann gucken wir uns das dochmal genauer an:

Also was denn jetzt? Ist es schneller oder kommt es auf die Anwendung an? Und wenn es schneller ist kannst du das sicherlich mit Benchmarks belegen und nicht nur als Bauchgefühl vermuten, oder?

Die Bash löst '*' auf bevor das eigentliche Executable (in diesem Falle java) aufgerufen wird und übergibt alle auf die Wildcard passenden Dateien als Parameter an die main Funktion. It's not a bug, it's a feature ;-)

Also irgendwie sind das Begründungen auf sehr niedrigem Niveau. Wenn schon Vor- und Nachteile, dann auch bitte richtig. a) Eine pauschale Aussage wie Bytecode ist langsamer als vorkompilierter Code ist falsch. Es gibt Szenarien, in denen das der Fall ist, genauso wie es Szenarien gibt, wo Bytecode deutlich (!) schneller ist. auch .NET Code wird nicht direkt nativ kompiliert, sondern ebenfalls in Bytecode umgewandelt (Stichtwort: Common Intermediate Language). Der Punkt ist also weder ein Plus- noch ein Minuspunkt für eine der beiden verglichenen Technologien. Das gilt nicht nur für Java sondern für so ziemlich jede Programmiersprache (.NET included). Versuch mal ein .NET 3.0 optimiertes Programmm unter 1.1 auszuführen - viel Spaß. Vielleicht solltest du dich zunächst mal genauer mit den Technologien beschäftigen, bevor du solche gewagte Thesen aufstellst.

In wirklich Fan-Kreisen sicherlich. Aber damit lässt sich ja nicht das große Geld machen. Zwölf Jahre Entwicklung, da möchte ich mal sehen für welchen Preis man wieviele Kopien verkaufen müsste nur um aus dem Schlamassel wieder plusminus Null herauszukommen - von Gewinn mal ganz zu schweigen ;-)

Hast du dich denn schonmal mit der API-Dokumentation beschäftigt? Da hättest du z.B. http://java.sun.com/javase/6/docs/api/java/util/List.html#add(E) gefunde. Generell halte ich es für eine verdammt schlechte Vorgehensweise dir hier "bröckchenweise" die benötigten Informationen zu holen anstatt erst einmal in Ruhe die Dokumentation (z.B. auch http://tinyurl.com/ohzrjn) durchzulesen. Du willst schließlich auch verstehen, was die einzelnen Methodenaufrufe wirklich bewirken, oder?

Wenn du in der Lage bist die Aussage "geht nicht" so zu formulieren, dass man auch versteht was du probiert hast und was daran nicht geklappt hat - vielleicht. Solange du aber nicht mal das Problem beschreiben kannst: Nö!