кросс-платформность на Java

[crazy-mike]

1. POSIX определяет стандарты кодировок?
2. Насколько Win совместима с POSIX?

Фактически - да (для stdio.h :grum: ). wfopen и fopen. Там просто явно разделяют UNICODE (UTF-16) и 8битовые наборы символов.
1. Глюк реализации JVM именно и состоит в том - что они это попытались сделать "невидимым" (transparent). Оно даже как бы и получилось - но "не до конца".
2. Windows NT является POSIX-системой по утверждениям Microsoft (на уровне библиотеки crtl.dll :grum: (C runtime library)).

[crazy-mike]

Но новая компания уже вряд ли будет на C++ писать.

Для микропроцессоров и микроконтроллеров - довольно много ещё всего пишут на C++.

[смешно]

самая большая "кросс проблема" это что-бы одинaково показывало в IE и Firefox. :grum:(я не только про джаву)

[crazy-mike]

самая большая "кросс проблема" это что-бы одинaково показывало в IE и Firefox. :grum:(я не только про джаву)

:grum:
K-Meleon 1.5.2 :grum:
Google Chrome :grum:
Seam Monkey :grum:
Safari :grum:
Это всё "под виндой". Но под виндой они все используют Sun JRE (если оно установлено).
IE и FireFox - используют Sun-овский плагин в этом случае.
Opera вот "под виндой" использует свою Java-машину (а под FreeBSD - любую установленную. (какую найдёт :grum: ) Там это можно в настройках браузера задавать).

[crazy-mike]

java -jar mg.jar
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java :620)
at java.security.SecureClassLoader.defineClass(Secure ClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader .java:260)
at java.net.URLClassLoader.access$100(URLClassLoader. java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java: 195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.j ava:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:3 06)
at sun.misc.Launcher$AppClassLoader.loadClass(Launche r.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:2 51)
at java.lang.ClassLoader.loadClassInternal(ClassLoade r.java:319)

:cranky: Там только swing!!!!!!!!!! Но всё сделано под виндой (JDK6 Java SE) - а хотелось запустить в UNIX (FreeBSD)!!!!!!!!!! (open JDK 1.5 diablo) Ну - типа не запустилось!!!!!!!!
:grum:
Написано однажды - нуждается в перекомпиляции!!!!!!!!!!
:cranky: там конечно же можно пробовать задавать "совместимость с версией" , но тем не менее...
Под kaffee - тоже ведь работать не будет!!!!! :grum:
coocoo# javac -encoding CP1251 mg.java
coocoo# jar -cfm mg.jar mg.txt *.class
coocoo# java -jar mg.jar
coocoo#
А после перекомпиляции - работает!!!!! Тогда - чем же Java отличается от g++ (GNU C++) ?????????? Тем более - что runtime library для gcc как раз очень даже неплохо стандартизирована , а на g++/gcc MinGW можно под *NIX создавать исполняемые файлы для Win32!!!!!!!!!!
Даже апплеты - тоже работают ненормально!!!!! :cranky:
Сообщение Invalid bytecode в браузере прямо "улыбает"!!!!!
:evillaugh:
Но вот откомпиленное под FreeBSD (JDK 1.5 Diablo) - нормально работает под виндой!!!!!!!!!!!!!!! (в JRE 1.6 )
У меня вот этот "старый релиз" под FreeBSD:
http://www.freebsdfoundation.org/downloads/java15.shtml
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01)
Java HotSpot(TM) Client VM (build diablo-1.5.0_07-b01, mixed mode)
Под WinXP - Java SE 6
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode)

Кстати - перекомпиляция под виндой по javac -source 1.5 yo.java --- в этом случае не помогает!!!!!

[crazy-mike]

:grum: Но вот откомпилил апплет под FreeBSD - и выгрузил на сервер. И оно нормально работает и на винде , и на FreeBSD (с браузером Opera 9.64 ). :grum:
Вот - нет под рукой сейчас ни одного Linux-а. Даже интересно - если бы кто-то попробовал под Linux эту хрень выполнить.
Сейчас запихну её на mynet.ho.ua куда-нибудь...:grum:
http://mynet.ho.ua/mu.html == апплет "там тупой по максимуму" (создаёт такой гламурный жёлтенький JInternalFrame по нажатию кнопки)

import java.lang.*;
  import java.awt.*;
  import java.awt.event.*;
  import javax.swing.*;



  class MyF extends JInternalFrame {
    public MyF()
    { super("Приветик");
      setContentPane(new JPanel());
      getContentPane().setBackground(new Color(0xff,0xff,0));
      add(new JLabel("Приветик!"));
      setVisible(true);
      pack();        
    }
  } 




  final public class Ma extends JApplet implements ActionListener {
    final public void actionPerformed(ActionEvent e)
    { if("do".equals(e.getActionCommand())) {
        JOptionPane.showMessageDialog(this,"Привет!","Hi!",
        JOptionPane.INFORMATION_MESSAGE);                
        MyF f=new MyF();
        add(f);
      };
    }
    
    final public void init() {
      JPanel p;
      JButton b;
      p=new JPanel();
      b=new JButton("Выполнить!"); b.addActionListener(this); b.setActionCommand("do");
      p.setBackground(new Color(0,0xff,0xff)); p.add(b);
      setContentPane(p);                  
    } 

  } 

[In2HiDef]

OS default behavour === byte stream (без всякой перекодировки) для текстовых файлов (кроме wchar_t ). Ключ encoding CP1251 - для компилятора означает перекодировку всего из UNICODE в windows-1251.
"Оно" и перекодирует всё. Но с input/output streams оно обращается "по-варварски". Когда компилятор перевёл литерал из windows-1251 в UTF-8 , то JRE при выводе такой хреновины в "текст" об этом не знает. А должно бы (можно было инфу в дескрипторе константы менять). Т.е. - это самый настоящий "глюк реализации".

Майк, не морочи себе голову опциями компайлера. Куда как естественней надеяться на внутреннее представление utf-8, и явно указывать внешнюю кодировку. Вот тебе и байтовый стрим.

Что касается "странностей компиляции"– если бы ко мне пришел инженер с такими делами, я бы его слушал ровно 1 минуту, потом послал работать, а в свободное время писать каменты Биллу Джою.

[Sixteen]

Майк, не морочи себе голову опциями компайлера. Куда как естественней надеяться на внутреннее представление утф-8, и явно указывать внешнюю кодировку. Вот тебе и байтовый стрим.

Что касается "странностей компиляции"– если бы ко мне пришел инженер с такими делами, я бы его слушал ровно 1 минуту, потом послал работать, а в свободное время писать каменты Биллу Джою.

ух ты. менеджыр. Майки, среди нас запахло менеджериным духом.
покатаюся поваляюся пажравши интухайдефского мяса!

[In2HiDef]

:fig:

[Sixteen]

:фиг:

хи хи хи. испужалсо! так и надо!