Премини към съдържанието
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

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


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

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

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

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

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

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

Вход

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

Вход

×

Информация

Поставихме бисквитки на устройството ви за най-добро потребителско изживяване. Можете да промените настройките си за бисквитки, или в противен случай приемаме, че сте съгласни с нашите условия за ползване.