Премини към съдържанието
SSMeniak

Java проблем с 32 и 64 битови архитектури

    Препоръчан отговор


    Здрвавейте. С 64 битова машина съм с Linux Mint 17.3 и 64 битова Java инсталиранa на нея и пиша Java програмки с NetBeans. Когато използвам написаното приложение от мене на друг 64 битов компютър с инсталирана 64 битова Java няма проблем, приложението си работи както трябва. Но когато стартирам приложението на 32 битова машина с 32 битова Java то или не тръгва въобще или ако стартира не работи правилно. Не знам дали точно проблема е в разликата на архитектурите но ако някои знае от къде идва проблема моля да сподели.

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Версията на джава, да не е едната стара, а другата нова и да си ползвал методи, дето на едната работят, а на другата не.

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Общо казано няма да е проблема в това дето си мисля. И само още един въпрос, няма значение на колко битова Java пишеш и на колко битова Java го пускаш приложението, в смисъл писал сам програмата на 64 бит OS с 64 бит Java и то си върви и на 32 бит OS с 32 бит Java?


    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 43 минути, SSMeniak написа:

    Общо казано няма да е проблема в това дето си мисля. И само още един въпрос, няма значение на колко битова Java пишеш и на колко битова Java го пускаш приложението, в смисъл писал сам програмата на 64 бит OS с 64 бит Java и то си върви и на 32 бит OS с 32 бит Java?

    Пренесъл си написания код или компилирания файл?

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 3 часа, Реджеп Иведик написа:

    Версията на джава, да не е едната стара, а другата нова и да си ползвал методи, дето на едната работят, а на другата не.

    Java до 1.7 е напълно backward compatible откъм API за поне 2 версии назад. Освен ако колегата не е писал кода си с Java <= 1.5, това не е проблем. Друга е обаче историята за 1.8. Там вече има включено функционално API, което се въвежда за първи път и е резонно на нещо < 1.7 да не върви - т.е. Lambda expressions, Functional интерфейсите и т.н. ще счупят нещата. Освен ако именно това е случая, backward историите отпадат като потенциален проблем.

    От друга страна версиите на 64 и 32 бита произвеждат различен bytecode при компилиране на класовете. Съвсем нормално е bytecode, изгреден за 64 битова платформа да не тръгва на 32 битова.

    В случая, решението не е красиво - трябва да се свали 32-битова Java (JDK), и компилацията да мине през нея. 

    Допълнително, когато се прави компилация на source файлове с JDK8 и ако въпросното нещо ще върви на 1.7 или 1.6,, на компилатора трябва да му се укаже към коя версия точно да генерира bytecode-а. Както споменах по-горе, 8-цата вкарва доста нови неща, които 1.7 и 1.6 не поддържат.

    Тук е документацията на javac командата с всички параметри, които може да приема. Вас Ви интересуваt -target <version> и -source<version>

    Цитат

    Това ще реши проблемите с по-стари версии на Java, но за проблема с 32/64 битовата компилация ще се наложи отделно JDK ...

    Поздрави !

    • Харесва ми 2

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 10 минути, soundtracker написа:

    Java до 1.7 е напълно backward compatible откъм API за поне 2 версии назад. Освен ако колегата не е писал кода си с Java <= 1.5, това не е проблем. Друга е обаче историята за 1.8. Там вече има включено функционално API, което се въвежда за първи път и е резонно на нещо < 1.7 да не върви - т.е. Lambda expressions, Functional интерфейсите и т.н. ще счупят нещата. Освен ако именно това е случая, backward историите отпадат като потенциален проблем.

    ...

    Ако трябва да сме прецизни имам код, който върви на 1.6, но не иска на 1.7 (а не е толкова стар <1.5). Така че и програмистите може да си подложат само мотиката :D

    • Харесва ми 1

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 3 минути, capnemo написа:

    Ако трябва да сме прецизни имам код, който върви на 1.6, но не иска на 1.7 (а не е толкова стар <1.5). Така че и програмистите може да си подложат само мотиката :D

    Възможно е :). Версия 1.7 е първата, която мина под банера на Oracle, като плановете за нея са били грандиозни - по план, нещата, които получихме в 1.8 са били планирани за 1.7 и за да стане ситуацията още по-"розова", голяма част от основните low-level фукнционалности в JRE/JDK, свързани с 1.8 са налични и в 1.7. Не са expose-нати през API-то, защото не са били завършени и по стар програмистки обичай са сметени под килима ... 

    Поне в core частта си, Sun (и до известна степен и Oracle) се придържат към политиките на deprecation анотирането - не махат съответния метод, дават му @depricated и правят overload на метода с нова версия. Факт е, че при компилиране конзолата ще потъне в Warning-и, но компилацията ще мине. 

    P.S. Като едно "изключение на правилото", това абсолютно не важи за Cryptography частта и редовно при upgrade на JRE/JDK, започват да валят чаршафите със security грешки :D 

     @SSMeniak , опитайте с 32-битова версия да компилирате програмата си. Ако и след това има драми, приложете грешката, която Ви се изписва.

    Поздрави !

     

    • Харесва ми 2

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове
    преди 1 минута, soundtracker написа:

    ....

    P.S. Като едно "изключение на правилото", това абсолютно не важи за Cryptography частта и редовно при upgrade на JRE/JDK, започват да валят чаршафите със security грешки :D 

    ...@SSMeniak

     

     

    Тъкмо сигурността ми е проблема, искат за комуникация с ААА TLS (мисля поне 1..1) ама успяхме да намерим заобиколен път и не ъпгрейднахме джавата.... :)

    • Харесва ми 1

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Moeто мнение е, че зависи по-скоро от библиотеките, които се ползват. Също така някои хора използват графичната библиотека SWT, която си има 32 и 64 бита версии, защото съдържа машинен код от графични библиотеки като например GTK+ за Linux.

    • Харесва ми 1

    Сподели този отговор


    Линк към този отговор
    Сподели в други сайтове

    Регистрирайте се или влезете в профила си за да коментирате

    Трябва да имате регистрация за да може да коментирате това

    Регистрирайте се

    Създайте нова регистрация в нашия форум. Лесно е!

    Нова регистрация

    Вход

    Имате регистрация? Влезте от тук.

    Вход


    ×

    Информация

    Този сайт използва бисквитки (cookies), за най-доброто потребителско изживяване. С използването му, вие приемате нашите Условия за ползване.