Здрвавейте. С 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>

Цитат

Cross-Compilation Options

By default, classes are compiled against the bootstrap and extension classes of the platform that javac shipped with. But javac also supports cross-compiling, where classes are compiled against a bootstrap and extension classes of a different Java platform implementation. It is important to use the -bootclasspath and -extdirs options when cross-compiling.

-target version

Generates class files that target a specified release of the virtual machine. Class files will run on the specified target and on later releases, but not on earlier releases of the JVM. Valid targets are 1.1, 1.2, 1.3, 1.4, 1.5 (also 5), 1.6 (also 6), 1.7 (also 7), and 1.8 (also 8).

The default for the -target option depends on the value of the -source option:

• If the -source option is not specified, then the value of the -target option is 1.8

• If the -source option is 1.2, then the value of the -target option is 1.4

• If the -source option is 1.3, then the value of the -target option is 1.4

• If the -source option is 1.5, then the value of the -target option is 1.8

• If the -source option is 1.6, then the value of the -target is option 1.8

• If the -source option is 1.7, then the value of the -target is option 1.8

• For all other values of the -source option, the value of the -target option is the value of the -source option.

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

Поздрави !

преди 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). Така че и програмистите може да си подложат само мотиката

преди 3 минути, capnemo написа:

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

Възможно е :). Версия 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 грешки  

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

Поздрави !

 

преди 1 минута, soundtracker написа:

....

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

...@SSMeniak

 

 

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

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