JAVA - Could not find or load main class....

[gwbuiter74]

Hallo allemaal,

Ik heb ook mijn eerste stappen gezet in het programmeren met Java... Althans, ik doe een poging.
Maar ik loop gelijk al vast.

Heb al veel info gelezen over bovenstaande foutmelding, en wat YouTube tutorials bekeken voor een mogelijke oplossing, maar wat ik ook al probeerde in te stellen.... niets werkt

Wat is er gaande?
Ik heb een java programma geschreven (even als voorbeeld: HelloWorld.java)
compilen gaat prima, maar zodra ik de class file wil starten dan krijg ik dus de melding:
Error: Could not find or load main class HelloWorld"

Wat heb ik al gedaan?
in de command prompt getest of zowel "java" als "javac" commando's werken. en dat doen ze.

Via configuratiescherm>systeemeigenschappen>geavanceerd>omgevingsvariabelen

bij systeemvariabelen nieuwe variabele ingesteld.

naam:JAVA_HOME
waarde: c:\java\jdk1.8.0_92 (<waar bij mij java geïnstalleerd staat) ook geprobeerd met C:\java\jdk.1.8.0_92\bin; maar ook dat hielp niet.

path gewijzigd, en als toevoeging vooraan gezet: %JAVA_HOME%\bin;

Ergens op een YouTube video gaf iemand aan ook de CLASSPATH in te stellen.
Die heb ik gezet op de lokatie waar mijn opgeslagen classfiles staan (in mijn geval C:\java\ProjectFiles)
maar hier heb ik ook al geprobeerd de java jdk, maar ook de jre directory in te vullen....

Nouja, kortom...ik heb alles nu wel geprobeerd maar ik ben nog geen steek verder. Gezien de foutmelding vermoed ik zelf dat ik ergens de CLASSPATH settings mogelijk moet wijzigen in iets anders....

Overigens nog een kleine kanttekening....
Ik start overigens de cmd prompt vanuit de desbetreffende map waar mijn java files staan, doe dan SHIFT+rechter muisknop, en kies vervolgens voor: "opdrachtvenster hier openen". Dan zit ik namelijk direct in de juiste map....leek mij wel zo handig.

Ik gebruik overigens Windows 7, maar in Windows 10 op mijn andere pc zit ik eveneens met hetzelfde probleem.

Wie helpt mij verder? want ik kom er niet meer uit!

[johnkeates]

Het probleem is dat je je HelloWorld probeert te starten zonder dat Java je main kan vinden. Je kan je main specificeren op de commandline en dan werkt het wel.

[ Voor 26% gewijzigd door johnkeates op 02-05-2016 23:51 ]

[gwbuiter74]

En hoe doe ik dat? Kan ik dat niet permanent instellen?

[johnkeates]

gwbuiter74 schreef op maandag 02 mei 2016 @ 23:55:
En hoe doe ik dat? Kan ik dat niet permanent instellen?

Nee.

[gwbuiter74]

Ik neem aan dat je doelt op: java -cp . java ?
Ook dan krijg ik dezelfde error melding.

[Gerco]

Stel dat je code er als volgt uit ziet:

Java: HelloWorld.java

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, World!");
  }
}

Dan moet je die als volgt kunnen compileren naar een .class file:

code:

> javac HelloWorld.java

En als volgt uitvoeren:

code:

> java -cp . HelloWorld
Hello, World!

Met -cp vertel je java waar het de .class files kan vinden. "." betekent "de huidige directory" en "HelloWorld" is de naam van de class die je wilt uitvoeren (de naam van je bestand zonder .java).

[ Voor 54% gewijzigd door Gerco op 03-05-2016 00:30 ]

[gwbuiter74]

Dank Gerco voor je uitleg. Dat was mij allemaal duidelijk. en alles gaat prima...tot ik bij het uitvoeren kom, dan gaat het fout....met of zonder "-cp" toevoeging...en ook netjes HelloWorld ingetypt zonder .java (of .class)

Daarbij heb ik ook deze tutorial al doorlopen...(en nog wel meerdere overigens) .https://www.youtube.com/watch?v=vhBNV8no4CI

[ Voor 22% gewijzigd door gwbuiter74 op 03-05-2016 00:43 ]

[Gerco]

Heb je geprobeerd om dit exacte voorbeeld uit te voeren? Indien dat het geval is, kun je eens kijken of er een .class bestand is gegenereerd naast je .java bestand?

Post anders eens een volledig log van je command line waar je de volgende commando's uitvoert:

code:

javac HelloWorld.java
dir
java -cp . HelloWorld

[gwbuiter74]

Jazeker, de class file staat er gewoon, in dezelfde map als waar ook de .java files staan.

ok, dit heb ik gedaan:

public class Helloworld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}

opgeslaan als "Helloworld.java"

vervolgens compilen: C:'java\javac Helloworld.java, wat mij vervolgens netjes de "Helloworld.class file oplevert.

[ Voor 62% gewijzigd door gwbuiter74 op 03-05-2016 01:10 ]

[RobIII]

Hoe ziet je class eruit? En dan bedoel ik vooral je main signature... post eens wat relevante code?

[ Voor 17% gewijzigd door RobIII op 03-05-2016 00:59 ]

[gwbuiter74]

Ik weet even niet zo gauw hoe ik hier een screenshot kan plaatsen, maar het is exact zoals ik hierboven heb omschreven. maar ik heb het overigens met alle class files....ook van anderen.

[gwbuiter74]

1: public class Helloworld {
2: public static void main(String[] args) {
3: System.out.println("Hello world!");
4: }
5: }


Ik denk ook niet daar hier de fout zit, anders had ik immers wel een compile error gekregen weet ik intussen.

[ Voor 32% gewijzigd door gwbuiter74 op 03-05-2016 01:13 ]

[.oisyn]

Code posten doe je zo:

[code=java]
... jouw code hier ...
[/code]

wordt:

Java:

... jouw code hier ...

[ Voor 30% gewijzigd door .oisyn op 03-05-2016 01:16 ]

[gwbuiter74]

Java:

1: public class Helloworld {
 2:    public static void main(String[] args) {
 3:      System.out.println("Hello world!");
 4:    }
 5:  }

[.oisyn]

Je gebruikt geen hoofdletter W in de class Helloworld, maar de errorcode in de topicstart suggereert dat ie dat wel moet hebben.

[Gerco]

Je hebt inderdaad een class geschreven die "Helloworld" heet, maar je probeert een class uit te voeren die "HelloWorld" moet heten. Java is hoofdlettergevoelig en de namen moeten dus exact overeenkomen, hoofdletters inclusief.

[gwbuiter74]

Klopt ja, maar dat was even een vlotte typfout...in de file zelf staat het wel goed.
Ik heb voor het gemak maar even een nieuwe .java file gemaakt. met als class "Hello", en de bestandsnaam eveneens "Helllo" gegeven. (met hoofdletter)

dus:

Java:

 1: public class Hello  {
 2:    public static void main(String[] args) {
 3:      System.out.println("Hello world!");
 4:    }
 5:  }

opgeslaan als "Hello.java"


commando: "javac Hello.java" (compiler maakt er een Hello.class file van) en die staat ook netjes in dezelfde directory

vervolgens voor het uitvoeren: "java Hello" (of "java -cp . Hello") maar de foutmelding blijft.

Hoe is het mogelijk dat ogenschijnlijk zo iets kleins zoveel ellende kan veroorzaken. en dan ben ik nog maar amper begonnen... Maar goed, de oplossing heb ik nog steeds niet.

[ Voor 11% gewijzigd door gwbuiter74 op 03-05-2016 09:36 ]

[hackerhater]

Tip : gebruik een IDE als Netbeans of Eclipse om java in te programmeren.
Die regelen dit gedoe voor je ipv moeite te moeten doen via de commandline.
Het via de commandline kunnen is mooie kennis, maar wellicht te hoog gegrepen voor een beginnende programmeur.

[Merethil]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 09:25:
Klopt ja, maar dat was even een vlotte typfout...in de file zelf staat het wel goed.
Ik heb voor het gemak maar even een nieuwe .java file gemaakt. met als class "Hello", en de bestandsnaam eveneens "Helllo" gegeven. (met hoofdletter)

dus:

Java:

 1: public class Hello  {
 2:    public static void main(String[] args) {
 3:      System.out.println("Hello world!");
 4:    }
 5:  }

opgeslaan als "Hello.java"


commando: "javac Hello.java" (compiler maakt er een Hello.class file van) en die staat ook netjes in dezelfde directory

vervolgens voor het uitvoeren: "java Hello" (of "java -cp . Hello") maar de foutmelding blijft.

Hoe is het mogelijk dat ogenschijnlijk zo iets kleins zoveel ellende kan veroorzaken. en dan ben ik nog maar amper begonnen... Maar goed, de oplossing heb ik nog steeds niet.

Kan je eens een dump doen van de resultaten van de volgende commando's:

code:

javac -version

code:

java -version

?

[Niekfct]

Heb je een environment variable CLASSPATH?

Je kunt ook eens proberen om in plaats van

code:

java -cp . Hello

de classpath expliciet te specificeren:

code:

java -cp ~/Desktop/javatest Hello

[ Voor 68% gewijzigd door Niekfct op 03-05-2016 09:58 ]

[gwbuiter74]

Niekfct schreef op dinsdag 03 mei 2016 @ 09:54:
Heb je een environment variable CLASSPATH?

Ja, heb ik ook. (zie ergens een van mijn eerdere berichten verder hier boven)

[Niekfct]

Merethil schreef op dinsdag 03 mei 2016 @ 10:00:
[...]


Heb je trouwens die lijnnummers ook in de file staan wanneer je de Hello.java file opent met notepad?

Dan zou er al een compiler error optreden.

Wellicht kun je je .class file met ons delen? Dan kunnen wij even kijken of wij het wel kunnen runnen

[ Voor 186% gewijzigd door Niekfct op 03-05-2016 10:02 ]

[Merethil]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 09:57:
[...]


Ja, heb ik ook. (zie ergens een van mijn eerdere berichten verder hier boven)

Heb je trouwens die lijnnummers ook in de file staan wanneer je de Hello.java file opent met notepad?

Edit: Nvm, dan gooit javac een error. Hoe dan ook, voer eens de commando's van mijn vorige post uit?

[ Voor 14% gewijzigd door Merethil op 03-05-2016 10:01 ]

[TIGER79]

heb je ook alle benodigde libraries geimporteerd ?

[Niekfct]

TIGER79 schreef op dinsdag 03 mei 2016 @ 10:02:
heb je ook alle benodigde libraries geimporteerd ?

Dat zou niet van toepassing moeten zijn met een Hello world programma.

[TIGER79]

nope, zat weer te checken en inderdaad met System.out.println is dat niet nodig...
My bad

[Giesber]

Bij mij compileert en werkt het programma prima, daar lijkt niets mis mee te zijn. Dat er een class file gemaakt wordt geeft ook al aan dat de compilatie lukt.

De fout "Error: Could not find or load main class HelloWorld" geeft ook aan dat java op zich gevonden wordt, maar dat java de class niet vindt.

Het enige wat ik mij kan indenken is dat er toch iets vanuit een verkeerde directory wordt gestart, maar dat is raar omdat de class file wel in de goede directory verschijnt.

Een andere mogelijkheid is dat er een Hello class zonder main method gevonden wordt alvorens hij de class in de huidige directory vindt, maar dat zou ook raar zijn. Zeker omdat HelloWorld ook niet werkte.

[Arie-]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 09:25:
[...]

Java:

 1: public class Hello  {
 2:    public static void main(String[] args) {
 3:      System.out.println("Hello world!");
 4:    }
 5:  }

[...]

Aangezien je hier 1:, 2: etc. voor hebt staan heb je deze code niet ge-copy-paste* denk ik. Wat is je werkelijke code, heb je er misschien een package declaratie bovenin waarbij de map waarin zoekt naar je .class niet overeenkomt met je package declaratie?

*Geen idee hoe je dat schrijft en te lui om op te zoeken

[gwbuiter74]

Merethil schreef op dinsdag 03 mei 2016 @ 10:00:
[...]


Heb je trouwens die lijnnummers ook in de file staan wanneer je de Hello.java file opent met notepad?

Edit: Nvm, dan gooit javac een error. Hoe dan ook, voer eens de commando's van mijn vorige post uit?

bij deze:

c:\Windows\System32>java -version
java version "1.8.0_92"
Java(TM) SE Runtime Enviroment (build 1.8.0_92-b14)
Java Hotspot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)


c:\Windows\System32>javac -version
javac 1.8.0_92

[gwbuiter74]

Arie- schreef op dinsdag 03 mei 2016 @ 10:38:
[...]

Aangezien je hier 1:, 2: etc. voor hebt staan heb je deze code niet ge-copy-paste* denk ik. Wat is je werkelijke code, heb je er misschien een package declaratie bovenin waarbij de map waarin zoekt naar je .class niet overeenkomt met je package declaratie?

*Geen idee hoe je dat schrijft en te lui om op te zoeken

Java:

    public class Hello  {
    public static void main(String[] args) {
      System.out.println("Hello world!");
       }
  }

[laurens0619]

Ik denk dat je het moet zoeken in de config van je systeem. Ik zou gaan experimenteren met de classpath

Als je tutorial voorbeelden download, kan je die wel uitvoeren?

[gwbuiter74]

laurens0619 schreef op dinsdag 03 mei 2016 @ 10:51:
Ik denk dat je het moet zoeken in de config van je systeem. Ik zou gaan experimenteren met de classpath

Als je tutorial voorbeelden download, kan je die wel uitvoeren?

Nee, ook die kan ik niet uitvoeren.

[Verwijderd]

Wat als je letterlijk de volgende drie commando's in een CMD paste (op een andere locatie dan waar je andere Hello.java stond)?

code:

echo public class Hello { public static void main(String[] args) { System.out.println("Hello world!"); } } > Hello.java
javac Hello.java
java -cp . Hello

[RobIII]

Euh... waar sla je die .java bestanden op? Zit je niet gewoon in een-of-andere directory a-la program files of system32 te werken waar je mogelijk problemen hebt met rechten e.d.?

[Mohius]

Ik denk dat ik een antwoord voor je heb (niet dat ik een java guru ben overigens).

Java:

package com.company;

public class Hello {

    public static void main(String[] args) {

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

Let op de package name: com.company

Voer ik het volgende commando uit:

code:

D:\Projects\Java\test\src\com\company>java -cp . Hello

dan krijg ik exact dezelfde foutmelding als de topic starter.

Als ik echter 2 stappen terug ga in het pad, dus naar de src folder en dan het volgende commando uitvoer:

code:

D:\Projects\Java\test\src>java -cp . com.company.Hello

Krijg ik netjes de uitvoer:

code:

Hello world!

Nou heb ik al tijden niet met java gewerkt maar ik meen mij te herinneren dat vroeger (ten tijde van versie java 5) een fully qualified package name geen vereiste was om een programma te kunnen uitvoeren.

Edit:

Ik heb net een nieuw test gevalletje opgezet zonder package name en dan werkt de code precies zo als je zou mogen verwachten. Het lijkt er dus op dat de topic starter een package name gedefinieerd heeft in de source file.

[ Voor 11% gewijzigd door Mohius op 03-05-2016 12:16 ]

[gwbuiter74]

RobIII schreef op dinsdag 03 mei 2016 @ 12:06:
Euh... waar sla je die .java bestanden op? Zit je niet gewoon in een-of-andere directory a-la program files of system32 te werken waar je mogelijk problemen hebt met rechten e.d.?

Nee hoor, om het gemakkelijk te houden heb ik alle files in map C:\java staan.

[Merethil]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 15:16:
[...]


Nee hoor, om het gemakkelijk te houden heb ik alle files in map C:\java staan.

Wat is de volledige inhoud van je gecreëerde .class file?

[Arias45]

Toen ik net starte met het Compilen van java code, had ik naar wat ik weet een soortgelijk probleem.

Bij mij lag het aan de PATH locatie van de Java installatie.

Misschien dat onderstaand stuk van de Oracle link helpt?

https://docs.oracle.com/j...al/environment/paths.html

[Hydra]

Weet je 100% zeker dat het compilen goed ging en heb je 100% zeker de volledige inhoud van je .java file gepost? Voordat je opnieuw compiled delete dan eerst even al je class files.

Deze code moet werken:

Java:

public class HelloWorld {
    public static void main(String[] argv) {
        System.out.println("Hello world");
    }
}

Save deze als HelloWorld.java in een lege directory. Check met dir of dit de enige file is in die directory. Compile 'em dan met "javac HelloWorld.java". Als het goed is heb je dan een HelloWorld.java en een HelloWorld.class file. Dan moet je 'em kunnen runnen met simpelweg "java HelloWorld". Je hoeft geen classpath op te geven.

Als dit niet lukt post dan even screenshots van je directory inhoud en de melding die je krijgt.

Let wel: dit soort dingen komen gewoon 100% exact. Zorg dus dat je met je commandline in de juiste dir zit e.d. en post ook exact je sourcecode as is.

Arias45 schreef op dinsdag 03 mei 2016 @ 16:11:
Bij mij lag het aan de PATH locatie van de Java installatie.

Hij had al gechecket met java -version / javac -version.

[ Voor 19% gewijzigd door Hydra op 03-05-2016 16:35 ]

[hackerhater]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 15:16:
Nee hoor, om het gemakkelijk te houden heb ik alle files in map C:\java staan.

Hier zou je niet moeten kunnen schrijven als gebruiker!
Draai software niet als admin!

[LinuX-TUX]

Hydra schreef op dinsdag 03 mei 2016 @ 16:31:
Weet je 100% zeker dat het compilen goed ging en heb je 100% zeker de volledige inhoud van je .java file gepost? Voordat je opnieuw compiled delete dan eerst even al je class files.

Deze code moet werken:

Java:

public class HelloWorld {
    public static void main(String[] argv) {
        System.out.println("Hello world");
    }
}

[...]


Hij had al gechecket met java -version / javac -version.

Mee eens, maar ook een klein detail, tegenwoordig staan javac en java in system32. Nu weten we nog steeds niet 100% zeker of z'n PATH wel correct staat. De test / check had hij buiten deze directory moeten doen ivm %JAVA_HOME%. Verschillende versies java draaien kan echt een drama zijn op Windows, onder linux toch net even wat makkelijker tegenwoordig.

edit:

javac staat er gelukkig niet, wel javaw javaws. Maar punt blijft nog even staan met andere java environment variabelen.

[ Voor 7% gewijzigd door LinuX-TUX op 03-05-2016 16:40 ]

[Hydra]

hackerhater schreef op dinsdag 03 mei 2016 @ 16:37:
Hier zou je niet moeten kunnen schrijven als gebruiker!

Want?

[hackerhater]

Hydra schreef op dinsdag 03 mei 2016 @ 16:40:
Want?

Omdat je, tenzij je zelf de rechten van die map aangepast hebt, buiten je documents root zit en dus buiten de ruimte waar je normaal schrijfrechten hebt?
Je documents-root is iets van C:\Document and users\gebruikersnaam\.
Pin me er niet op vast, ik gebruik geen Windows.

Zeker gezien hoe weinig programmeer-ervaring TS heeft hoort ie absoluut niet als admin de software te draaien. Je kan namelijk heel simpel via JAVA belangrijke bestanden slopen en daarmee je OS.

@TS
Weet je zeker dat niet constant tegen de Windows beveiliging aan hikt omdat je op een locatie zit te werken waar je niet aan hoort te komen?

[Merethil]

hackerhater schreef op dinsdag 03 mei 2016 @ 16:45:
[...]


Omdat je, tenzij je zelf de rechten van die map aangepast hebt, buiten je documents root zit en dus buiten de ruimte waar je normaal schrijfrechten hebt?
Je documents-root is iets van C:\Document and users\gebruikersnaam\.
Pin me er niet op vast, ik gebruik geen Windows.

Zeker gezien hoe weinig programmeer-ervaring TS heeft hoort ie absoluut niet als admin de software te draaien. Je kan namelijk heel simpel via JAVA belangrijke bestanden slopen en daarmee je OS.

@TS
Weet je zeker dat niet constant tegen de Windows beveiliging aan hikt omdat je op een locatie zit te werken waar je niet aan hoort te komen?

Maar in hoeverre denk je dat zijn commando iets schrijft op die locatie? Als hij wel met javac een .class kan aanmaken, maar die niet kan uitvoeren omdat java zegt deze niet te kunnen vinden zou het hoogstens een issue kunnen zijn met lees-rechten, maar dan had javac weer niet gewerkt.

Daarnaast: Als je de cmdprompt opent via shift-rightclick opent hij niet in een Admin-modus, dus kans is dat hij ook niet als Admin zijn code probeert te draaien.
Maar zelfs, echt zelfs al had hij het in Admin mode gedraaid... Is dat zo erg wanneer je letterlijk niets anders doet dan een System.out.println()? Het is niet alsof dát je systeem gaat opblazen.

[Hydra]

hackerhater schreef op dinsdag 03 mei 2016 @ 16:45:
Pin me er niet op vast, ik gebruik geen Windows.

Dat blijkt want het is gewoon niet waar. Heb het ff op m'n werklaptop getest en je kunt gewoon een java dir maken in je door en daar files in maken zonder elevated rechten nodig te hebben.

[hackerhater]

Merethil schreef op dinsdag 03 mei 2016 @ 16:48:
Maar zelfs, echt zelfs al had hij het in Admin mode gedraaid... Is dat zo erg wanneer je letterlijk niets anders doet dan een System.out.println()? Het is niet alsof dát je systeem gaat opblazen.

Nee, maar dit is iets wat afgeleerd hoort te worden. Als ie later bestanden gaat bewerken en dan een programmeerfout maakt........
Niet voor niets wordt in de *nix-wereld gezegd : "Don't work as root"

@Hydra
Probeer dat eens als pure gebruiker en niet als verkapte admin onder UAC (default user). Dan krijg je doodleuk permission denied, en terecht. Tenminste ik ga er vanuit dat MS hun rechten systeem nu wel goed heeft gemaakt.
Je hebt als gebruiker simpelweg niks te zoeken buiten je eigen documenten-map.


Btw de problemen van TS kunnen heel goed hiermee te maken hebben. De kans is namelijk groot dat deze map niet in zijn path staat.

[ Voor 7% gewijzigd door hackerhater op 03-05-2016 16:58 ]

[gwbuiter74]

LinuX-TUX schreef op dinsdag 03 mei 2016 @ 16:37:
[...]
Mee eens, maar ook een klein detail, tegenwoordig staan javac en java in system32. Nu weten we nog steeds niet 100% zeker of z'n PATH wel correct staat. De test / check had hij buiten deze directory moeten doen ivm %JAVA_HOME%. Verschillende versies java draaien kan echt een drama zijn op Windows, onder linux toch net even wat makkelijker tegenwoordig.

edit:

javac staat er gelukkig niet, wel javaw javaws. Maar punt blijft nog even staan met andere java environment variabelen.

Als ik check hoe bij mij de CLASSPATH is ingesteld via C:\ echo %CLASSPATH%
dan geeft hij aan dat ik hem nu heb staan op c:\java\jdk1.8.0_92\lib

[Hydra]

hackerhater schreef op dinsdag 03 mei 2016 @ 16:57:

Btw de problemen van TS kunnen heel goed hiermee te maken hebben. De kans is namelijk groot dat deze map niet in zijn path staat.

Dat hoeft ook niet. Z'n JDK/JRE /bin directories moeten in de PATH var staan.

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 18:55:
Als ik check hoe bij mij de CLASSPATH is ingesteld via C:\ echo %CLASSPATH%
dan geeft hij aan dat ik hem nu heb staan op c:\java\jdk1.8.0_92\lib

Mijn suggestie gemist?

[ Voor 30% gewijzigd door Hydra op 03-05-2016 19:16 ]

[gwbuiter74]

Hydra schreef op dinsdag 03 mei 2016 @ 16:31:
Weet je 100% zeker dat het compilen goed ging en heb je 100% zeker de volledige inhoud van je .java file gepost? Voordat je opnieuw compiled delete dan eerst even al je class files.

Deze code moet werken:

Java:

public class HelloWorld {
    public static void main(String[] argv) {
        System.out.println("Hello world");
    }
}

Save deze als HelloWorld.java in een lege directory. Check met dir of dit de enige file is in die directory. Compile 'em dan met "javac HelloWorld.java". Als het goed is heb je dan een HelloWorld.java en een HelloWorld.class file. Dan moet je 'em kunnen runnen met simpelweg "java HelloWorld". Je hoeft geen classpath op te geven.

Als dit niet lukt post dan even screenshots van je directory inhoud en de melding die je krijgt.

Let wel: dit soort dingen komen gewoon 100% exact. Zorg dus dat je met je commandline in de juiste dir zit e.d. en post ook exact je sourcecode as is.


[...]


Hij had al gechecket met java -version / javac -version.

Exact opgevolgd zoals je hierboven hebt omschreven, maar helaas nog steeds dezelfde melding.
hieronder maar even een link met de screenshot.

http://prnt.sc/azud4d

[laurens0619]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 19:37:
[...]


Exact opgevolgd zoals je hierboven hebt omschreven, maar helaas nog steeds dezelfde melding.
hieronder maar even een link met de screenshot.

http://prnt.sc/azud4d

had je nu al geprobeerd het absolute classpath erbij op te geven?
dus java -cp c:\test HelloWorld

[ Voor 4% gewijzigd door laurens0619 op 03-05-2016 19:46 ]

[Oyster]

Het is HelloWWWWorld ...

java -cp . HelloWorld dus.
En hou je ClassName en source en bytecode filenames alsjeblieft hetzelfde.

public class HelloWorld{...}

HelloWorld.java
HelloWorld.class

[ Voor 82% gewijzigd door Oyster op 03-05-2016 19:52 ]

[Arie-]

1) Wat Oyster zegt!
2) post je classpath eens in [code ] blokken
3) post je path eens in [code ] blokken*
4) ik vertrouw je screenshot niet, volgens windows eindigt je bestand met .java in kleine letters, maar Notepad++ laat hoofdletters zien.
5) Wat Oyster zegt!

*Ik denk dat je path niet het probleem is, de executables java en javac worden immers gevonden.

[Creepy]

Kom op... na al die posts en informatie zie je (weer) een hoofdletter over het hoofd.......

[IceM]

In je screenshot mist HelloWorld een hoofdletter, daarom werkt het niet. Uitvoeren als Java -cp . HelloWorld zou moeten werken

Edit: oeps, 2e pagina niet gezien

[ Voor 12% gewijzigd door IceM op 03-05-2016 21:45 ]

[gwbuiter74]

Oyster schreef op dinsdag 03 mei 2016 @ 19:43:
Het is HelloWWWWorld ...

java -cp . HelloWorld dus.
En hou je ClassName en source en bytecode filenames alsjeblieft hetzelfde.

public class HelloWorld{...}

HelloWorld.java
HelloWorld.class

Eindelijk lukt het mij met bovenstaande commando wel.
In dit geval dan dus: java -cp . HelloWorld

maaaaar....dan ook alleen maar voor deze classfile...
probeer ik een andere, een class die ik heb behorende bij een tutorial, dan begint hij opnieuw weer met de melding.

@Arie, Ik weet niet precies wat je bedoelt met "post je classpath eens in [code ] blokken"

[Oyster]

Post anders even een screenshot net zoals de laatste die je hebt gepost.

Ik vermoed dat het dus weer fout gaat met je ClassName en filenames. Dit soort dingen moet je als (ook als beginnend) programmeur echt heel snel onder controle en in de gaten hebben. Echt essentieel.

[gwbuiter74]

Oyster schreef op dinsdag 03 mei 2016 @ 22:16:
Post anders even een screenshot net zoals de laatste die je hebt gepost.

Ik vermoed dat het dus weer fout gaat met je ClassName en filenames. Dit soort dingen moet je als (ook als beginnend) programmeur echt heel snel onder controle en in de gaten hebben. Echt essentieel.

http://prnt.sc/azwpjo

[armageddon_2k1]

En probeer dan eens java -cp examples.Y2k ?

[Oyster]

java -cp . examples.Y2k

Staat ook al eerder in dit topic omschreven.

Edit: Hier dus door Mohius.

[ Voor 51% gewijzigd door Oyster op 03-05-2016 22:31 ]

[Patrickdev]

Nog een laatste ding om op te letten; als je de package example gebruikt, verwacht ie ook dat het bestand zich in de map example bevindt. Voorbeeld:

C:\example\Y2k.java:

Java:

package example;
public class Y2k {
    public static void main(String[] args) {
        System.out.println("Hiep hoi");
    }
}

Dan moet je uitvoeren (let op de current dir)

code:

C:\>javac example\Y2k.java

C:\>java example.Y2k
Hiep hoi

[gwbuiter74]

Oyster schreef op dinsdag 03 mei 2016 @ 22:29:
java -cp . examples.Y2k

Staat ook al eerder in dit topic omschreven.

Edit: Hier dus door Mohius.

Klopt, maar die had ik ook al geprobeerd.

http://prnt.sc/azww79

[gwbuiter74]

Patrickdev schreef op dinsdag 03 mei 2016 @ 22:37:
Nog een laatste ding om op te letten; als je de package example gebruikt, verwacht ie ook dat het bestand zich in de map example bevindt. Voorbeeld:

C:\example\Y2k.java:

Java:

package example;
public class Y2k {
    public static void main(String[] args) {
        System.out.println("Hiep hoi");
    }
}

Dan moet je uitvoeren (let op de current dir)

code:

C:\>javac example\Y2k.java

C:\>java example.Y2k
Hiep hoi

Aha...die ga ik gelijk even uitproberen...ik laat het zo weten of het gelukt is..

[Oyster]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 22:38:
[...]


Klopt, maar die had ik ook al geprobeerd.

http://prnt.sc/azww79

Dan zal je ook Y2k.class in een example/ directory moeten zetten. En dan vanaf de parent van example/ dat commando uitvoeren. Maar ik zou packages voor nu laten voor wat het is en het uit je source halen.

code:

[622] Oyster@mbp10 ~/example > java -cp ../ example.Y2k
Hiep hoi
[623] Oyster@mbp10 ~/example > ls
total 8
drwxr-xr-x   3 Oyster  staff   102 May  3 22:40 ./
drwxr-xr-x+ 87 Oyster  staff  2958 May  3 22:40 ../
-rw-r--r--   1 Oyster  staff   416 May  3 22:39 Y2k.class
-rw-r--r--   1 Oyster  staff     0 May  3 22:45 Y2k.java
[624] Oyster@mbp10 ~/example >

[ Voor 32% gewijzigd door Oyster op 03-05-2016 22:46 ]

[gwbuiter74]

Oyster schreef op dinsdag 03 mei 2016 @ 22:42:
[...]


Dan zal je ook Y2k.class in een example/ directory moeten zetten. En dan vanaf de parent van example/ dat commando uitvoeren. Maar ik zou packages voor nu laten voor wat het is en het uit je source halen.

code:

[622] Oyster@mbp10 ~/example > java -cp ../ example.Y2k
Hiep hoi
[623] Oyster@mbp10 ~/example > ls
total 8
drwxr-xr-x   3 Oyster  staff   102 May  3 22:40 ./
drwxr-xr-x+ 87 Oyster  staff  2958 May  3 22:40 ../
-rw-r--r--   1 Oyster  staff   416 May  3 22:39 Y2k.class
-rw-r--r--   1 Oyster  staff     0 May  3 22:45 Y2k.java
[624] Oyster@mbp10 ~/example >

Ik heb voor nu maar de package regel weggehaald, en opnieuw geprobeerd. Als ik dan "java -cp . Y2k" doe, dan werkt het wel.

[Hydra]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 19:37:
Exact opgevolgd zoals je hierboven hebt omschreven,

Nee dat doe je niet. Zoals ik al aangaf komt dit precies en schrijf jij Helloworld terwijl de class name HelloWorld is. java is case sensitive zoals de meeste programmeertalen. Ik raad je aan beter op de details te letten anders kom je niet ver

[kahraman11]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 19:37:
[...]


Exact opgevolgd zoals je hierboven hebt omschreven, maar helaas nog steeds dezelfde melding.
hieronder maar even een link met de screenshot.

http://prnt.sc/azud4d

"Java HelloWorld" werkt misschien wel?

[Hydra]

laurens0619 schreef op dinsdag 03 mei 2016 @ 19:43:
had je nu al geprobeerd het absolute classpath erbij op te geven?
dus java -cp c:\test HelloWorld

Dat is nergens voor nodig. Sterker nog; met dit soort dingen kun je makkelijk fouten maken dus kan hij beter niet doen. De huidige dir staat gewoon op 't classpath.

Dus even aan iedereen die hier met die -cp switch zit te kloten: gewoon niet doen. Dat is alleen maar een extra ding waar de TS fouten mee kan maken. Het is, als je gewoon in de dir zit waar je .java en .class files staan, nergens voor nodig een classpath op te geven. Idem als hij de correcte layout voor packages gebruikt.

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 22:54:
Ik heb voor nu maar de package regel weggehaald, en opnieuw geprobeerd. Als ik dan "java -cp . Y2k" doe, dan werkt het wel.

Je moet ook niet lukraak packages toe gaan voegen zonder dat je snapt hoe ze werken.

Een package mapt direct op een directory structuur. Als je een class een package 'mypackage' geeft moet deze in de mypackage directory staan en compile en run je hem vanuit de root. Als je package com.mijndomein.mijnlibrary is, staat hij vanuit je root in de /com/mijndomein/mijnlibrary directory. Deze zaken moeten gewoon matchen anders vindt je runtime de packages gewoon niet.

Dit is dus wat er misgegaan is: je bent onachtzaam geweest wat betreft de spelling van zaken en het toepassen van packages. Zoals ik al aangaf: dit komt gewoon 100% exact dus als je niet oplet op wat je doet werkt het gewoon niet.

[ Voor 39% gewijzigd door Hydra op 04-05-2016 09:39 ]

[LinuX-TUX]

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 18:55:
[...]


Als ik check hoe bij mij de CLASSPATH is ingesteld via C:\ echo %CLASSPATH%
dan geeft hij aan dat ik hem nu heb staan op c:\java\jdk1.8.0_92\lib

PATH en CLASSPATH zijn helaas niet hetzelfde.
PATH is een windows system environment variabele welke definieert waar alle standaard systeem brede executables gevonden kunnen worden.

CLASSPATH is voor java zelf en wil je eigenlijk per running process in de hand houden.

De vraag is dus nog steeds heel reeel, als je in een dos-prompt ergens BUITEN C:\Windows\system32 en c:\java\jdk####\ om het volgende intikt:

code:

cd \
set
java -version
javac -version
where java
where javac

wat rolt er dan uit?

[LinuX-TUX]

Hydra schreef op woensdag 04 mei 2016 @ 09:26:
[...]
Zoals ik al aangaf: dit komt gewoon 100% exact dus als je niet oplet op wat je doet werkt het gewoon niet.

Ik vermoed dat je gelijk hebt:

code:

gideon@laptop ~ $ echo "public class Test { public static void main(String[] args) { System.out.println(\"Hello World\"); } }" >> Test.java && javac Test.java && java Test && java test
Hello World
Error: Could not find or load main class test
gideon@laptop ~ $

Shit, wilde dit editen/toevoegen bij m'n vorige post

[ Voor 53% gewijzigd door LinuX-TUX op 04-05-2016 10:20 ]

[gwbuiter74]

Hydra schreef op woensdag 04 mei 2016 @ 09:26:
[...]


Dat is nergens voor nodig. Sterker nog; met dit soort dingen kun je makkelijk fouten maken dus kan hij beter niet doen. De huidige dir staat gewoon op 't classpath.

Dus even aan iedereen die hier met die -cp switch zit te kloten: gewoon niet doen. Dat is alleen maar een extra ding waar de TS fouten mee kan maken. Het is, als je gewoon in de dir zit waar je .java en .class files staan, nergens voor nodig een classpath op te geven. Idem als hij de correcte layout voor packages gebruikt.


[...]


Je moet ook niet lukraak packages toe gaan voegen zonder dat je snapt hoe ze werken.

Een package mapt direct op een directory structuur. Als je een class een package 'mypackage' geeft moet deze in de mypackage directory staan en compile en run je hem vanuit de root. Als je package com.mijndomein.mijnlibrary is, staat hij vanuit je root in de /com/mijndomein/mijnlibrary directory. Deze zaken moeten gewoon matchen anders vindt je runtime de packages gewoon niet.

Dit is dus wat er misgegaan is: je bent onachtzaam geweest wat betreft de spelling van zaken en het toepassen van packages. Zoals ik al aangaf: dit komt gewoon 100% exact dus als je niet oplet op wat je doet werkt het gewoon niet.

Gek genoeg krijg ik het alleen werkende als ik de -cp switch wel gebruik. Zonder werkt het bij mij niet.
Overigens heb ik niets met de packages gedaan. dit was een voorbeeld .java file, behorende bij een cursus. Heb ik niet aan gesleuteld. Ik heb ze juist weggehaald, waarna het ineens wel werkte, maar dan wel ook alleen als ik de -cp switch erbij gebruik

[Merethil]

LinuX-TUX schreef op woensdag 04 mei 2016 @ 10:18:
[...]

Ik vermoed dat je gelijk hebt:

code:

gideon@laptop ~ $ echo "public class Test { public static void main(String[] args) { System.out.println(\"Hello World\"); } }" >> Test.java && javac Test.java && java Test && java test
Hello World
Error: Could not find or load main class test
gideon@laptop ~ $

Shit, wilde dit editen/toevoegen bij m'n vorige post

Je hoeft het niet te vermoeden, Java is gewoon case sensitive. Net als veel andere programmeertalen. Het jammere hieraan is dat dit al letterlijk meerdere malen is gemeld in dit topic, waarbij de eerste keer al direct een uurtje of 2 na openen van het topic was:

.oisyn schreef op dinsdag 03 mei 2016 @ 01:33:
Je gebruikt geen hoofdletter W in de class Helloworld, maar de errorcode in de topicstart suggereert dat ie dat wel moet hebben.

Dit is trouwens echt één van de beginselen van de gemiddelde Java-tutorial, die geven aan dat je ze één op één moet overnemen, inclusief hoofdletters want Java is case sensitive.

[LinuX-TUX]

Merethil schreef op woensdag 04 mei 2016 @ 10:25:
[...]


Je hoeft het niet te vermoeden, Java is gewoon case sensitive. Net als veel andere programmeertalen. Het jammere hieraan is dat dit al letterlijk meerdere malen is gemeld in dit topic, waarbij de eerste keer al direct een uurtje of 2 na openen van het topic was:


[...]


Dit is trouwens echt één van de beginselen van de gemiddelde Java-tutorial, die geven aan dat je ze één op één moet overnemen, inclusief hoofdletters want Java is case sensitive.

Vermoeden dat dat de oorzaak is geweest, dat het case sensitive is weet ik maar al tegoed ... zie linux =)

[gwbuiter74]

Merethil schreef op woensdag 04 mei 2016 @ 10:25:
[...]


Je hoeft het niet te vermoeden, Java is gewoon case sensitive. Net als veel andere programmeertalen. Het jammere hieraan is dat dit al letterlijk meerdere malen is gemeld in dit topic, waarbij de eerste keer al direct een uurtje of 2 na openen van het topic was:


[...]


Dit is trouwens echt één van de beginselen van de gemiddelde Java-tutorial, die geven aan dat je ze één op één moet overnemen, inclusief hoofdletters want Java is case sensitive.

Dat is mij intussen al wel duidelijk geworden. mijn fout, ik zal daar wat beter op letten.

[Merethil]

LinuX-TUX schreef op woensdag 04 mei 2016 @ 10:25:
[...]

Vermoeden dat dat de oorzaak is geweest, dat het case sensitive is weet ik maar al tegoed ... zie linux =)

Je hoeft gewoon niets te vermoeden. Als je zijn screenshots bekeken hebt zie je dat hij het consistent fout bleef doen door niet te kijken naar case sensitivity, zelfs al is het al meerdere malen gemeld dat hij dat moest doen.
Daarnaast: Prima dat Linux case sensitive is, maar dat houdt niet in dat je automatisch ook weet dat Java dat is

[Hydra]

gwbuiter74 schreef op woensdag 04 mei 2016 @ 10:23:
Gek genoeg krijg ik het alleen werkende als ik de -cp switch wel gebruik. Zonder werkt het bij mij niet.

Dat is dus gewoon niet zo. Je bent met symptoombestrijding bezig omdat je zaken niet begrijpt. Zonder -cp switch werkt het prima als je maar zorgt dat je in de juiste dir zit. Sidenote: zie onder.

Probeer nu gewoon eens de voorbeeld code die ik gaf (HelloWorld.java) zonder -cp switch met de juiste casing.

Overigens heb ik niets met de packages gedaan. dit was een voorbeeld .java file, behorende bij een cursus.

Maakt niet uit. Je begrijpt niet hoe ze werken en gaat dan maar lukraak sleutelen. Dat is niet hoe dit werkt. Eerst snappen. Dan doen. Als door het doen blijkt dat je het niet snapt ga je terug naar stap 1.

gwbuiter74 schreef op dinsdag 03 mei 2016 @ 18:55:
Als ik check hoe bij mij de CLASSPATH is ingesteld via C:\ echo %CLASSPATH%
dan geeft hij aan dat ik hem nu heb staan op c:\java\jdk1.8.0_92\lib

Heb je die zelf aangemaakt? Zo ja; waarom? Want nu heb je waarschijnlijk je huidige dir UIT je classpath geknikkerd door hier mee te kloten.

Je wil echt geen CLASSPATH environment var aanmaken.

To quote this page:

The preferred way to specify the class path is by using the -cp command line switch. This allows the CLASSPATH to be set individually for each application without affecting other applications. Setting the CLASSPATH can be tricky and should be performed with care.

Je CLASSPATH environment var verwijderen dus.

[ Voor 35% gewijzigd door Hydra op 04-05-2016 10:36 ]

[LinuX-TUX]

Merethil schreef op woensdag 04 mei 2016 @ 10:27:
[...]


Je hoeft gewoon niets te vermoeden. Als je zijn screenshots bekeken hebt zie je dat hij het consistent fout bleef doen door niet te kijken naar case sensitivity, zelfs al is het al meerdere malen gemeld dat hij dat moest doen.
Daarnaast: Prima dat Linux case sensitive is, maar dat houdt niet in dat je automatisch ook weet dat Java dat is

Meer in de zin van: ik weet niet beter ( en snap niet waarom ze bij Mac tegenwoordig ook case-insensitive aanbieden )

[Merethil]

LinuX-TUX schreef op woensdag 04 mei 2016 @ 10:34:
[...]
Meer in de zin van: ik weet niet beter ( en snap niet waarom ze bij Mac tegenwoordig ook case-insensitive aanbieden )

Om te voorkomen dat mensen die niet nadenken over dat soort zaken in de knoei komen, gok ik (lees: De gemiddelde consument). En dan krijg je dat mensen er overheen lezen en dus problemen krijgen wanneer het wel belangrijk is

[ Voor 3% gewijzigd door Merethil op 04-05-2016 10:35 ]

[.oisyn]

Lichtelijk offtopic, maar wat gebeurt er onder Windows als je twee classes hebt die alleen qua casing verschillen in dezelfde package? Aangezien het Windows file system niet case sensitive is...

[LinuX-TUX]

.oisyn schreef op woensdag 04 mei 2016 @ 10:41:
Lichtelijk offtopic, maar wat gebeurt er onder Windows als je twee classes hebt die alleen qua casing verschillen in dezelfde package? Aangezien het Windows file system niet case sensitive is...

Op disk niveau kunnen ze in ieder geval niet bestaan denk ik, zelfs met GIT enorme problemen gehad toen iemand zich bedacht "owh wacht, dat moet een hoofdlettertje zijn" en deze wijziging terug pushde naar de git repo. Geloof dat dit git bugje inmiddels is opgelost.

Meestal heb je hier overigens geen last van omdat alles toch in een jar geplaatst wordt. Zal zo even de proef op de som nemen voor je

[Hydra]

LinuX-TUX schreef op woensdag 04 mei 2016 @ 10:46:
Op disk niveau kunnen ze in ieder geval niet bestaan denk ik

Jawel:

Java:

public class Test {
  public static class TestA {
  }

  public static class Testa {
  }
}

Kan alleen het effect niet testen. Enige Windows install die ik heb is m'n klantlaptop en die is dichtgetimmerd. Onder linux werkt dit prima en krijg je Test$TestA.class en Test$Testa.class.

[Merethil]

.oisyn schreef op woensdag 04 mei 2016 @ 10:41:
Lichtelijk offtopic, maar wat gebeurt er onder Windows als je twee classes hebt die alleen qua casing verschillen in dezelfde package? Aangezien het Windows file system niet case sensitive is...

Net even getest met een Hello.java

Java:

class Hello {

}

en een Hello2.java

Java:

class hello {

}

Hij overschrijft je Hello.class met de nieuwste die je genereert, waarna je niet meer weet of je hem moet aanroepen als

code:

java . Hello

of

code:

java . hello

Hydra schreef op woensdag 04 mei 2016 @ 10:52:
[...]


Jawel:

Java:

public class Test {
  public static class TestA {
  }

  public static class Testa {
  }
}

Kan alleen het effect niet testen. Enige Windows install die ik heb is m'n klantlaptop en die is dichtgetimmerd. Onder linux werkt dit prima en krijg je Test$TestA.class en Test$Testa.class.

Dit ook even geprobeerd, genereert een Test.class en een Test$TestA.class, maar geen Test$Testa.class.
Het lijkt er dus op dat dat niet lekker werkt onder Windows en je dat in de gaten moet houden.

Edit: Erger is; als ik nu Test$TestA aanroep, krijg ik de return van Test$Testa. Dat kan best een hoop gezeik geven...

Bovenstaande edit was fout. Als ik Test$TestA aanroep werkt dat niet (al bestaat Test$TestA.class wel), want hij pakt de implementatie van Test$Testa en stopt die in de classfile van Test$TestA. Dit zal komen vanwege een top-to-bottom manier van werken, maar het zorgt er dus gewoon voor dat je veel verwarring krijgt.

[ Voor 47% gewijzigd door Merethil op 04-05-2016 11:01 ]

[LinuX-TUX]

Hydra schreef op woensdag 04 mei 2016 @ 10:52:
[...]


Jawel:

Java:

public class Test {
  public static class TestA {
  }

  public static class Testa {
  }
}

Kan alleen het effect niet testen. Enige Windows install die ik heb is m'n klantlaptop en die is dichtgetimmerd. Onder linux werkt dit prima en krijg je Test$TestA.class en Test$Testa.class.

En in een archive kunnen ze OOK naast elkaar bestaan ja. Maar de vraag is, wat als ze alle 2 daar staan EN gecompiled klaar staan

Merethil schreef op woensdag 04 mei 2016 @ 10:53:
[...]


Net even getest met een Hello.java

Java:

class Hello {

}

en een Hello2.java

Java:

class hello {

}

Hij overschrijft je Hello.class met de nieuwste die je genereerd, waarna je niet meer weet of je hem moet aanroepen als

code:

java . Hello

of

code:

java . hello

Ik denk dat in context van een archive geen problemen meer zijn, op disk daarentegen gaat Windows best vreemd stuiteren omdat hij (volgens mij) de verkeerde oppakt en java dat niet snapt:


Natuurlijk wel even moeten aanmaken op een linux share:

code:

gideon@laptop ~/Gideon/test $ javac test.java
gideon@laptop ~/Gideon/test $ javac Test.java
gideon@laptop ~/Gideon/test $ ls
test.class  Test.class  test.java  Test.java
gideon@laptop ~/Gideon/test $ java test
Hello world
gideon@laptop ~/Gideon/test $ java Test
Hello World
gideon@laptop ~/Gideon/test $

edit:

Sterker nog, ik denk dat je zo'n project niet eens kan bouwen op Windows. Het 'bestaan' van dezelfde namen kan windows nog mee omgaan, maar het moment dat de compile slag gedaan wordt naar classes, zal er maar 1 classe overleven welke weer in de archive geplaatst gaat worden Spuit11

[ Voor 7% gewijzigd door LinuX-TUX op 04-05-2016 11:35 ]

[Hydra]

Merethil schreef op woensdag 04 mei 2016 @ 10:53:
Dit ook even geprobeerd, genereert een Test.class en een Test$TestA.class, maar geen Test$Testa.class.
Het lijkt er dus op dat dat niet lekker werkt onder Windows en je dat in de gaten moet houden.

Of gewoon geen windows gebruiken

Dus wel een leuk "fuck you" geintje om je zooi windows-incompatible te maken

LinuX-TUX schreef op woensdag 04 mei 2016 @ 10:59:
En in een archive kunnen ze OOK naast elkaar bestaan ja. Maar de vraag is, wat als ze alle 2 daar staan EN gecompiled klaar staan

Wat is je punt? Je kunt mijn voorbeeld op Windows gewoon niet compileren. Of ze in een 'archive' staan of whatever maakt niet uit.

[ Voor 30% gewijzigd door Hydra op 04-05-2016 11:01 ]

[Merethil]

Hydra schreef op woensdag 04 mei 2016 @ 11:00:
[...]


Of gewoon geen windows gebruiken

Dus wel een leuk "fuck you" geintje om je zooi windows-incompatible te maken


[...]


Wat is je punt? Je kunt mijn voorbeeld op Windows gewoon niet compileren. Of ze in een 'archive' staan of whatever maakt niet uit.

Voor een platform dat zichzelf ziet als "write once, run anywhere" is dit wel jammer. Nou moet ik zeggen: Kan Java erg weinig aan doen, Windows zou eigenlijk eens moeten ophouden met die case insensitivity. En te korte padlengte. En eigenlijk nog veel meer.
Helaas heeft niet iedereen de mogelijkheid over te stappen op Linux (op mijn werk willen ze alles van Microsoft hebben draaien (behalve Java dus...) omdat we geen systeembeheerders hebben die Linux kennen (jippie....))
Waarom we nog steeds geen C# gebruiken in dat geval... Tja, al sla je me dood.

[LinuX-TUX]

Hydra schreef op woensdag 04 mei 2016 @ 11:00:
[...]


Of gewoon geen windows gebruiken

Dus wel een leuk "fuck you" geintje om je zooi windows-incompatible te maken

Ken je deze al?

public class Test {
public static void main(String[] args) { System.out.println("Hello World");
}
}

[...]
Wat is je punt? Je kunt mijn voorbeeld op Windows gewoon niet compileren. Of ze in een 'archive' staan of whatever maakt niet uit.

Punt is, dat ook al kan je het niet onder windows compileren, kan je het nog wel voorgeschoteld krijgen uit een wereld waar case sensitivity wel bestaat. Nu weten we dus: zowel compile als runtime ga je vroeg of laat onderuit, TENZIJ het al in een archive bestaat, want dan is Windows lookup uitgesloten en is de JVM ervoor verantwoordelijk welke wel case sensitive is

---

Toch altijd leuk om even dingen helemaal te checken, we zijn immers tweakers om een reden, alles moet bewezen en gemeten worden
Test.java

Java:

public class Test {
    public static void main(String[] args) {
        test.showMessage();
        showMessage();
    }
    public static void showMessage() {
        System.out.println("Hello World!");
    }
}

test.java

Java:

public class test {
    public static void main(String[] args) {
        Test.showMessage();
        showMessage();
    }
    public static void showMessage() {
        System.out.println("hello world");
    }
}

Dan krijgen we onder linux:

code:

gideon@laptop ~/NetBeansProjects/Personal/CaseTest/target $ java -cp CaseTest-0-SNAPSHOT.jar test
Hello World!
hello world
gideon@laptop ~/NetBeansProjects/Personal/CaseTest/target $ java -cp CaseTest-0-SNAPSHOT.jar Test
hello world
Hello World!
gideon@laptop ~/NetBeansProjects/Personal/CaseTest/target $

en onder windows

code:

Z:\test>java -cp CaseTest-0-SNAPSHOT.jar test
Hello World!
hello world

Z:\test>java -cp CaseTest-0-SNAPSHOT.jar Test
hello world
Hello World!

.oisyn schreef op woensdag 04 mei 2016 @ 11:19:
[...]

Misschien moeten programmeertalen gewoon ophouden met case sensitivity. Ik vind het nogal een boude statement, alsof je van een case sensitive file system nou zo gelukkig wordt. Erg gebruikersvriendelijk is het iig niet.

En natuurlijk kan Java hier wel wat aan doen. Ze wisten bij ontwerp al dat er platforms waren waarbij het filesystem niet case sensitive is. Je kunt hier dus alternatieven voor verzinnen. Bijvoorbeeld dat je niet alleen <classname>.class opent, maar ook <classname>@*.class als <classname>.class niet de juiste class oplevert.

Toepassing van case sensitivity of niet, met gebruiksvriendelijkheid als achterliggende gedachte, is altijd al een discussie punt geweest. Net als 'null' als waarde in Java. Als we dan toch, in dit geval semantiek, gaan beginnen, dan blijven we bezig .

[ Voor 53% gewijzigd door LinuX-TUX op 04-05-2016 11:32 ]

[.oisyn]

Merethil schreef op woensdag 04 mei 2016 @ 11:03:
Windows zou eigenlijk eens moeten ophouden met die case insensitivity.

Misschien moeten programmeertalen gewoon ophouden met case sensitivity. Ik vind het nogal een boude statement, alsof je van een case sensitive file system nou zo gelukkig wordt. Erg gebruikersvriendelijk is het iig niet.

En natuurlijk kan Java hier wel wat aan doen. Ze wisten bij ontwerp al dat er platforms waren waarbij het filesystem niet case sensitive is. Je kunt hier dus alternatieven voor verzinnen. Bijvoorbeeld dat je niet alleen <classname>.class opent, maar ook <classname>@*.class als <classname>.class niet de juiste class oplevert. En dan heb je bijvoorbeeld een [e-mail] voor "Testa" en [e-mail] voor "TestA".

[ Voor 16% gewijzigd door .oisyn op 04-05-2016 11:32 ]

[Merethil]

.oisyn schreef op woensdag 04 mei 2016 @ 11:19:
[...]

Misschien moeten programmeertalen gewoon ophouden met case sensitivity. Ik vind het nogal een boude statement, alsof je van een case sensitive file system nou zo gelukkig wordt. Erg gebruikersvriendelijk is het iig niet.

En natuurlijk kan Java hier wel wat aan doen. Ze wisten bij ontwerp al dat er platforms waren waarbij het filesystem niet case sensitive is. Je kunt hier dus alternatieven voor verzinnen. Bijvoorbeeld dat je niet alleen <classname>.class opent, maar ook <classname>@*.class als <classname>.class niet de juiste class oplevert.

Ik denk dat de gebruiksvriendelijkheid ook de reden is dat OS X er nu een aanpassing in heeft gemaakt, maar vanuit het oogpunt als developer vind ik het zelf juist heel onhandig; elk systeem doet 't (misschien) anders en het betekent dat je rekening moet gaan houden met of je specifieke programmeertaal het voor je vergemakkelijkt door de case sensitivity van het OS aan te houden, of die van de programmeertaal zelf als je basisfuncties (e.g. opzoeken van files, uitlezen van files/registers etc) uitvoert.

Nee, ik vind het voor normaal gebruik prima dat Windows CI is, maar soms erger ik me er gewoon aan dat het weer net anders is bij Windows dan bij de duizenden Linux of *NIX-varianten.

[.oisyn]

LinuX-TUX schreef op woensdag 04 mei 2016 @ 11:07:
Toepassing van case sensitivity of niet, met gebruiksvriendelijkheid als achterliggende gedachte, is altijd al een discussie punt geweest.

Ik had het over het filesystem, dat per definitie een enorm veel grotere groep gebruikers kent dan alleen programmeurs . In een programmeertaal kom je nog weg met bepaalde restricties gezien de doelgroep.

[Hydra]

Merethil schreef op woensdag 04 mei 2016 @ 11:03:
Voor een platform dat zichzelf ziet als "write once, run anywhere" is dit wel jammer.

Java pretendeert niet dat er geen platformverschillen zijn. De class files zijn prima overdraagbaar. Dat er bepaalde files niet aangemaakt / gevonden kunnen worden is bij alle platformen zo. In server land een redelijk non-issue trouwens; daar is het toch Linux dat de klok slaat.

Ook is het een beetje een non-issue. Als je twee classes met dezelfde naam en alleen andere casing hebt in je package doe je sowieso iets fout.

.oisyn schreef op woensdag 04 mei 2016 @ 11:19:
En natuurlijk kan Java hier wel wat aan doen. Ze wisten bij ontwerp al dat er platforms waren waarbij het filesystem niet case sensitive is. Je kunt hier dus alternatieven voor verzinnen. Bijvoorbeeld dat je niet alleen <classname>.class opent, maar ook <classname>@*.class als <classname>.class niet de juiste class oplevert. En dan heb je bijvoorbeeld een [e-mail] voor "Testa" en [e-mail] voor "TestA".

Je kunt prima een eigen classloader maken die dat doet.

[ Voor 31% gewijzigd door Hydra op 04-05-2016 11:40 ]

[Merethil]

Hydra schreef op woensdag 04 mei 2016 @ 11:38:
[...]


Java pretendeert niet dat er geen platformverschillen zijn. De class files zijn prima overdraagbaar. Dat er bepaalde files niet aangemaakt / gevonden kunnen worden is bij alle platformen zo. In server land een redelijk non-issue trouwens; daar is het toch Linux dat de klok slaat.

Ook is het een beetje een non-issue. Als je twee classes met dezelfde naam en alleen andere casing hebt in je package doe je sowieso iets fout.

Dit natuurlijk vooral, er zit dan sowieso wat mis. Toch is het iets wat ik had verwacht dat ze wel getest en ondervangen zouden hebben.

In Enterprise-omgevingen zie ik trouwens meestal juist Windows. Dus ik gok dat Linux inderdaad op 't merendeel van de webservers zal staan, maar aangezien ik tot nu toe voornamelijk Enterprise-niveau werkgevers heb gehad ben ik ze eigenlijk nog niet tegengekomen; vandaar dat ik voornamelijk daar mijn nadruk op leg in m'n redenering.

[LinuX-TUX]

.oisyn schreef op woensdag 04 mei 2016 @ 11:37:
[...]

Ik had het over het filesystem, dat per definitie een enorm veel grotere groep gebruikers kent dan alleen programmeurs . In een programmeertaal kom je nog weg met bepaalde restricties gezien de doelgroep.

Dat besef ik me al tegoed en zo'n veiligheidsnet is ook een must om mensen tegen zichzelf in bescherming te nemen. Desalniettemin, hoe ver kan je dit doortrekken? Windows usernames zijn niet case sensitive ... vind ik persoonlijk apart, domain names zijn case insensitive, wat voor mij weer heel logisch is.

Hydra schreef op woensdag 04 mei 2016 @ 11:38:
[...]
Ook is het een beetje een non-issue. Als je twee classes met dezelfde naam en alleen andere casing hebt in je package doe je sowieso iets fout.

100% mee eens, en het gebeurt ... en soms wordt het gecorrigeerd en hebbenhadden ALLE developers onder windows er last van

offtopic:
Dan nog wat anders, 'windows file locking' ... dat is leuk
Wel eens met 4 man een uur naar een scherm zitten kijken hoe iets niet werkte. Bleek er een java process onder water nog het jar bestandje vast te houden. Ontwikkeltool daarentegen 'compilede' netjes de nieuwe java code en gaf nergens foutmeldingen. Windows pretendeerde dat het bestand was weggeschreven, maar ondertussen ... niet. Pas toen het process onder water de nek om werd gedraait, werd het jar bestandje geupdate. Of dit nou een java fout of windows misser is, geen idee, het kan nog steeds

[Hydra]

Merethil schreef op woensdag 04 mei 2016 @ 11:43:
Dit natuurlijk vooral, er zit dan sowieso wat mis. Toch is het iets wat ik had verwacht dat ze wel getest en ondervangen zouden hebben.

Dit is niet iets dat 'onbekend' is ofzo. Het is gewoon een non-issue waar je alleen tegenaan loopt als je je niet aan de naming conventions houdt. Daarnaast is het iets dat je als developer ook gewoon hoort te weten.

[Merethil]

Hydra schreef op woensdag 04 mei 2016 @ 12:14:
[...]


Dit is niet iets dat 'onbekend' is ofzo. Het is gewoon een non-issue waar je alleen tegenaan loopt als je je niet aan de naming conventions houdt. Daarnaast is het iets dat je als developer ook gewoon hoort te weten.

Ik heb er gewoon nooit aan gedacht 't eens te testen omdat ik nooit in die situatie beland ben. Ik verbaas me ook meer over dat je dit in Linux kán doen, maar dat in Windows er niet een oplossing voor bedacht is om 't toch mogelijk te maken.

Ik zeg niet dat het gewenst is dat mensen dit doen, maar het kán voorkomen en dan zou ik, als ik de oorspronkelijk bedenker geweest zou zijn, in ieder geval ervoor zorgen dat 't werkt zoals 't op andere platformen ook werkt, al dan niet met een omweg.