[BUG #2] java.io.IOException: mark/reset not supported

[BlueDragon]

Discutiamo qui del bug trovato da PGI

---------
Dettagli della macchina:

Win XP Home SP 2
JRE 1.5.0_06
AMD64 3200+
GeForce 6800 GS (Driver NVIDIA versione 8.1.9.8)
DirectX 9.0x (4.09.0000.0904)
Realtek AC97 Audio (Driver 5.10.0000.5750)

Descrizione del problema.

Doppio click sul file "run-diamonds.bat". Sul prompt del dos appaiono le seguenti linee


C:\Documents and Settings\limitato\Documenti\DiamondCrush>set LD_LIBRARY_PATH=li
b/win32/

C:\Documents and Settings\limitato\Documenti\DiamondCrush>set CLASSPATH=DiamondC
rush.exe;.;bin/;lib/jar/jinput.jar;lib/jar/lwjgl_devil.jar;lib/jar/lwjgl.jar;lib
/jar/lwjgl_util.jar;lib/jar/jogg-0.0.7.jar;lib/jar/jorbis-0.0.15.jar;lib/jar/trb
.jar;

C:\Documents and Settings\limitato\Documenti\DiamondCrush>java -Djava.library.pa
th=lib/win32/ -cp DiamondCrush.exe;.;bin/;lib/jar/jinput.jar;lib/jar/lwjgl_devil
.jar;lib/jar/lwjgl.jar;lib/jar/lwjgl_util.jar;lib/jar/jogg-0.0.7.jar;lib/jar/jor
bis-0.0.15.jar;lib/jar/trb.jar; it.diamonds.Game
Display Adapter: nv4_disp
List of available display modes:
[...]
java.io.IOException: mark/reset not supported
at java.io.InputStream.reset(Unknown Source)
at com.sun.media.codec.audio.mp3.JS_MP3FileReader.getAudioFileFormat(JS_
MP3FileReader.java:226)
at com.sun.media.codec.audio.mp3.JS_MP3FileReader.getAudioInputStream(JS
_MP3FileReader.java:131)
at com.sun.media.codec.audio.mp3.JS_MP3FileReader.getAudioInputStream(JS
_MP3FileReader.java:93)
at javax.sound.sampled.AudioSystem.getAudioInputStream(Unknown Source)
at org.lwjgl.util.WaveData.create(WaveData.java:123)
at it.diamonds.engine.audio.Sound.readSoundFile(Unknown Source)
at it.diamonds.engine.audio.Sound.initSource(Unknown Source)
at it.diamonds.engine.audio.Sound.<init>(Unknown Source)
at it.diamonds.engine.audio.Sound.<init>(Unknown Source)
at it.diamonds.engine.audio.Audio.createSound(Unknown Source)
at it.diamonds.gems.DroppableFactory.<init>(Unknown Source)
at it.diamonds.gems.RandomDroppableFactory.<init>(Unknown Source)
at it.diamonds.gems.GemQueue.<init>(Unknown Source)
at it.diamonds.grid.GridController.create(Unknown Source)
at it.diamonds.PlayField.<init>(Unknown Source)
at it.diamonds.GameLoop.createPlayField(Unknown Source)
at it.diamonds.GameLoop.createPlayFieldOne(Unknown Source)
at it.diamonds.GameLoop.initPlayField(Unknown Source)
at it.diamonds.GameLoop.<init>(Unknown Source)
at it.diamonds.GameLoop.create(Unknown Source)
at it.diamonds.Game.setUpGame(Unknown Source)
at it.diamonds.Game.create(Unknown Source)
at it.diamonds.Game.main(Unknown Source)
------------

Praticamente la questione è che quando invochiamo WaveData.create in Sound, dietro a quest'invocazione c'è un AudioSystem.getAudioInputStream, che può variare a seconda dell'implementazione.
Nei sistemi che hanno a disposizione implementazioni dell'Audio java oltre a quella standard, (es: supporto mp3), la chiamata ad AudioSystem può incappare in uno stream che non supporta il mark/reset necessario alla nostra WaveData.create.

Ho provato a simulare il problema aggiungendo al progetto i jar mp3spi e tritonus che danno il supporto ad mp3 in JavaSound ed ho riscontrato un errore con stacktrace quasi identico (differisce solo nelle prime righe per via di implementazioni diverse).
La soluzione, come suggerita da TigerShark è di passare a WaveData.create uno stream che supporti il mark/reset, ad esempio BufferedInputStream.

Quindi wrappando il FileInputStream con un BufferedInputStream, il problema dovrebbe essere risolto.
Ho provato e funziona

[Jocchan]

Grandissimo!

[^TiGeRShArK^]

http://www.hwupgrade.it/forum/showpo...21&postcount=6
pure io avevo già fatto tutto
solo che alla fine io ho usato il getResourceAsStream del ClassLoader che a quanto ne so è + consigliato..
potresti provare se come ho fatto io ti funziona???

[BlueDragon]

Originariamente inviato da ^TiGeRShArK^

http://www.hwupgrade.it/forum/showpo...21&postcount=6
pure io avevo già fatto tutto
solo che alla fine io ho usato il getResourceAsStream del ClassLoader che a quanto ne so è + consigliato..
potresti provare se come ho fatto io ti funziona???

Sì, ho provato anche da Eclipse e funziona.
Non mi è mai capitato di usare getResourceAsStream...vedo che ritorna un generico InputStream...possiamo essere sicuri che sotto quell'InputStream ci sia sempre un'istanza di una classe che supporta mark/reset?
(la classe InputStream non lo supporta).

[cionci]

new BufferedInputStream(getResourceAsStream(....));

Dovrebbe andare bene...no ?

[^TiGeRShArK^]

si perfetto.
come dice cionci dovrebbe andare
committi tu blue?

[BlueDragon]

Originariamente inviato da cionci

new BufferedInputStream(getResourceAsStream(....));

Dovrebbe andare bene...no ?

Eheeh così uniamo le due soluzioni

Però sinceramente se comunque alla fine wrappiamo con BufferedInputStream, allora tanto vale "dire YAGNI" al getResourceAsStream che ci fa anche modificare il classpath e wrappare semplicemente il FileInputStream esistente.
A meno che il fatto di usare getResourceAsStream non ci porti dei benefici di cui abbiamo già bisogno.

[^TiGeRShArK^]

onestamente non so se è YAGNI....
però di solito si usa il getResource...
ad esempio:

Most nontrivial applications are packaged with "resource files," which are nothing more than files used by the application for various purposes. Some examples of these resources include image (GIF, JPEG) files, message/text data, configuration/initialization information, and so on. There are several of ways to read these resources, but most of them are closely tied to the way in which the code is packaged. For example, one way will work correctly for a Java application, while another will work only for an applet. Obviously, the most desirable approach is to use a mechanism that functions correctly regardless of the packaging of the code. This is where the getResource() method in java.lang.Class is useful. It returns a URL that represents a resource, which can then be used to read the resource.

in pratica il vantaggio è che con getResource si ha un metodo uniforme per caricare le risorse.
La modifica al classpath in realtà non è necessaria, è che nella fretta avevo eliminato il riferimento al package in cui si trovava il file..
lasciando la stringa originaria dovrebba andare anke avendo il classpath che abbiamo usato finora...
inoltre qui di seguito c'è un buon articolo che spiega piuttosto bene le differenze:
http://www.javaworld.com/javaworld/j...-property.html

[VICIUS]

E uno è andato.
Per ora preferisco la versione con BufferdInputStream. getResource può essere utile per future release se decidessimo di inserire tutti i files dentro ad un singolo jar ma per ora non penso possa servirci.

ciao

[fek]

Bravo BD! Questa soluzione e' perfetta cosi'.

[^TiGeRShArK^]

Originariamente inviato da VICIUS

E uno è andato.

Per ora preferisco la versione con BufferdInputStream. getResource può essere utile per future release se decidessimo di inserire tutti i files dentro ad un singolo jar ma per ora non penso possa servirci.

ciao

ok, perfetto
vai e colpisci Blue!

[BlueDragon]

Committata soluzione minimale

Da così:
WaveData waveFile = WaveData.create(inputFile);
A così:
WaveData waveFile = WaveData.create(new BufferedInputStream(inputFile));

Interessante comunque il getResource...si impara sempre qualcosa

[VICIUS]

Bug Closed.