[java] Probleem met JDBC

Pagina: 1
Acties:

  • wackmaniac
  • Registratie: Februari 2004
  • Laatst online: 03-02 11:16
Ik heb zojuist jdbc geinstalleerd en volgens mij heb ik de instellingen goed staan, maar ik krijg telkens de foutmelding
java.lang.ClassNotFoundException: com.mysql.jdbc.Driver
Ik heb mysql-connector-java-5.0.3-bin-g.jar in de classpath gezet. Onderstaande stukje code heb ik hier op het forum gevonden:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import java.sql.*;

class customSql 
{
    public static void main(String[] args) 
    {
            String userName = "****";
            String password = "****";
            String url = "jdbc:mysql://localhost/film";
            try {
                // This is where we load the driver
                Class.forName("com.mysql.jdbc.Driver");
            }
            catch (Exception e) {
                System.out.println(e.toString());
                return;
            } 

        
        System.out.println("Hello world!");

    }
}


Weet iemand wat ik fout doe? Mijn verbinding met de database (gebruikersnaam + wachtwoord + hostadres) kloppen, maar dat maakt hiervoor volgens mij niet uit, want hij gaat de fout al in bij het laden van de driver. Kan iemand mij op weg of uit de brand helpen?>

Read the code, write the code, be the code!


  • den 150
  • Registratie: Oktober 2002
  • Niet online
wackmaniac schreef op maandag 25 september 2006 @ 20:14:
Ik heb mysql-connector-java-5.0.3-bin-g.jar in de classpath gezet.
Dan heb je daar toch iets fout gedaan, want dit zou moeten werken. Werk je vanuit een IDE, zoja welke? Probeer eens in command prompt vanuit je classes dir

code:
1
java -classpath .;path\to\mysql-connector.jar customSql

  • wackmaniac
  • Registratie: Februari 2004
  • Laatst online: 03-02 11:16
code:
1
2
3
C:\Documents and Settings\Timo Schinkel\Desktop\customSql>java -classpath .;C:\Program Files\Java\jdk1.5.0_08\jre\lib\ext\mysql-connector-java-5.0.3-bin-g.jar customSql
Exception in thread "main" java.lang.NoClassDefFoundError: Files\Java\jdk1/5/0_0
8\jre\lib\ext\mysql-connector-java-5/0/3-bin-g/jar


Nog steeds niet. Dien ik misschien nog extra software te installeren? Naast MySql, Java en JDBC?

Read the code, write the code, be the code!


  • coenbijlsma
  • Registratie: Augustus 2004
  • Niet online
edit:
beter lezen coenie!!

[ Voor 70% gewijzigd door coenbijlsma op 25-09-2006 20:50 ]


  • martennis
  • Registratie: Juli 2005
  • Laatst online: 16-01 14:17
heb je de jdbc ook geregistreerd bij de odbc van je systeem? (neem aan van wel)
en kun je eens in je jre-base-folder/ext/ folder kijken? staat de .jar file daar in?
run je het programma vanuit je IDE of start je je programma vanuit een gecreeerde .jar file?

  • NetForce1
  • Registratie: November 2001
  • Laatst online: 13-02 21:23

NetForce1

(inspiratie == 0) -> true

wackmaniac schreef op maandag 25 september 2006 @ 20:47:
code:
1
2
3
C:\Documents and Settings\Timo Schinkel\Desktop\customSql>java -classpath .;C:\Program Files\Java\jdk1.5.0_08\jre\lib\ext\mysql-connector-java-5.0.3-bin-g.jar customSql
Exception in thread "main" java.lang.NoClassDefFoundError: Files\Java\jdk1/5/0_0
8\jre\lib\ext\mysql-connector-java-5/0/3-bin-g/jar


Nog steeds niet. Dien ik misschien nog extra software te installeren? Naast MySql, Java en JDBC?
Probeer het classpath eens tussen quotes te zetten, zo te zien faalt hij op de spatie tussen Program en Files. Het zou echter niet uit moeten maken, de libs in de ext directory worden sowieso geladen. Als het met de quotes wel werkt zit je op een andere jvm te werken, dit kun je controleren door java -version uit te voeren op de console.

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"


  • NetForce1
  • Registratie: November 2001
  • Laatst online: 13-02 21:23

NetForce1

(inspiratie == 0) -> true

martennis schreef op maandag 25 september 2006 @ 20:56:
heb je de jdbc ook geregistreerd bij de odbc van je systeem? (neem aan van wel)
Dat lijkt me niet de bedoeling, jdbc is nl iets anders dan odbc. Indien je gebruik maakt van de jdbc-odbc bridge moet de odbc-datasource inderdaad geregistreerd zijn bij Windows. Tenzij je een full path opgeeft naar bijv. een Access db-file, dan hoeft dat volgens mij weer niet.

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"


  • martennis
  • Registratie: Juli 2005
  • Laatst online: 16-01 14:17
dat zou ik zo niet weten :) ik had een tut ergens gevonden waarbij ik eerst de bridge idd moest registeren

  • den 150
  • Registratie: Oktober 2002
  • Niet online
Die bridge is als je een odbc driver via jdbc wil aanspreken, dat is in dit geval niet nodig

probeer eens:
code:
1
C:\Documents and Settings\Timo Schinkel\Desktop\customSql>java -classpath ".;C:\Program Files\Java\jdk1.5.0_08\jre\lib\ext\mysql-connector-java-5.0.3-bin-g.jar" customSql


We weten trouwens nog niet of je met een IDE werkt (Eclipse, IntelliJ, Netbeans, ...) ?

  • writser
  • Registratie: Mei 2000
  • Laatst online: 10-02 20:24
Gebruik Eclipse, kun je 'm toevoegen aan je project?

Onvoorstelbaar!


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-02 11:06

Janoz

Moderator Devschuur®

!litemod

den 150 schreef op maandag 25 september 2006 @ 21:07:
Die bridge is als je een odbc driver via jdbc wil aanspreken, dat is in dit geval niet nodig

probeer eens:
code:
1
C:\Documents and Settings\Timo Schinkel\Desktop\customSql>java -classpath ".;C:\Program Files\Java\jdk1.5.0_08\jre\lib\ext\mysql-connector-java-5.0.3-bin-g.jar" customSql


We weten trouwens nog niet of je met een IDE werkt (Eclipse, IntelliJ, Netbeans, ...) ?
Zet dan wel even de quote op de juiste plek:
code:
1
C:\Documents and Settings\Timo Schinkel\Desktop\customSql>java -classpath .;"C:\Program Files\Java\jdk1.5.0_08\jre\lib\ext\mysql-connector-java-5.0.3-bin-g.jar" customSql

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Robtimus
  • Registratie: November 2002
  • Laatst online: 12-02 15:05

Robtimus

me Robtimus no like you

Je weet wel dat, als je de SDK installeert, er ook een JRE wordt geinstalleerd die op een andere plaats staat? Deze heeft zijn eigen ext directory, waar je dus ook je extra libs moet neerzetten. Dit is ook de JRE waar java.exe van wordt gebruikt. Meestal is het Program Files\Java\j2re1.5.xxxx

Zelf zet ik ze in allebei, dan weet ik zeker dat het werkt.

More than meets the eye
There is no I in TEAM... but there is ME
system specs


  • wackmaniac
  • Registratie: Februari 2004
  • Laatst online: 03-02 11:16
We weten trouwens nog niet of je met een IDE werkt (Eclipse, IntelliJ, Netbeans, ...) ?
Uhm, EditPlus2?

MOet tegenwoordig Eclipse gebruiken, ik ben nog steeds gewend gewoon een texteditor te gebruiken.

Zal de jar ook eens in de ext van de jre zetten. Resultaat:

code:
1
2
3
4
Exception in thread "main" java.lang.NoClassDefFoundError: org/aspectj/lang/Signature
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        at customSql.main(customSql.java:15)

[ Voor 31% gewijzigd door wackmaniac op 25-09-2006 21:34 ]

Read the code, write the code, be the code!


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-02 11:06

Janoz

Moderator Devschuur®

!litemod

Dan zal ik als ik jouw was toch maar echt eens overstappen op een IDE ipv een text editor. Er is zo enorm veel meer dan enkel syntax highlighting.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • wackmaniac
  • Registratie: Februari 2004
  • Laatst online: 03-02 11:16
Misschien een leuke discussie voor een ander tijdstip :)

Ik heb alles in een Eclipse project gezet en ik krijg dezelfde error. Als ik jdbc gebruik is het toch niet noodzakelijk om een odbc driver te hebben of begrijp ik dit nu helemaal verkeerd?

Read the code, write the code, be the code!


  • NetForce1
  • Registratie: November 2001
  • Laatst online: 13-02 21:23

NetForce1

(inspiratie == 0) -> true

Het lijkt erop dat je een debug build te pakken hebt.
You should not use the debug build of the driver unless instructed to do so when reporting a problem ors bug to MySQL AB, as it is not designed to be run in production environments, and will have adverse performance impact when used. The debug binary also depends on the Aspect/J runtime library, which is located in the src/lib/aspectjrt.jar file that comes with the Connector/J distribution.

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"


  • wackmaniac
  • Registratie: Februari 2004
  • Laatst online: 03-02 11:16
NewForce1, jij verdiend een standbeeld!

En ik verdien het om het in mijn eentje een berg op te dragen. Ik heb het verkeerd gelezen |:( |:( |:(

Hij werkt nu. Voor de mensen die hetzelfde probleem hebben: je moet de release versie hebben!

*schaam**schaam**schaam**schaam**schaam**schaam**schaam**schaam**schaam*

Read the code, write the code, be the code!


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-02 11:06

Janoz

Moderator Devschuur®

!litemod

Och, als je Eclipse, of een andere IDE met een realtime gecompileerde code, dan had je bij het includen van de library waarschijnlijk al de foutlmelding gehad dat je nog meer libs miste. Ik weet dat deze opmerking een enorm hoog achteraf gelul gehalte heeft, en zo bedoel ik het ook helemaal niet, maar ik raad je echt aan om enkel een text editor links te laten liggen en toch echt eens met een integrated development enviroment bezig gaat. Het neemt je zoveel werk uit handen en maakt het vooraf inzien van mogelijke problemen zo'n stuk makkelijker. Hierdoor kun je je tenminste volledig richten op het daadwerkelijk programmeren van je applicatie ipv allerlei randverschijnselen op te lossen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • wackmaniac
  • Registratie: Februari 2004
  • Laatst online: 03-02 11:16
Nou ik heb de code in zijn overgezet in Eclipse en daar krege ik nog niet de melding dat ik zaken miste. Misschien is dat omdat ik het automatisch aangeven van de opties in Eclipse aardig vertraagd heb (1 sec).

Ik heb altijd op Linux met emacs gewerkt en momenteel wordt er van mij verwacht dat ik met Eclipse werk. Echter ik vind Eclipse maar kut. Terwijl ik php standaard in Zend maak. Misschien ligt de structuur en interface van Eclipse mij gewoon niet zo :)

Ik vind alleen wel dat als ik snel een java dingetje inelkaar draai van hooguit twee bestanden dat een IDE als Eclipse een beetje een overkill is als ik het ook in een eenvoudige texteditor kan maken, maar dat is natuurlijk heel persoonlijk O-)

Read the code, write the code, be the code!


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 13-02 11:06

Janoz

Moderator Devschuur®

!litemod

Mwah, ikzelf werk liever met IntelliJ, maar in principe komt het ongeveer op hetzelfde neer. Sowieso was ik zelf vroeger ook zo. Gewoon make en emacs voor het ontwikkelen. In die tijd ooit eens JBuilder geprobeerd, maar dat zoog behoorlijk. De initiele overstap is vaak wat lastig. Voor mij heeft het ook even geduurd voordat ik het nut inzag. Het komt vooral omdat je, voordat je een project begint, dit eerst op moet zetten. Je kunt dus niet ff een stukje java kloppen en kijken wat het wordt. Als je dit echter 2 keer gedaan hebt krijg je hier ook wat handigheid in.

Nu is mijn productiviteit zo enorm veel hoger door realtime syntax checking, refactor tools, (smart) code completion en het automatisch toevoegen van de juiste import klassen. Probeer het gewoon eens een keer. Zet een projectje op (even werk, wel zo kaal mogelijk doen zodat je niet ineens een berg meuk op je af ziet komen) en werk er eens een beetje mee.

Dat eclipse niet gelijk herkende dat jou jdbc driver afhankelijk is van AspectJ zou trouwens ook kunnen komen omdat dit een feature van IntelliJ was en dat ik het door elkaar houd.

@hieronder: Inderdaad, daar had ik even over de runtime import heen gekeken :X

[ Voor 3% gewijzigd door Janoz op 26-09-2006 09:28 ]

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Verwijderd

Janoz schreef op maandag 25 september 2006 @ 22:52:
Dat eclipse niet gelijk herkende dat jou jdbc driver afhankelijk is van AspectJ zou trouwens ook kunnen komen omdat dit een feature van IntelliJ was en dat ik het door elkaar houd.
Eclipse checked niet de (aanwezigheid van) dependencies die jars zelf weer hebben, alleen of de code die jij aan bouwen bent (dwz, alle source files in je project) hun directe dependencies hebben.

Je kunt met JDT bijvoorbeeld onvolledige classes bouwen. dat zijn classes die nog "unresolved compilation errors" hebben. Deze kun je packagen in een jar, en dan in een ander project toevoegen aan je class path. In dit geval worden er geen errors voor in die jars aangegeven.

Daarnaast is de gebruikte Class.forName 'slechts' een library functie. Toevallig wel 1 die erg standaard is, maar een library functie nevertheless. Een compiler doet geen uitspraken over de correctheid van de aanroep van library calls. In verreweg de meeste gevallen kan dit ook helemaal niet.

Het argument van de hier gebruikte Class.forName is dan weliswaar een constante, maar de uitkomst is dynamisch afhankelijk van de gebruikte class loader. De compiler kan niet een stuk van jouw programma simuleren om te kijken of er ergens een bepaalde class-loader gebruikt gaat worden. Hogere level tools (bv een Java versie van Plint) doen dit wel d.m.v. een soort pattern detectie in je code, eventueel aan de hand van opgegeven profielen.

In een Java EE omgeving komt bijvoorbeeld de .jar met de JDBC driver helemaal niet in je project classpath voor. Deze bevind zich in een speciale directory van de Application Server. Hierbij vraag je dan overigens eigenlijk wel meestal een connectie op via JDNI en doe je niet direct een Class.forName.

Een lang verhaal, maar om het kort samen te vatten:

Class.forName is een runtime functie die runtime resolved wordt. Er hoeft geen statische linking naar een bepaalde class gedaan te worden en dus hoeft/kan de compiler hier ook niks voor (te) checken.

IntelliJ kijkt waarschijnlijk wel naar de imports van al je .jars in je project en checked of die in je project resolved kunnen worden.
Pagina: 1