Miért is szeretem a Java-t

A minap hoztak javításra egy Siemens Logot amit szerettem volna letesztelni a javítás végeztével.
Ez a rajta lévő program lementését, illetve egy IO tesztelő program feltöltését foglalja magában amivel végig tudom csattogtatni a reléket.

Süldő egyetemista koromban volt egyszer egy Logo-m, még örömködtem is a HUP-on hogy milyen fasza, hogy lenne Linux-ra fejlesztőkörnyezet hozzá még ha Java-s is meg nem is működik.

Mondom csak eltelt 11 év csak eljött azóta a Java éve Linuxon, nem szopok egyszerűsítem az életem Windowsos VM-el.
 

Már nem emlékszem 2010-ben mi volt épp a verzió de most  8.3-nál tart a Siemens.
Letöltöttem hát, kiderült, hogy van 32 és 64 bites Linuxos installerük is, micsoda kényeztetés!
Feltelepítettem a 64 bites verziót egy KUbuntu 20.04 64 bit alá.
A cucc hozza a saját JRE-t:


mm@lapos:/opt/Siemens/LOGOComfort_V8.3/jre$ java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

Elindulni a program már elindul (nem úgy mint 2010-ben), azonban bármilyen hardware függő dolgot próbálok az alábbi üzenetet kapom:

https://i.imgur.com/WikPt9O.png

Itt elkezdett rezegni a léc, hogy nyomok egy rf -rf-et a telepített mappára és indítom a VM-et de a sötét oldal erősebb volt, így elővettem a JD-GUI-t mert egyrészt kíváncsi voltam, hogy obfuszkálnak-e már német barátaink, másrészt meg ez az egy dolog amit szeretek a Java-ban.
Anno 2010-ben is elkezdtem patchelni, de eredményt akkor nem értem el, el is adtam a Logot nem sokkal később.

Protip: legfrissebb (1.6.6) JD-GUI-val érdemes próbálkozni, mert a régebbi (Ubuntu-val szállított) visszafejti ugyan a kódok nagy részét de vannak dolgok amik nem fordíthatóak le utána.

A lib/classes.jar fájlt tartalmazza a lényegi kódokat, a többi jar a lib mappában az 3rd party kódokat tartalmaz.

A classes.jar fájlt kibontva némi szöveges kereséssel eljutottam a DE/siemens/ad/logo/util/dipmgr/NetworkAdapterSuseUtil.java fájlig amibe az alábbi függvény található:

protected boolean readDHCPStatus(String adaptername, String macaddr) throws UnsupportedOperationException {
    boolean useDhcp = false;
    String filename = "/etc/sysconfig/network/ifcfg-" + adaptername;
    File cfgFile = new File(filename);
    if (!cfgFile.exists()) {
      String adaptertype = null;
      if (adaptername.toLowerCase().startsWith("eth")) {
        adaptertype = "eth";
      } else if (adaptername.toLowerCase().startsWith("wlan")) {
        adaptertype = "wlan";
      } 
      if (adaptertype == null)
        throw new UnsupportedOperationException("adapter type is not support"); 
      filename = "/etc/sysconfig/network/ifcfg-" + adaptertype + "-id-" + macaddr;
      cfgFile = new File(filename);
      if (!cfgFile.exists())
        throw new UnsupportedOperationException("cfg script file format is not support"); 
    } 
    try {
      FileReader fr = new FileReader(cfgFile);
      BufferedReader br = new BufferedReader(fr);
      String line = null;
      while ((line = br.readLine()) != null) {
        line = line.toLowerCase();
        if (line.startsWith("bootproto") && line.contains("dhcp")) {
          useDhcp = true;
          break;
        } 
      } 
      br.close();
      fr.close();
    } catch (IOException e) {}
    return useDhcp;
  }

Ubuntu-n az /etc/sysconfig mappa at all hiányzik, illetve én soros portos kábellel akarom csak piszkálni a Logo-t.

Körbenéztem a readDHCPStatus hívásokat, a függvény kizárólag egy UI-on megjelenítésre van használva, úgyhogy egy return true; sor beiktatása mellett döntöttem.

A forrás fájl (*.java) módosítása után a következő módon lehet a class fájlt létrehozni:

A JD-GUI-val visszafejtett mappát a lib mappába tömörítettem ki a jar fájlok mellé majd így a lib mappában:

javac -cp $PWD/bcprov-jdk15to18-164.jar  -cp $PWD/bsh.jar  -cp $PWD/ComfortIPUtil.jar  -cp $PWD/dom4j-2.1.3.jar  -cp $PWD/itext.jar  -cp $PWD/jaxen-1.1-beta-10.jar  -cp $PWD/jcalendar.jar  -cp $PWD/jhall.jar  -cp $PWD/jna.jar  -cp $PWD/junit.jar  -cp $PWD/kunststoff.jar  -cp $PWD/RXTXcomm.jar  -cp $PWD/slsecurity.jar -cp $PWD/classes.jar DE/siemens/ad/logo/util/dipmgr/NetworkAdapterSuseUtil.java

A classpathba (-cp argumentummal) betettem az összes jar fájlt a lib mappából. (ls -1 *.jar meg némi regexpes csere segített.)

Ami itt beugratós lehet az a javac és a program által használt JRE verziójának kompatibilitása.

Régebbi Logo szoftverek még 1.7-es javaval mentek, de szerencsére a 8.3-as már 1.8 ami azonos az Ubuntu-val szállított verzióval. (Nem kellett ócska JDK-t bugázni az Oracletől.)

Az így létrejött class fájlt pedig így lehet a classes.jar-ba visszatenni:

jar uf classes.jar DE/siemens/ad/logo/util/dipmgr/NetworkAdapterSuseUtil.class

Ezen módosítás után pedig: profit!

https://i.imgur.com/y51sJXu.png

A fentiek fényében a Siemens oldalán álló "Runs on all Linux distributions on which Java 2 runs." kissé meredeken hangzik, de hát ha azt vesszük futni fut, csak nem működik :D

Hozzászólások

Jó hát ilyet nyelvfüggetlenül el lehet követni, nem a Java sara, max annyi, ha nem lehetett megvalósítani rendszerfüggetlenül a függvényt.

olvass utana a "java agent" dolognak, azzal univerzalisan tudsz java class betolteskor modositani. igy nemkell az eredeti jar-ban turkalni.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szerkesztve: 2021. 08. 08., v – 17:36

Meg lehet adni a javac-nek a -target argumentummal milyen verzióra fordítson, így nem gond ha újabb a JDK-d. Illetve 9-es verziótól a --release használata javasolt.

Egyébként ez a readDHCPStatus metódus a tipikus példája hogyan lehet egy platformfüggetlen nyelven platformfüggő kódot írni, a /etc/sysconfig az a Red Hat alapú disztribúciókban szokott tipikusan előfordulni. A hibaüzenetben található nyelvtani hibával együtt el tudom képzelni, hogy milyen fejlesztők dolgoztak ezen a kódon.

el tudom képzelni, hogy milyen fejlesztők dolgoztak ezen a kódon.

Az utolsó precíz német meghalt Sztálingrád alatt.

 

Egyébként ez a readDHCPStatus metódus a tipikus példája hogyan lehet egy platformfüggetlen nyelven platformfüggő kódot írni, a /etc/sysconfig az a Red Hat alapú disztribúciókban szokott tipikusan előfordulni.

Nekem csak az bántja a lelkem, hogy ez egy olyan funkció ami tényleg nincs használva semmire csak egy checkbox bepipálására megjelenítésként.

A JDK verzió tippet köszönöm, erről nem tudtam :)