# Fehlermeldungen die keiner braucht ...



## boesi (3. Sep 2007)

... 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 (3. Sep 2007)

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 (3. Sep 2007)

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 (3. Sep 2007)

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


----------



## Kim Stebel (3. Sep 2007)

oder so:

```
import java.util.Date;

class SqlDate extends java.sql.Date{}

public class MeineKlasse
{
  SqlDate sd;
  Date d;
}
```


----------



## boesi (3. Sep 2007)

P3AC3MAK3R hat gesagt.:
			
		

> 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 (3. Sep 2007)

Kim Stebel hat gesagt.:
			
		

> oder so:
> 
> ```
> [...]
> ...


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 (3. Sep 2007)

"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 (3. Sep 2007)

boesi hat gesagt.:
			
		

> :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.



			
				boesi hat gesagt.:
			
		

> :wink: und sowas hier
> 
> 
> 
> ...


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?



			
				boesi hat gesagt.:
			
		

> :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 (3. Sep 2007)

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


----------



## boesi (4. Sep 2007)

Murray hat gesagt.:
			
		

> 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). 



			
				Murray hat gesagt.:
			
		

> 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 (4. Sep 2007)

boesi hat gesagt.:
			
		

> Und was denkt sich der Compiler bei:
> 
> ```
> import java.sql.*;
> ...


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.



			
				boesi hat gesagt.:
			
		

> Murray hat gesagt.:
> 
> 
> 
> ...


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


----------



## SlaterB (4. Sep 2007)

Murray hat gesagt.:
			
		

> 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 (4. Sep 2007)

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 (4. Sep 2007)

byto hat gesagt.:
			
		

> 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 (4. Sep 2007)

Wildcard hat gesagt.:
			
		

> 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 (4. Sep 2007)

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

mpG
Tobias


----------



## merlin2 (4. Sep 2007)

Danke, das hab ich schon seit langem gesucht.


----------

