Java

Hello,

Adott egy konzolos 5 soros program, ami  a paraméterben kapott fájlt utf8-ra alakítja. (Egy feldolgozási folyamat végén egy másik programból kerül meghívásra).

Remekül működött a jre 1.8 update 411-ig. Ettől fogva a fájlt csak akkor tudta megnyitni, ha átadtam a jvm-nek a -Dsun.jnu.encoding=utf8 paramétert.

Ismét működött (411-421), de most jött nemrég a 431. És megint nem megy. 

Ha nem adok át neki paramétert (-Dsun.jnu.encoding=utf8) akkor jól működik (tehát mint előtte).

Ugye most nézegethetném (valahogy), hogy melyik verzió megy és aszerint hívhatnám meg (A sun.jnu.encoding paramétert nem lehet programból állítani tehát az nem játszik, hogy programon belül lekezelem a kivételt és újra próbálom más paraméterrel).

Várom az ötleteket.

Köszönöm!

f:\test2024>java -Dsun.jnu.encoding=utf8 utf8 KÖN_202410_2411111223.xml
Java Runtime version 1.8.0_421-b09
---------------------------------------------------------
Charset.defaultCharset()                  = windows-1250
System.getProperty("file.encoding")       = Cp1250
System.getProperty("native.encoding")     = null
System.getProperty("sun.jnu.encoding")    = utf8
System.getProperty("sun.stdout.encoding") = cp852
System.getProperty("sun.stderr.encoding") = cp852

f:\test2024>java -Dsun.jnu.encoding=utf8 utf8 KÖN_202410_2411111223.xml
Java Runtime version 1.8.0_431-b10
---------------------------------------------------------
Charset.defaultCharset()                  = windows-1250
System.getProperty("file.encoding")       = Cp1250
System.getProperty("native.encoding")     = null
System.getProperty("sun.jnu.encoding")    = utf8
System.getProperty("sun.stdout.encoding") = cp852
System.getProperty("sun.stderr.encoding") = cp852

Exception in thread "main" java.nio.file.NoSuchFileException: K?N_202410_2411111223.xml
        at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
        at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
        at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
        at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source)
        at java.nio.file.Files.newByteChannel(Unknown Source)
        at java.nio.file.Files.newByteChannel(Unknown Source)
        at java.nio.file.Files.readAllBytes(Unknown Source)
        at utf8.main(utf8.java:25)

Úgy hozta az élet, hogy mocskolnom kellene ezen a java-ban írt projekten kicsit:

https://github.com/OpenAPITools/openapi-generator

Sajnos a módosítás mértéke úgy tűnik meg kell haladja azt a szintet amit gyalog módszerrel (kate + mvn clean install + jar futtatása) érdemes végezni.

Kellene valami IDE amiben tudok normálisan debugolni illetve egy sor módosítás compile-ja (vagy aminek Javaul épp nevezik) az nem két percig tart.

Mit ajánlatok erre a célra 2024-ben?

Adott egy java alkalmazas ami csak 1.7-es javán fut, ha jól tudom a java 1.7 nem támogatja a TLS 1.3-at,
hogyan lehetne linuxon megoldani, hogy mégis elérje a https://srv-t, az alkalmazás módosítása nélkül?
pl: java alk. <--> (nginx?) proxy on localhost:443(TLS1.2 selfsigned cert) <--> https://srv.tld (TLS1.3),
vagy lenne egyszerűbb megoldás ?
Köszönöm!
 

Van néhány WAV fájlom, amik egy régi 8 bites számítógép betölthető programjait tárolják.

Továbbá van egy javascript alapú emulátorom, ami az AudioContext segítségével be is tudja tölteni ezeket.

Valamint jelenleg ehhez az emulátorhoz létezik néhány MP3 fájl is, amiben szintén a géphez tartozó programok vannak tárolva, és ezeket is be tudja tölteni az emulátor.

A feladat az lenne, hogy én is tudjak MP3 fájlt generálni a létező WAV fájlomból úgy, hogy ez az emulátor be tudja tölteni.

1 - Azt már megtapasztaltam, hogy az AudioContext objektumnak van egy 'sampleRate' paramétere. Ha ez az érték nem azonos a wav fájl sampleRate értékével, akkor az emulátor nem tudja beolvasni. Ha azonos, gond nélkül betölti.

2 - Érdekes módon, ez a 'sampleRate' paraméter az mp3 fájlok esetén nem azonos az mp3 fájlból killvasható értékkel. Az AudioCintext objektumban ez 48000, míg az mp3-nál a ffprobe parancs 44.1kHz-es értéket mutat.

A parancs, amivel jelenleg próbálok konvertálni:

lame -s 44.1 -b 96 -q 9 -m m program.wav program.mp3

Az ffprobe mind a működő mp3, mind az általam konvertált mp3 esetén ugyanazt az információt mutatja:

..., bitrate: 96 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, mono, fltp, 96 kb/s

A minta mp3 fájlt mégis gond nélkül betölti az emulátor, az enyémet meg nem.

Van ötletetek, hogyan tudnám mp3 formátumba konvertálni a wav fájljaimat, hogy továbbra is működjön a betöltés?

Böngészőben egy excel állomány tartalmát szeretném megjeleníteni . 

<input type='file' accept='.xlsx, .xls' onChange={handleFileUpload} bekéréssel,  ahol a handleFileUpload-ban egy  FileReader() -t használva, ami  egy target.files[0] tömbe tölti be a olvasandó fájl elérési útcvonalát  sikeresen meg tudom jeleníteni a kijelőlt xlsx állomány tartalmát.

Szeretném felhasználó bevonása nélkül,  programból feltölteni a  target.files[0] tomb tartalmát  de sehogy sem tudom programból megoldani.

Tudna valaki segíteni hogy hogy oldhatom ezt meg ?

Köszönöm 

Lehet, hogy nem jól értek valamit.

Van 2 alkalmazás szerver. Nincs az Entity cache szinkronban.

Amikor kiíratom az SQL-t amit optimistic lock esetén végrehajt, egy ilyesmit látok: update version=?version+1 where version=?version and id=?id; Ez alapján úgy gondolnám, hogy nem lehet 2 írás ugyanazon a rekordon. Vagy mégis? Úgy tűnik mintha ennek ellenére 2x íródna nagyon ritkán ugyanaz a rekord, nem dob Exception-t.

Még az ünnepek előtt jött valahol szembe a Vaadin (https://vaadin.com), ami első (és egyelőre sokadik) ránézésre is olyan frameworknek látszik, aminek használatát érdemes lenne fontolóra venni.

Amúgy sem szeretem a frontendet; JavaScripttől, CSS-től stb., kiráz a hideg.

De azt vettem észre, hogy kis fejlesztőcsapat lévén (van 1 db UX-es, de ő is inkább designer, mint fejlesztő, a többi lényegileg mind backend) számos belső tool-ra egyszerűen nem jut idő és energia frontendet fejleszteni, mert a Postman-nel való tutujgatás "elégségesen jó" megoldás.

Szóval első körben leginkább belső tool-ok UI fejlesztésére használnám, nem pedig a publikus oldalunkat akarnám újraírni benne.

A kérdés: használta-e valaki a Vaadin-t éles környezetben (nem példakódok otthon bizergetése), és ha igen, akkor mik voltak a tapasztalatok vele?

Mennyire egyszerű vele egy frontendet összehozni?

Mennyire bugos?

Hogyan lehet debugolni?

Milyen előnyöket/hátrányokat tapasztaltatok?

Stb. stb.

Köszi!

Még fiatalos a kinézetem. Visszajelzések szerint 5-10 évet simán letagadhatok. A modernebb technológiák vonzanak és még van bennem tudásvágy is.

A mostanában szokásos videó interjúkon (itt kevésbé látszik, hogy oldalt már őszülök) / feladatokon is átmegyek simán.

Az önéletrajzomból nem derül ki a korom, sőt ott is a 10 évvel fiatalabb jön ki egy véletlen folytán.

Ma raktam magamban össze a képet, hogy ahol modernebb technológiákat használnak, ott valószínűleg fiatalabbakat is várnak.

Azaz addig nincs semmi baj, amíg nem kérik be az adataimat. Jó ajánlatokat is kapok. 1.5 fölötti mind. Viszont amikor sejtésem szerint a beküldött adatok alapján meglátják, hogy nemrég elmúltam 50, jönnek a visszahúzódások.

Soha sem vágytam vezetői pozícióba. Mentorálni viszont mindig szerettem.

Lehet vissza kell lépnem a régebbi technológiákhoz? Azoknál nem volt gond ennyire, olyan helyekre simán felvettek volna. Igaz ott mindegyiken öreg szakikat is láttam. Több helyen GWT-t tolnak még. Volt ahol JDBC megy még. Stb. Az egyikre rákérdezve azt mondták felvettek ugyan embereket, de ha meggondolom magam szívesen látnak.
A régi munkahelyemre is visszavennének, ott JEE van. A Spring ott viszont tiltott. Pedig simán lehetne sok esetben használni.

Ez nem allasajanlat, hanem akinek van kedve reszt venni egy mar letezo kodbazis fejlesztesenek folytatasaban, az irjon nekem:

wyx@freemail.hu

reszletek online beszelgetesben kesobb..

kosz,

Már 1 napot eltöltöttem ezzel a feladattal és nem igazán látok megoldást.

SOAP: Jaxb 2.3.3 + Spring.

Kb. 400 megás fájlokat kellene XML-ben visszaadnom base64 kódolással.

Valahogy így néz ki az XSD ezen része: 

type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream"

A Java-ban így van beállítva:

.setDoc(new DataHandler(new FileDataSource(f)));

Jelenleg olyan 4G-át eszik 1db 400 megás fájlnál.

Jó lenne ha streamelné inkább mint betölti memóriába a teljes fájlt stb.
com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.class:

try {
    ByteArrayOutputStreamEx baos = new ByteArrayOutputStreamEx(1024);
    InputStream is = this.dataHandler.getDataSource().getInputStream();
    baos.readFrom(is);
    is.close();
    this.data = baos.getBuffer();
    this.dataLen = baos.size();
} catch (IOException var3) {
    this.dataLen = 0;
}

Mert a főnökség viszont szeretné, ha mindez elmenne <1G rammal. Ha lehet 512 megával.

Ahogy debugoltam úgy látom alapból betölti a teljes fájlt. Majd azon még dolgozik a base64 kódolás miatt és úgy rakja be az XML-be. Gondolom a Content-Lenght-et is így állítja be (de ez nem lenne fontos).

Van ötletetek valami megoldásra?