Fehlermeldungen die keiner braucht ...

[boesi]

... nämlich:

The method convertToString(Date) in the type Tools is not applicable for the arguments (Date)

HÄÄÄÄ? :bahnhof:

:idea: Ahh ich hatte nur java.sql.Date importiert. Also noch flugs ein import java.util.Date dazu ... aber was passiert nun?

Tools.java:4: java.sql.Date is already defined in a single-type import
import java.util.Date;

Muss ich hier doch tatsächlich den *-import nehmen - ich glaub ich spinne ...

Ach nee ich kann auf die Import-Statements komplett verzichten - na das nenn ich doch mal elegantes und leicht verständliches Design :applaus:


cu boesi - Hilfe ich will hier weg :autsch:

 

[P3AC3MAK3R]

Wenn Du zwei Klassen importierst, die den gleichen Namen haben (java.sql.Date, java.util.Date), mußt Du den Namenskonflikt auflösen, indem Du bei deren Verwendung die gewünschte Klasse über ihren kompletten Pfad referenzierst.

 

[The_S]

Naja, wenn du mehrere Klassen verwendest, die identisch heißen, musst du natürlich das komplette package mit angeben, um eine Eindeutigkeit zu gewährleisten. Wo ist jetzt das Problem?

 

[SlaterB]

oder: eine Klasse importieren und normal verwenden und lediglich die zweite Klasse jeweils komplett ausschreiben

 

[Kim Stebel]

oder so:

import java.util.Date;

class SqlDate extends java.sql.Date{}

public class MeineKlasse
{
  SqlDate sd;
  Date d;
}

 

[boesi]

Wenn Du zwei Klassen importierst, die den gleichen Namen haben (java.sql.Date, java.util.Date), mußt Du den Namenskonflikt auflösen, indem Du bei deren Verwendung die gewünschte Klasse über ihren kompletten Pfad referenzierst.

Na nen Problem hab ich nicht mehr - funktioniert ja ...

• :wink: aber zB könnte bei der ersten Fehlermeldung das Package angeben werden, wo er das Date hernimmt. Wenn schon "static typing", dann könnte man doch auch sinnvolle Meldungen generieren.
  :wink: und sowas hier

  import java.sql.Date;
  import java.util.Date;

  sollte ohne jeden Kommentar funktionieren
  :wink: und das ich kein import brauch, wenn ich im Quelltext java.sql.Date verwende, ist zwar logisch aber letztlich einfach nur noch verwirrend

cu boesi

 

[boesi]

oder so:

[...]
class SqlDate extends java.sql.Date{}
[...]

Wie beurteilst du dieses Konstrukt denn hinsichtlich Softwarequalität?

Ich vergleich das jetzt mal blödsinnigerweise mit Maschinenbau - verwende soviele Standardbauteile wie nur irgendwie möglich.


cu boesi

 

[Kim Stebel]

"Wie beurteilst du dieses Konstrukt denn hinsichtlich Softwarequalität?"
Das ist ein Hack, der einem das Leben leichter macht. Hat irgendwer etwas anderes behauptet?

 

[Murray]

:wink: aber zB könnte bei der ersten Fehlermeldung das Package angeben werden, wo er das Date hernimmt. Wenn schon "static typing", dann könnte man doch auch sinnvolle Meldungen generieren.

Das stimmt, die Fehlermeldungen hätte man sicher besser mit voll qalifizierten Klassennamen versehen; dann wäre sofort klar gewesen, was nicht passt.

:wink: und sowas hier

import java.sql.Date;
import java.util.Date;

sollte ohne jeden Kommentar funktionieren

Wie soll das funktionieren? Ein Import-Statement ist doch nur eine Art Ersetzungsvorschrift für den Compiler ("füge überall da java.util.Date ein, wo im Sourcecode Date ohne Package steht"). Wie soll der Compiler jetzt wissen, welches Date jeweils gemeint ist?

:wink: und das ich kein import brauch, wenn ich im Quelltext java.sql.Date verwende, ist zwar logisch aber letztlich einfach nur noch verwirrend[/list]

Das verstehe nicht - wenn du nicht gerade eine Klasse mit dem Package java.sql schreibst, dann musst du auch java.sql.Date importieren (sofern das nicht deine IDE automatisch gemacht hat)

 

[Roar]

mit javafx ginge sowas:
import java.util.Date;
import java.sql.Date as SqlDate;

 

[boesi]

Wie soll das funktionieren? Ein Import-Statement ist doch nur eine Art Ersetzungsvorschrift für den Compiler ("füge überall da java.util.Date ein, wo im Sourcecode Date ohne Package steht"). Wie soll der Compiler jetzt wissen, welches Date jeweils gemeint ist?

Und was denkt sich der Compiler bei:

import java.sql.*;
import java.util.*;

Dann kommt erst bei der Zeile "Date date = new Date(); eine Meldung von wegen Mehrdeutigkeit. Wobei das aber eigentlich Quatsch ist, weil es den Konstruktor java.sql.Date() gar nicht gibt. Ausser ich importier wieder explizit eines der beiden Dates (wobei bei der Zeile oben natürlich nur ein "import java.util.Date;" Sinn ergibt, sonst gibt's wieder ne andere Fehlermeldung).

Das verstehe nicht - wenn du nicht gerade eine Klasse mit dem Package java.sql schreibst, dann musst du auch java.sql.Date importieren (sofern das nicht deine IDE automatisch gemacht hat)

Noe also ich kann sehr wohl schreiben "java.util.Date date = new java.util.Date();" ohne java.util.Date oder java.util.* zu importieren. Ist ja auch klar, weil keine "Ersetzungsvorschrift" nötig ist.


cu boesi

PS: Über son poppeliges import kann man ganz schön viel diskutieren ...

 

[Murray]

Und was denkt sich der Compiler bei:

import java.sql.*;
import java.util.*;

Dann kommt erst bei der Zeile "Date date = new Date(); eine Meldung von wegen Mehrdeutigkeit. Wobei das aber eigentlich Quatsch ist, weil es den Konstruktor java.sql.Date() gar nicht gibt. Ausser ich importier wieder explizit eines der beiden Dates (wobei bei der Zeile oben natürlich nur ein "import java.util.Date;" Sinn ergibt, sonst gibt's wieder ne andere Fehlermeldung).

Diese Importe von ganzen Packages sind m.E. keine besonders gute Idee der Sprachentwickler gewesen; dadurch kann es ja passieren, dass eigentlich funktionierender Code mit einer neuen Version einer Library nicht mehr funktioniert, nur weil eine neue Klassen eingeführt wurde, die man implizit mit importiert. Vielleicht wird ja aus purer Bosheit mit JDBC 7.0 die Klasse java.sql.List eingeführt ...

Außerdem machen solche Package-Importe die Analyse von Abhängigkeiten schwieriger - heute können das zwar die IDE normalerweise, aber trotzdem kann es manchmal hilfreich sein, die Verwender einer Klasse durch einfache lexikalische Untersuchung der Sourcen (z.B. mit grep) herausfinden zu können.

Das verstehe nicht - wenn du nicht gerade eine Klasse mit dem Package java.sql schreibst, dann musst du auch java.sql.Date importieren (sofern das nicht deine IDE automatisch gemacht hat)

Noe also ich kann sehr wohl schreiben "java.util.Date date = new java.util.Date();" ohne java.util.Date oder java.util.* zu importieren. Ist ja auch klar, weil keine "Ersetzungsvorschrift" nötig ist.

OK, hatte ich nicht richtig verstanden; natürlich kann man sich den Import sparen, wenn man den voll qualifizierten Klassennamen verwendet.

 

[SlaterB]

Diese Importe von ganzen Packages sind m.E. keine besonders gute Idee der Sprachentwickler gewesen; dadurch kann es ja passieren, dass eigentlich funktionierender Code mit einer neuen Version einer Library nicht mehr funktioniert, nur weil eine neue Klassen eingeführt wurde, die man implizit mit importiert. Vielleicht wird ja aus purer Bosheit mit JDBC 7.0 die Klasse java.sql.List eingeführt ...

immerhin dürften dann eindeutige Fehlermeldungen kommen, die man leicht korrigieren kann,
wäre also kein großes Unheil, sondern nur aufgeschobene Arbeit, die man ansonsten zur Programmierzeit hätte,

was ist schlimmer?
bei jedem Programm in der Welt Arbeitsaufwand x
oder die hypothetische Möglichkeit, bei einer neuen Java-Version einen verschwindend geringen Anteil von alten Programmen mit Aufwand y anzupassen,
wobei y durchaus höher als x liegt, aber nur unwesentlich höher?

 

[byte]

Praktisch siehts doch so aus, dass Import ganzer Packages nur dann interessant ist (weil es Arbeit erleichtert), wenn man mit nem proprietären Editor entwickelt und die Imports per Hand schreiben muss. Betrifft also wohl niemanden, der professionell mit Java entwickelt. Eine vernünftige IDE organisiert die Imports selbst und wird nie ein ganzes Package importieren, weil es die Performance senkt (die VM lädt Klassen, die gar nicht benötigt werden).

 

[Wildcard]

Eine vernünftige IDE organisiert die Imports selbst und wird nie ein ganzes Package importieren, weil es die Performance senkt (die VM lädt Klassen, die gar nicht benötigt werden).

Unsinn. Nur die Imports die tatsächlich verwendet werden, müssen geladen werden.
In Eclipse zum Beispiel kannst du auf festlegen ab welcher Anzahl von Imports aus dem gleichen Package das ganze Package importiert werden soll.

 

[merlin2]

In Eclipse zum Beispiel kannst du auf festlegen ab welcher Anzahl von Imports aus dem gleichen Package das ganze Package importiert werden soll.

Wo?

 

[Tobias]

Project->Properties->Java Code Style->Organize Imports->Number of imports needed for .*

mpG
Tobias

 

[merlin2]

Danke, das hab ich schon seit langem gesucht.