a 3.29.0-01 verzio most is mukodik, csak vigyaznom kell, hogy a programot ne frissitsem, csak a nyomtatvanyokat.
a diffekbol latja valaki, hogy mi az ujabb verzionak a baja?
koszi!
az stdout-on ennyi a kulonbseg:
-------------------------
0a1,2
> Friss abevjava csomag (jelenlegi:v3.29.0, frissebb: v3.33.0)
> Rendszer upgrade
9c11
< abevjava 3.29.0-01
---
> abevjava 3.33.0-01
43,59c45
< 4000
< Free memory=105 MB
< frissités napló könyvtár : /home/user/abevjava/naplo
< ReadHandedObjectStreamTime = 10 enyk_dirlist_home_nyomtatvanyok_user
< FileListTime = 13 /home/user/abevjava/nyomtatvanyok/
< ReadHandedObjectStreamTime = 2 enyk_dirlist_home_nyomtatvanyok_user
< FileListTime = 3 /home/user/abevjava/nyomtatvanyok
< ReadHandedObjectStreamTime = 1 enyk_dirlist_home_segitseg_user
< FileListTime = 1 /home/user/abevjava/segitseg
< ReadHandedObjectStreamTime = 1 enyk_dirlist_home_nyomtatvanyok_user
< FileListTime = 3 /home/user/abevjava/nyomtatvanyok/
< ReadHandedObjectStreamTime = 1 enyk_dirlist_home_nyomtatvanyok_user
< FileListTime = 2 /home/user/abevjava/nyomtatvanyok
< ReadHandedObjectStreamTime = 0 enyk_dirlist_home_segitseg_user
< FileListTime = 1 /home/user/abevjava/segitseg
< ReadHandedObjectStreamTime = 1 enyk_dirlist_home_nyomtatvanyok_user
< FileListTime = 3 /home/user/abevjava/nyomtatvanyok/
---
> *** TM impl : AnykTrustManagerProviderImplAnykts
-------------------------
az stderr-en ennyi, azt latom hogy "NoClassDefFoundError: javax/xml/bind/JAXBContext" csak azt nem hogy ilyenkor mi van.
-------------------------
97a498,508
> Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext
> at hu.piller.enykp.alogic.templateutils.blacklist.Blacklist.create(Unknown Source)
> at hu.piller.enykp.alogic.templateutils.blacklist.BlacklistStore.<init>(Unknown Source)
> at hu.piller.enykp.alogic.templateutils.blacklist.BlacklistStore.getInstance(Unknown Source)
> at hu.piller.enykp.gui.framework.MainFrame.<init>(Unknown Source)
> at hu.piller.enykp.gui.framework.MainFrame.main(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBContext
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
> ... 5 more
-------------------------
Hozzászólások
Nem lehet, hogy a régi java8, az új meg frissebb java? Én megpróbálnék a classpathra odavarázsolni neki egy jaxb implementációt (ha már a fejlesztői nem voltak képesek erre).
Egyébként meg https://github.com/Res42/anyk-docker
A java fejlődésének egyik diadalmas lépése a Jaxb és JaxWS megszüntetése volt (mármint kikerültek az SE-ből).
Default java helyett specifikusan nyolcassal kellene futtatni. (Szerintem valamilyen .krny fájlt kellene megszerkeszteni.)
Szerintem a platformnak jót tett, és van milliópluszegy Java app (akár desktopon is), aki képes volt megugrani ezt a feladatot, hogy nem egy pain in the ass a használata.
Az meg az állam/NAV sara, hogy az anyk olyan, amilyen... Nem lenne egy teljesíthetetlen feltétel, hogy az utolsó x java releaseen, és az utolsó x Debian/Ubuntu/Fedora releaseen OOB induljon el.
Off: az egy ideális "másodikborítékos" megoldás volt: amikor berakták az SE-be, az kompatbilitási gondokat okozott, és amikor kivették, az is kompatibiltási gondokat okozott.
nem ertem amit irsz a java 8-al. java 17-en futtatom mindkettot. ez van debian 12-ben. java 8-at szerintem kb. debian 10 ota nem latott az abevjavam.
az az abevjava frissites par honapja tortent, ami nem indul.
neked aztan fura humorod van...
https://openjdk.org/jeps/320
tldr: a java8-ban még a JAVA-SE platform szállította a JAXB-s dolgokat (~xml parsinghoz dolgokat), mert legacy örökség. postjava8 után nem szállítja a javase, az appnak kell gondoskodnia róla. ez exception alapján ilyet hiányol neked az anyk
ködszurkálás: vagy most váltottál JRE verziót, vagy most kezdett el az anyk jaxb-t (és ~xml-t) használni. esetleg az anyk minősége nagyot esett most. az utolsó lehetetlen (eddig is a béka segge alatt volt), a friss xml-használatban is kételkednék -> marad az, hogy nálad változott a JRE, amivel az anyk elindul.
irom, hogy ugyanazon a 17-es javan inditom mindkettot, csak az abevjava frissult. ha visszateszem az elozo abevjavat, az ugyanugy mukodik mint eddig.
ebbol arra kovetkeztetek, hogy vagy most kezdhettek el hasznalni ezt a jaxb-t (xml-t eddig is dolgoztak fel), vagy most dobhattak ki a classt.
neked aztan fura humorod van...
Én már pár éve ezt használom:
https://github.com/Res42/anyk-docker
Gábriel Ákos
Ha komolyan dockerezni kell, mert annyi a szivás vele linuxon, akkor jobb lett volna exe-nél maradni az jól futott wine-al.
A szopás az, hogy ez a projekt 24 éve indult és azóta alig nyúltak hozzá, annyit változtattak rajta technológiailag, amennyi mindenképpen kellett. Ennyi idő alatt mininum három nagyobb refactor kellett volna, de arra sose adtak pénzt-paripát-fegyvert, ezért így maradt.
https://iotguru.cloud
Mondjuk mit programozó ezzel én is egyetértek, a legjobbak azok a fejlesztések, amikor azért kapjuk a pénzt, hogy egy nagy átírás után program ugyanazt [na jó, a gyakorlatban mindig egy kicsit kevesebbet] tudja, mint eddig.
egészen biztos vagyok benne, hogy ez a vacak a mai napig elindul 3-on.
köcsög állampolgárok, hogy ma már nem XP-n akarnak adót bevallani.
Ezt most nem értem pontosan, melyik három XP-n indul el a milyen vacak, és ez miért baj?
Kimaradt egy Debian szó, szóval
Addig jó amig nem hozzák nyilvánosságra, hogy hány % ad be adóbevallást linuxról, mert lenne felhördülés, hogy miért sziv mindenki ezzel a javas szarral...
De mondom, annak az 1-2%-nak tökéletes ment wine-al is a régi exe.
Szerintem a Debian verziójánál a Java verziója érdekesebb; legjobb tudomásom szerint az OpenJDK-ból van 8-as verzió Windows-ra és Debianra is, szóval nem megugorhatatlan a feladat.
én csak azt mondom, hogy amíg anyk-fejlesztőként tök oké undocumented, sőt, dokuemntáltan unsupported API-kat használni, addig semmi meglepő nincs abban, ha ez a szar csetlik, botlik.
meg lehetett volna írni ~20 éve is úgy, hogy elinduljon ma is. nem úgy írták, nem a java tehet róla :\
(Nem látom a topikban, hogy mi a kérdéses dokumentálatlan feature, de ha megmutatod, esetleg ránézek.)
Itt, vagy a fentebb linkelt topicban? De tessék, megkapod mindkettőt:
Ami ekkora gány app, az várhatóan tele van még hasonló finomságokkal.
Ok, köszi. Mindazonáltal, ha azt írják, hogy 8-cal megy, akkor talán érdemes lenne 8-assal használni, még ha el is kell vándorolni érte valami ilyesmi helyre: https://adoptium.net/temurin/release-notes/?version=jdk8u412-b08
A kifejezés, amit keresel, de nem találsz, az a "technical debt".
Ez az oka annak, hogy már nem találnak embert, aki hozzá merne vagy hozzá akarna nyúlni egy 24 éves kódbázishoz, illetve ebből adódóan a következménye az, hogy egy amúgy egy napos meló az nagyjából két hónap lesz, mert két hónap kell hozzá, hogy megértse, átlássa és hozzá merjen nyúlni az új fejlesztőember.
És akkor jönnek ezek a problémák, hogy hiába járunk Java 21 LTS körül, ez a foshalom még mindig a 10 évvel ezelőtti Java 8 felett szeret futni, de a kódbázis jelentős része elfutna azon az 1.4-es Java felett, amire eredetileg készült.
Szóval kell a refactor, anélkül egyre nagyobb szargalacsint hajt maga előtt az adott szervezet.
https://iotguru.cloud
Off: Nekem van egy jobb ötletem: ha mondjuk egy munkahelyen olyan programozókat alkalmaznak, akik csak Java21-ben tudnak fejleszteni, de Java8-ban nem, akkor szeretettel el kell bocsátani őket azzal együtt, aki felvette őket.
Nekem még jobb ötletem van: ki kell baszni a picsába azokat a programozókat, akik megrekedtek 10-15-20 évvel ezelőtti technikai színvonalon és képtelenek a fejlődésre, illetve azokat is, akik 5-10-15 évvel ezelőtt nem rúgták ki őket a picsába, amikor még csak 5 év lemaradásuk volt.
https://iotguru.cloud
Már megegyeztünk, hogy nem fejlődést akarunk, hanem felkavarást, vagy a már meglévővel azonos funkcionalitás előállítását más technikával (tipikusan lassabb, erőforrásigényesebb és kevésbé kompatibilis változatot létrehozva).
(Ez természetesen nagyon etikátlan a megrendelővel szemben, de jövedelmező a programozónak, szóval helyeslem és támogatom.)
Igazából annyit kéne tenni hogy az ONYA alá be kéne húzni végre az összes formot.
Egy "pain-in-the-ass" hogy vállalkozói jövedelemigazolást csak ezen a fostengeren keresztül tudok intézni, a gyerek koleszához kell évente kétszer.
De a fentebb említett dockeres megoldással tök oké.
Gábriel Ákos
Nem tudom mennyit "kell" szívni vele, találtam ezt a dockeres megoldást. Teljesen jó.
További jó benne hogy M1 Mac-re is jó, RDP-n megy.
Kicsit megfejlesztettem a docker mountokat így már meg is tudnak maradni az előállított fileok.
Félévente egyszer elindítani: rendben van.
Gábriel Ákos
Lehet, hogy a Pillér cég fejlesztése most került bele a termékbe. Szerk: eddig is benne volt, most azon belül is konkrétan az 'hu.piller.enykp.alogic.templateutils.Blacklist' nevű fejlesztés került bele.
Szerk: Ez csak egy tipp, de lehet, hogy amikor azt írják, hogy 8-as Java kell hozzá, az lehet egy burkolt célzás arra, hogy 8-as Java kell hozzá.
"Ez csak egy tipp, de lehet, hogy amikor azt írják, hogy 8-as Java kell hozzá, az lehet egy burkolt célzás arra, hogy 8-as Java kell hozzá."
ebben lehet valami, elmult az a szep ido mikor az elavult 17-es javan is futott :)
neked aztan fura humorod van...
Csak tegyél oda egy jaxb-t valahonnan. (Ezek a jar-ok kellenek: activation.jar, jaxb-api.jar, jaxb-impl.jar; forrás: https://hup.hu/comment/2376921#comment-2376921 )
Nemrég volt dolgom javax-jakarta refactoringgal, gusztustalan mindenképpen.
Kis IBM MQ-val megküldve meg aztán legacy a köbön.
Gábriel Ákos
legkozelebb kiprobalom ezt, ertem en a celzast :)
https://onya.nav.gov.hu
neked aztan fura humorod van...
koszi ezt kiprobalom, amugy ez vicces:
Az alábbi ÚJ csomagok lesznek telepítve:
libaopalliance-java libargs4j-java libatinject-jsr330-api-java libcdi-api-java libcodemodel-java libcommons-cli-java libcommons-codec-java libcommons-compress-java libcommons-lang3-java libdom4j-java libdtd-parser-java liberror-prone-java libfastinfoset-java libgeronimo-annotation-1.3-spec-java libgeronimo-interceptor-3.0-spec-java libguava-java libguice-java libhttpclient-java libhttpcore-java libistack-commons-java libjaxb-api-java libjaxb-java libjaxen-java libjsoup-java libjsr305-java libmaven-file-management-java libmaven-parent-java libmaven-resolver-java libmaven-shared-io-java libmaven-shared-utils-java libmaven3-core-java libplexus-archiver-java libplexus-cipher-java libplexus-classworlds-java libplexus-component-annotations-java libplexus-interpolation-java libplexus-io-java libplexus-sec-dispatcher-java libplexus-utils2-java librelaxng-datatype-java librngom-java libsisu-inject-java libsisu-plexus-java libslf4j-java libsnappy-java libsnappy-jni libstax-ex-java libstreambuffer-java libtxw2-java libwagon-http-java libwagon-provider-api-java libxsom-java
neked aztan fura humorod van...
egyik leghülyébb ötlet ever a debiannal (vagy ubuntuval) java-t telepíttetni.
Gábriel Ákos
Nálam Debian 12 alatt működik a 3.33, Oracle Java 1.8.0_401 kellett hozzá.
Tegnap használtam, frissítettem is.
Manjaro és nem Debian, de szerintem ez pont lényegtelen most. 8-as java kell hozzá. Mindig problémám volt vele, ha frissült.
A frissítési problémát el lehet kerülni, ha beteszed egy mappába az abev mellé a nekik kellő Java JRE környezetet, működik az portable módban, csak akkor egy shell szkripttel úgy kell indítani az abevet, hogy ne a disztró Java környezetét használja, hanem a mappába mellékeltet, és örökké fog működni, sose frissül, igaz ez lehet később biztonsági kockázat.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Off: Kis laptopomon (Windows11) most jött létre egy �NYK nevű parancsikon. Csak jó dolog ez a modern technika!
Jó, érted, az UTF-8 2024-ben sok helyen még űrtechnika, meg nem elég érett a bevezetésre. Igaz ebben a Windows is balfasz, mert ott alapból UTF-16-ra van fixre drótozva minden, plusz előfordulhatnak még az abeven kívül is régebbi programok, amik még ISO-8859-1 vagy CP1252 vagy CP1250 kódolással próbálják a fájlokat, mappákat kezelni.
Egyébként nálam már nem csak Windows nincs, de parancsikonok se, se az asztalon, se indítómenüben, indítómenü sincs, meg dokk, meg semmi se. A programokat, fájlokat dmenu-vel, vagy saját, fzf-et használó szkriptekkel érem el, vagy commander-típusú fájlkezelőből (Vifm, ritkábban sfm, lf vagy mc), ezek némelyikébe szintén be van drótozva az fzf.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
eddig jo volt?
neked aztan fura humorod van...
Nyomoronc program biztos használná a Java8 szabványos createDesktopIcon metódusát, ha lenne. De az a szomorú igazság, hogy még a Win32-ben sincs ilyen funkció, hanem egy Visual Basic scriptet kell megírni és futtatni.
https://learn.microsoft.com/en-us/troubleshoot/windows-client/admin-dev…
Az természetesen lehetséges, hogy a Visual Basic default encoding-ja az elmúlt évtizedekben megváltozott "ANSI"-ról "UTF8"-ra; illetve bizonyos verziókban és esetekben az "ANSI" jelenthet "UTF8"-at is.
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-u…
Ez butaság. A Windows shell funkciói között ez a Shell Links funkcióhalmaz. Ezzel a shell névterében lévő bármelyik objektumhoz lehet linket létrehozni - ennek egyik esete, amikor egy fájlhoz csinálsz shortcutot. A Desktop meg csak egy speciális mappa a fájlrendszeren, a shortcutot létrehozod ebben a mappában és kész is a desktop ikon.
https://learn.microsoft.com/hu-hu/windows/win32/shell/links?redirectedf…
Ebben a példában ki is emelik, hogy figyelni kell arra, hogy a shortcut nevét tartalmazó string Unicode legyen:
A Java Web Start nevű desktop-orientált technológiában volt ilyen funkció Java 8-ban. Már Java 6 óta.
https://docs.oracle.com/javase/7/docs/jre/api/javaws/jnlp/javax/jnlp/In…
De hát ugye ehhez érteni kéne.
Off: A JavaWS/JNLP sosem került be az OpenJDK-ba, az Oracle Javaból meg kifejlesztették a 9-ben. Az ilyenek teszik széppé ezt az ipart.
Még szerencse, hogy a JavaWS-nek van ezután is nyílt implementációja (ahogy a JavaFX-nek is), a Pillér kedves fejlesztői használhatnák a technológiát. És akkor még kevésbé függnének attól, hogy Java 8....21 van éppen a user gépére telepítve. Meg hát használhatnának jlinket, custom JRE-vel meg minden egyéb, de hát na, ehhez nem 24-25 éves lemaradásban kéne lenniük.
https://openwebstart.com/
Jelenleg is minden nyomtatványhoz a JNLP az első letöltési lehetőség, bár hagyományos észjárású felhasználó nem azt tölti le, hanem direktben az abevjava_install.jar-t.
Ettől teljesen függetlenül amikor a telepítés végén megkérdezi az installer, hogy akarsz-e parancsikont a telepített alkalmazáshoz, akkor már semmilyen javaws/jnlp nincs a mesében.