[Java/Maven] mismatch waar jar en IDE een resource zoekt

[MisterE]

Mijn vraag
Ik probeer te achterhalen hoe ik met interne resources hoor om te gaan met Java. Het werkt nu in mijn IDE of als jar. Maar het moet natuurlijk in alle gevallen werken.

In mijn echte project gaat het mis, maar ik kan het naspelen.

Relevante software en hardware die ik gebruik
Eclipse vanuit een Flatpack

Wat ik al gevonden of geprobeerd heb


File -> New -> Maven Project

Create a simple project

Use default Workspace location


Group Id: ExampleGroup

Artifact Id: ExampleId

We voegen plaatje toe aan "src/main/resources" map in de IDE

Maken een Class aan met Name: ExampleClass

Java:

public class ExampleClass {
    public static void main(String[] args) throws Exception {
        System.out.println(ExampleClass.class.getClassLoader().getResourceAsStream("test.jpg").available());
    }
}

Nou runnen we die als "java application". Het resultaat is 1492534.

---

Nou exporteren we deze als Jar:

File -> Export -> Runnable JAR file

Launch configuration: ExampleClass - ExampleID

Export destination: example.jar

Library handling: Copy required libraries into a sub-folder next to the generated JAR

java -jar example.jar

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "java.io.InputStream.available()" because the return value of "java.lang.ClassLoader.getResourceAsStream(String)" is null

Als ik de example.jar open in Ark dan zie ik dat het bestand staat in /resources/test.jpg.

Als ik de code aanpas naar "getResourceAsStream("resources/test.jpg")" en exporteer dan werkt het via de command line, maar dan faalt het weer in de IDE.

[dfijma]

Ik kan je niet 100% helpen: ergens begin deze eeuw ben ik gestopt met het gebruiken van Eclipse. Maar misschien om je op het goede pad te zetten: het zou moeten kunnen werken met "test.jpg" _zonder_ "/resources"-prefix in de code. Als ik je voorbeeld vertaal in een klein maven-projectje en daaruit een jar laat bouwen, dan komt die test.jpg in root van 'example.jar' (dus niet in een foldertje /resources). En dat is ook logisch, want dan staat de jpg in de root van de jar die het classpath vormt.

Als ik dit projectje open in IntelliJ en van daaruit run, dan werkt 't zonder code-wijzingen. Je zou de oplossing denk ik moeten zoeken in het creëren van de jar vanuit Eclipse. Wellicht dat daar iets van settings in zitten om te bepalen waar je resources terecht komen in de jar? (Of natuurlijk gewoon maven of gradle gebruiken :-))

[dfijma]

Wacht even, nu zie ik dat je als "maven" als project-type gebruikt. Gaat het dan wel goed als je de jar direct vanaf de commandline bouwt? ("mvn clean package; java -jar example.jar")

[CyBeRSPiN]

Je lijkt een relatief pad naar een plaatje te gebruiken, mogelijk is de werkdirectory verschillend afhankelijk van hoe je het start.

Probeer het eens met het volledige pad?

Wellicht dat je ergens een resource directory als variable kunt ophalen zodat het altijd op de juiste plek kijkt?

[ Voor 26% gewijzigd door CyBeRSPiN op 09-09-2026 13:05 ]

[dfijma]

CyBeRSPiN schreef op woensdag 9 september 2026 @ 13:03:
Je lijkt een relatief pad naar een plaatje te gebruiken, mogelijk is de werkdirectory verschillend afhankelijk van hoe je het start.

...

Zo'n relatief pad zou moeten werken (en is gebruikelijk voor het laden van een resource). We hebben het hier over het classpath, dat is wat anders dan een directe benadering van een bestand in het filesysteem (hoewel natuurlijk wel gerelateerd...)

Het probleem is dat de classpath's blijkbaar anders zijn vanuit de IDE dan vanaf de cmdline met "java -jar". Ik denk dat het ermee te maken heeft dat de instellingen van de Eclipse Jar-exporter niet goed zijn, zodat de inhoud van 'src/main/resources' niet in de root van de jar komt (zoals het heurt), maar in een subfolder '/resources' binnen die jar. Dat is vast op enige manier op te lossen door de project-settings binnen Eclipse te editen (iets als "de output directory gerelateerd aan src/main/resources")

Als het onderliggende project daadwerkelijk een maven-project is met een pom.xml die wel correct werkt, dan zou een mogelijk oplossing ook kunnen zijn om dat maven-project opnieuw te importeren in Eclipse (waarmee de project-settings automatisch goed komen te staan)

[MisterE]

Vooropgesteld, ik ben niet thuis in Java/Eclipse. Ooit projectje hierin begonnen en is inmiddels te veel werk om te porten.

Alternatief voor Eclise staat nog wel op mijn todo voor in de toekomst. De interface is een draak. Maar run dit ding nu vanuit een flatpack.

Als ik doe:

mvn clean package -Dmaven.test.skip=true

En ik kijk in die jar dan staat het bestand wel in de root.

Als ik dus exporteer dan is het anders.

Dus, maven jar:

META-INF/

jopt/

testing/

plaatje.png

En export jar:

3rd

META-INF/

jopt/

resources/plaatje.png

log4j2.xml

Ik heb ooit lopen vechten met -ik denk- die 3rd party module, en java/eclipse upgrades waardoor dingen stuk gingen. Dus ik heb vast ooit iets fout aangepast.

Die log4j2.xml gaf mij eerder ook problemen en daarom toen onder src/main/java gezet.

Aan de andere kant, als ik nu een nieuw maven project maak kan ik het naspelen. Daarmee lijkt het geen onderdeel van mijn project te zijn.

AI kwam steeds met volgende verwijziging, maar geeft ook aan dat die goed staat.

Project -> Properties -> Java Build Path -> Tabblad: Source

jopt/src/main/resources

Output folder: jopt/target/classes

Included: (All)

Excluded: **

Release: project default

[dfijma]

Die output van 'mvn clean package -Dmaven.test.skip=true' lijkt goed, die van de JAR-exporter fout. Het waarom kan ik je niet bij helpen, wegens gebrek aan Eclipse-kennis. De enige educated-guess die ik nog zou kunnen doen is checken of de output-folders van 'jopt/src/main/resources' en 'jopt/src/main/java' hetzelfde staan.

Doe jezelf een lol, installeer de (gratis) IntelliJ community-edition, importeer het bestaande maven-project en gaan met die banaan. Als je het kan builden met maven, dan kan je ook verder bewerken met IntelliJ, komt geen porting aan te pas.

[MisterE]

recent kort gekeken naar een alternatief, maar als ik me goed herinner is er van IntelliJ geen officiele platpack. Recent genoeg security drama met de Arch User Repository (AUR) . Dus ben wat terughoudend in onofficiele pakketjes.

[dfijma]

Sorry, geen idee van Arch Linux en flatpacks. Maar het lijkt me heel sterk dat je daar geen beschaafde installatie van IntelliJ op zou kunnen doen. Als dat zo zou zijn, dan zou ik de betreffende distro onmiddelijk vervangen door iets anders :-)

[MisterE]

dfijma schreef op woensdag 9 september 2026 @ 19:23:
Sorry, geen idee van Arch Linux en flatpacks. Maar het lijkt me heel sterk dat je daar geen beschaafde installatie van IntelliJ op zou kunnen doen. Als dat zo zou zijn, dan zou ik de betreffende distro onmiddelijk vervangen door iets anders :-)

Nee, ik draai geen Arch (btw). Maar bedoelde daarmee dat onofficiele pakketjes security risico's lopen. En bij IntelliJ staat dat deze niet officieel is. Dus ben huiverig deze te draaien.

Overigens neig ik er naar om dan niet meer die export in eclipse zelf te gebruiken maar mvn build in mijn compile (en bouw container) script op te nemen. Scheelt ook weer handmatige actie.

[MisterE]

Dank voor de tips. Ik heb net een uurtje met AI erbij de pom.xml zitten aanpassen naar soortgelijks. Dus de libs komen naast de jar file in de "target" map. Daarmee lijken de wijzigingen verder klein. Ik hoef niet meer handmatig te exporteren in eclipse nu. En mijn bouw-one-liner doet nu de mvn stap erbij

[dfijma]

MisterE schreef op woensdag 9 september 2026 @ 21:02:
Dank voor de tips

...

Gaarne gedaan, het 'classpath' in Java is een bitch :-)