The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Обновление JavaFX 2.1, Java SE 6 Update 32 и Java SE 7 Update 4 с поддержкой Mac OS X

27.04.2012 10:27

Доступны корректирующие выпуски Java SE 6 Update 32 с исправлением 45 ошибок и Java SE 7 Update 4 с устранением 473 ошибок. В представленных выпусках представлены только не связанные с безопасностью исправления, устранения уязвимостей были представлены в версиях Java SE 6 Update 31 и Java SE 7 Update 3. Большое число исправлений в Java SE 7 Update 4 связано с тем, что данная версия является вторым корректирующим выпуском после релиза Java SE 7, кодовая база которого подверглась дополнительной стабилизации. Java SE 7 Update 4 является первым потребительским релизом Java 7 JRE и будет рекомендован в качестве версии Java по умолчанию на Java.com, начиная с первого мая.

Среди новшеств, добавленных в Java SE 7 Update 4:

  • Обеспечена поддержка платформы Mac OS X (ранее компания Apple выпускала своими силами сборки JDK, но затем присоединилась к работе над проектом OpenJDK). Java SE 7u4 представлен только в 64-разрядной сборке для Mac OS X Lion и более новых версий. В состав не включены клиентские составляющие, такие как Java Plugin и Java Web Start. JRE для Mac OS X будет доступен в следующих обновлениях JDK 7. До этого момента предлагается установить предварительную тестовую версию Java SE 7 Update 6 с JRE и поддержкой выполнения апплетов;
  • Продолжена работа по слиянию Oracle Java HotSpot JVM и Oracle JRockit JVM. До 23 версии обновлена виртуальная машина HotSpot, в которой портированы некоторые возможности JRockit JVM, такие как расширенный агент JMX, поддержка текстовых дампов состояния VM и набор диагностических команд (jcmd). Кроме того в HotSpot интегрированы все связанные с обеспечением высокой производительности улучшения JRockit. Реализован ряд оптимизаций производительности JVM, особенно заметных ускорением работы продуктов Oracle Fusion Middleware;
  • В число официально поддерживаемых сборщиков мусора включён G1 (Garbage First), оптимизированный для работы с приложениями, потребляющими большой объём памяти и работающими на многоядерных системах, требуя при этом предсказуемых и контролируемых задержек, вызванных работой сборщика мусора;
  • JavaFX 2.1 Runtime теперь интегрирован с JDK и устанавливается одновременно с JRE 7 в процессе автообновления;
  • JAXP обновлён до версии 1.4.6;
  • БД Java DB обновлена до версии 10.8.2.2;
  • Задействованы специфичные для процессоров SPARC T4 оптимизации криптографических операций;
  • Добавлена опция "-XX:+UnlockCommercialFeatures", позволяющая контролировать доступность возможностей, подлежащих коммерческому лицензированию.

Одновременно анонсирован выход пакета JavaFX 2.1 в котором значительно расширена поддержка платформ, отличных от Windows. В частности, начиная с версии 2.1 добавлена поддержка разработки в Linux и Mac OS X. В новой версии также доведены до полноценного состояния средства разработки JavaFX-приложений на Java, расширено число доступных элементов интерфейса (например, добавлены стековые диаграммы, элементы управления для комбинированных форм, общее меню).

Увеличено качество рендеринга шрифтов для LCD-экранов, реализован субпиксельный рендеринг шрифтов. Добавлена поддержка проигрывания мультимедиа контента в формате MPEG-4 с видео H.264/AVC и звуком AAC. Подготовлена поддержка WebView для обеспечения вызова Java-методов из JavaScript, что позволяет создавать HTML/JavaScript приложения, обращающиеся к Java API для задействования специфичных возможностей Java. Кроме того, началось распространение предварительной версии визуального построителя интерфейса JavaFX Scene Builder 1.0, позволяющем генерировать определения шаблонов интерфейса на основанном на XML языке разметки FXML.

Платформа JavaFX предназначена для разработки интерактивных графических приложений, унифицированных для выполнения на широком спектре платформ - от настольных систем, до web-браузеров и мобильных телефонов. Если раньше для создания приложений требовалось изучать специальный язык JavaFX Script, то начиная с выпуска JavaFX 2.0 обеспечена возможность создания JavaFX-приложений, написанных целиком на языке Java. Для разработки приложений доступен богатый графический и мультимедиа API, упрощающий создание визуальных приложений.

В качестве дополнения, можно отметить, что комитет JCP (Java Community Process) выпустил черновой вариант спецификации Java EE 7 (Java Platform Enterprise Edition). Обсуждение черновика и приём комментариев продлится до 23 мая. Среди ключевых нововведений Java EE 7 отмечается включение интерфейсов для организации запуска и развёртывания промышленных приложений в окружении облачных PaaS-систем (платформа как сервис). Кроме того, в рамках черновика стандарта представлены обновлённые варианты спецификаций Java Persistence API2.1 (JSR 338), Java API for RESTful Web Services 2.0 (JSR 339), Expression Language 3.0 (JSR 341), Java Message Service 2.0 (JSR 343), JavaServer Faces 2.2 (JSR 344), Enterprise JavaBeans 3.2 (JSR 345), Contexts and Dependency Injection 1.1 (JSR 346) и Bean Validation 1.1 (JSR 349);

  1. Главная ссылка к новости (http://www.oracle.com/us/corpo...)
  2. OpenNews: Время жизни Java SE 6 продлено до ноября
  3. OpenNews: Apple на пути к удалению Java из состава Mac OS X
  4. OpenNews: Компания Oracle анонсировала выход Java SE 7
  5. OpenNews: Релиз свободного Java-пакета IcedTea 2.0.
  6. OpenNews: Apple присоединяется к OpenJDK с целью развития Java для MacOS X как открытого проекта
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/33711-java
Ключевые слова: java, jdk, javafx
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (63) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:50, 27/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ура,это офигенно. JavaFX в составе Java – это круче чем WPF для клиентских приложений. Вместе со Scene Builder это супер
     
     
  • 2.5, VoDA (ok), 12:12, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз наоборот :'(

    JavaFX упилена и не позволяет устранить один из фундаментальных недостатков java - сложность создания GUI приложений.

    Тот же C# на поле GUI легко рвет java в лохмотья (((


    PS senior java developer, так что могу спорить о вкусе устриц и java ;)))

     
     
  • 3.8, жабабыдлокодер (ok), 12:19, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    NetBeans удовлетворительно эти самые гуи делает.
     
     
  • 4.15, VoDA (ok), 14:26, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Именно удовлетворительно. Поработай с нативными MS гридами, а затем повтори то же самое на чистом Swing. И засеки сколько времени ушло на разобраться.

    По java я был вынужден прочитать несколько книг чтобы понимать механику работы... под MS C# достаточно было посмотреть на работающие примеры и скопировать.


    PS на вопрос что мешало копировать java отвечу, что layout managers это зло. И необходимость под каждый класс делать биндинг на контролы в таблицах тоже зло.

     
     
  • 5.18, Аноним (-), 14:54, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты не "senior java developer", ты просто толстый. JavaFX не связан со swing никак.
     
     
  • 6.22, Аноним (-), 16:22, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    +1

    Вот что бывает когда человек хочет прикинутся тем кем он не является. )))

    P.S. Для тех кто не понял, тот "senior java developer" даже близко не понимает о чем идет речь.

     
  • 6.29, VoDA (ok), 19:43, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а каким еще образом рисовать UI после того как JavaXF script был удален из JavaFX?
     
     
  • 7.33, Аноним (-), 21:49, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    import javafx.application.Application;
    import javafx.scene.Group;
    import javafx.scene.Scene;
    import javafx.scene.shape.Circle;
    import javafx.stage.Stage;

    public class MyApp extends Application {
        public void start(Stage stage) {
            Circle circ = new Circle(40, 40, 30);
            Group root = new Group(circ);
            Scene scene = new Scene(root, 400, 300);

            stage.setTitle("My JavaFX Application");
            stage.setScene(scene);
            stage.show();
        }
    }

     
     
  • 8.59, VoDA (ok), 09:23, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это конечно лучше голого свинга, но как вывести таблицу с данными из листа объек... текст свёрнут, показать
     
     
  • 9.61, Аноним (-), 10:00, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Давай я почитаю документацию за тебя TableView Person table new TableView Pe... текст свёрнут, показать
     
     
  • 10.62, VoDA (ok), 12:58, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Спасибо, действительно сделали какую то реализацию тейбла Хотя криворукость раз... текст свёрнут, показать
     
  • 7.55, a (??), 08:31, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Fxml
     
     
  • 8.58, VoDA (ok), 09:19, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    FXML не является стандартом для java-программирования ... текст свёрнут, показать
     
     
  • 9.60, Аноним (-), 09:57, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Так толсто, что даже толсто ... текст свёрнут, показать
     
  • 5.20, жабабыдлокодер (ok), 15:53, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > layout managers это зло.

    layout manager-ы - мягкие, теплые и пушистые... Вы просто не умеете их готовить. Регулируйте расположение элементов дополнительными JPanel-ями, и познайте дао.


     
     
  • 6.23, Аноним (-), 16:24, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> layout managers это зло.
    > layout manager-ы - мягкие, теплые и пушистые... Вы просто не умеете их
    > готовить. Регулируйте расположение элементов дополнительными JPanel-ями, и познайте
    > дао.

    Опять таки, речь не о Swing, а JavaFX, так что вопрос можно снимать (Там дао можно познать исключительно на layout manager-ах)...

     
  • 6.30, VoDA (ok), 19:44, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> layout managers это зло.
    > layout manager-ы - мягкие, теплые и пушистые... Вы просто не умеете их
    > готовить. Регулируйте расположение элементов дополнительными JPanel-ями, и познайте
    > дао.

    Совсем не умею. Пробовал и переплевался =((( даже книга Портянкина не помогла ощутить дао =(((

     
  • 6.34, Аноним (-), 21:49, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Регулируйте расположение элементов дополнительными JPanel-ями, и познайте дао.

    Костыль же?

     
     
  • 7.39, жабабыдлокодер (ok), 22:58, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В Java существуют два способа размещения визуальных элементов: жестко фиксированный и плавающий. Лично я предпочитаю плавающий, для которого и приходится устанавливать дополнительные элементы. В плюсах - красивое и удобное масштабирование окон. Но можно задать местоположение и жестко - что удобно лишь для диалоговых окон, зато ничего вспомогательного не требует.
     
     
  • 8.46, wfrr (ok), 01:13, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Приходиться если кое чего не осилил http docs oracle com javase 6 docs api jav... текст свёрнут, показать
     
     
  • 9.53, жабабыдлокодер (ok), 07:36, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Предпочитаю BorderLayout, более простой и ясный ... текст свёрнут, показать
     
     
  • 10.56, kosmonaFFFt (?), 08:49, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ИМХО MigLayout самодостаточен за исключением некоторых вещей типа CardLayout , ... текст свёрнут, показать
     
     
  • 11.57, жабабыдлокодер (ok), 09:10, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    То есть, удобных способов построения пользовательского интерфейса достаточно Чт... текст свёрнут, показать
     
  • 10.64, Аноним (-), 14:22, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а лучше BoxLayout в связке с BorderLayout, практически для всего хватает ... текст свёрнут, показать
     
  • 5.63, Аноним (-), 14:16, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Толсто.
    Если нативные МС гриды так хороши, зачем тогда, почти на вопрос "вменяемый грид для C# .net winforms" дают ответ DevExpress xtragrid.
    Признайся, ты не ведь не senior java developer.
     
     
  • 6.65, umbr (ok), 21:40, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Синьор не станет писать такую чушь: http://www.opennet.dev/opennews/art.shtml?num=33711#14
     
  • 3.17, Xasd (ok), 14:34, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > PS senior java developer, так что могу спорить о вкусе устриц и java ;)))

    пользуясь случаем присутствия специалиста -- спрошу следущее...

    ...когда в Java (языке) появится конструкция на подобие:




            import java.util.Date as UtilDate;
            import org.blahblablah.db.Date as DbDate;


    ???

    во всех же языках это есть (включая C++ и Scala, которые какбы родственники чтоле) кроме Java , но Java-создатели решили выделиться чтоли в этом смысле?

    блин.. ды даже сраный Javascript (CommonJS и его Node.Js, или Worker() в www-browser-javascript) импортирует модуль с любым-выбираемым именем.. и только один чтоле Java-Language альтернативно одарённый??? :-)

    [простите! Javascript конешно же не сраный, эт я для красивого словца:)]

    ..короткие алиасы нельзя делать в Java -- чтобы побольше текста было в программах? чтобы каждый раз писать в тексте программы полностью "org.blahblablah.db.Date" и типа программа выглядет СОЛИДНЕЕ так?? xD

     
     
  • 4.19, жабабыдлокодер (ok), 15:50, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    По мне, так никогда бы.
    Иначе может быть следующее:

    http://lurkmore.to/%D0%9A%D0%BE%D0%BF%D0&#

    Такие сипатишные алиасы...

     
     
  • 5.43, Xasd (ok), 23:18, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > По мне, так никогда бы.
    > Иначе может быть следующее:
    > http://lurkmore.to/%D0%9A%D0%BE%D0%BF%D0&#
    > Такие сипатишные алиасы...

    хаха! мем зачотный между прочим..

    ...ноо неее... вполне ОЧЕВИДНО же что #define это зло.. тут никто не спорит :-)

    но я надеюсь зоркие комментаторы смогли различить суть #define от сути import-as ???

    если нет, то объясняю некоторые различия :) :

    1. #define делает алиасы чего угодно, а import-as делает алиас только импортируемой чужемодульной сущности

    2. #define работает глобально (включая действие на другие модули), а import-as имеет своё синонимическое воздействие только внутри текущего модуля

     
  • 4.24, Аноним (-), 16:30, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >...когда в Java (языке) появится конструкция на подобие:
    >
    >


    >        import java.util.Date as UtilDate;
    >        import org.blahblablah.db.Date as DbDate;
    >

    Пользуясь случаем отвечу: никогда :)

    В ней много чего еще не появится. Если вам это нужно, то используйте как вы сказали scala. Если Вы этого ждете именно в java, то зря, не дождетесь, используйте что-то другое (то что вы назвали).

     
  • 4.25, Аноним (-), 16:36, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >..короткие алиасы нельзя делать в Java -- чтобы побольше текста было в программах? чтобы каждый раз писать в тексте программы полностью "org.blahblablah.db.Date" и типа программа выглядет СОЛИДНЕЕ так?? xD

    Тро-ло-ло :)

    Java славится своим выпрямлением рук даже у быдлокодеров. Это одна из фич, не пускающих быдлокодеров в уютную java. Или ты пишешь программы нормально, или идешь писать на чем то еще. Если у тебя относительно часто возникает указанная тобою проблема (а не в очень частных случаев) значит это противоречит нормальному дизайну программы, значит тебе не место носить гордое имя Java разработчика для сурового и надежного Ынтерпрайза :)

     
  • 4.31, VoDA (ok), 19:50, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >[оверквотинг удален]
    > пользуясь случаем присутствия специалиста -- спрошу следущее...
    > ...когда в Java (языке) появится конструкция на подобие:
    >


    >         import java.util.Date as UtilDate;
    >         import org.blahblablah.db.Date as DbDate;
    >


    > ???
    > во всех же языках это есть (включая C++ и Scala, которые какбы
    > родственники чтоле) кроме Java , но Java-создатели решили выделиться чтоли в
    > этом смысле?

    Sun-овцы решили закрыть еще одну возможность гов... криво писать.

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

     
     
  • 5.32, жабабыдлокодер (ok), 21:25, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В стандартных библиотеках utils и sql действительно есть разные классы Date. Иногда это доставляет неудобство: приходится писать название целиком. Но ради буквально единичного случая внедрять "ошибко-опасные" решения - по-моему, перебор.
     
     
  • 6.40, Xasd (ok), 23:00, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > внедрять "ошибко-опасные" решения - по-моему, перебор.

    пусть тогда исключат while-и-for из языка ... ато вдруг бесконечный цыкл... ВНИМАНИЕ ОПАСНО!!! xD xD

    # p.s.: а вот что опасного в алиасе (алиасе-во-время-импорта именно!) -- не очень вобщето понятно (пример можно в студию? :))...
    этоже не #define'какойнить'страшный

    # p.p.s.: только пожааааааааалуйста -- НЕ надо примеры на подобие:
                import org.blahblablah.db.Date as ArrayList; // ну ведь по случайной ошибке такое написать не получится xD

     
  • 5.35, Xasd (ok), 21:52, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Sun-овцы решили закрыть еще одну возможность гов... криво писать.

    <sarcasm>




            UtilDate dateA = new UtilDate(); // говнокод!
            // ...
            Date dateB = new Date(); // отличный код!
            // ...
            java.util.Date dateC = new java.util.Date(); // тоже отличный код!



    </sarcasm>

    проснитесь! АУ!!

     
     
  • 6.36, Аноним (-), 22:38, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Перед вами все разложили.

    А так +1

     
     
  • 7.37, Xasd (ok), 22:54, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ну и я разложил :) ведь
     
  • 6.38, Xasd (ok), 22:57, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > java.util.Date dateC = new java.util.Date(); // тоже отличный код!

    ...а главное солидный!

    # fixed :-)

     
  • 6.41, жабабыдлокодер (ok), 23:04, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Meine lieber gott...
    Ну, если уж так свербит, кто мешает сделать вот так:

    public class UtilDate extends java.util.Date {
    }

    UtilDate dateB = new UtilDate();

     
     
  • 7.42, Xasd (ok), 23:08, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    слава иегове! отличный костль!

    не всё потеряно значит в этом языке xD

    спасибо, буду пользовать xD

    ой нет... кое где придётся в коде всётаки писать "java.util.Date" ... например если функция [некая, чужамодульная] возвращает объекты этого типа "java.util.Date" (а не принимает его в качестве аргумента)

    вобщем не подходит.. нужны нормальные импортоалиасы

     
     
  • 8.44, жабабыдлокодер (ok), 23:33, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы вообще хоть что-нибудь на жабе писали или так, просто мимо проходили есть ме... текст свёрнут, показать
     
     
  • 9.47, Xasd (ok), 01:19, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    который предположим возврашает НЕ объекты класса UtilDate а совершенно други... текст свёрнут, показать
     
     
  • 10.54, жабабыдлокодер (ok), 08:19, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Если такая аллергия на написание полного пути - можно попробовать и через интерф... текст свёрнут, показать
     
  • 5.48, Xasd (ok), 01:43, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Когда в одном файле используются несколько классов с одинаковыми названиями, то это повод отрефакторить код и сменить имена похожих классов.

    здесь мы имеем дело с Коллизией Имён (проблема которая устранена у всех остальных языков (кроме Java), в которых есть пространства имён)

    (тоесть в Java существуют пространства имён, но они не избавляют от коллизий xD.. <sarcasm>ГЕНИАЛЬНО!!!</sarcasm>)

    а теперь давайте подумаем когда же возникают вероятности появления этих Коллизии Имён в Java (???)...

    а очень просто..: вероятности возникают тогда, когда используются два сторонних модуля (авторы которых друг друга НЕ знают, и случайно назвали классы имён одинаково... но якобы страшного ничего нет ведь пространства имён-то разные... но страшного ничего нет -- лишь во всех языках кроме Java :))

    но так как разработка программ -- это всегда от части эксперименты со смешиванием новых компонентов (модулей).. зачастую разработчикам модулей заранее сложно предсказать какой "коктель" из других модулей будет использован в будущем :-), так как вообще трудно заранее сказать какие в будущем будут новые виды программ

    И НАФИГА ТОГДА вообще в Java нужны пространства имён, если они доконца не защщищают от коллизий имён классов? похоже на какуюто инженерную чушь xD

    ...в таком случае -- создатели Java могли-бы срать...(простите за выражение)...срать классами прямо в глобальное пространство имён xD !! [также, как это было в старом PHP, до версии PHP-5.3] а в моменты коллизий умникибы точно также говорилибы: "Когда используются несколько классов с одинаковыми названиями, то значит надо сменить имена классов"

    но это же явная недоработка Java-Языка... а вы тут на форуме говорите что это якобы приемущество.. *LOL*

    > Sun-овцы решили закрыть еще одну возможность гов... криво писать.

    просто сглупили. недоглядели... то что это есть недоделка это очевидно... :-)

    ...вопрос лишь в том когда они собираются это исправлять

     
     
  • 6.66, Aleks Revo (ok), 14:38, 30/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А ещё Java не меняет пелёнки, так что это инструмент не для всех, да :-)
     

  • 1.2, ыгчч (?), 11:24, 27/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > В число официально поддерживаемых сборщиков мусора включён G1 (Garbage First)

    Название неимоверно доставляет.
    Прямо рекламный слоган Java - Garbage First.

     
  • 1.3, Аноним (-), 11:50, 27/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Задействованы специфичные для процессоров SPARC T4 оптимизации криптографических операций

    а для интелей они AES и/или AVX не задействовали?  *lol*

     
     
  • 2.4, ыгчч (?), 12:11, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не *lol* а маркетинг. Надо ж эту хрень (SPARC T4) как-то продавать.
     
  • 2.7, VoDA (ok), 12:16, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Задействованы специфичные для процессоров SPARC T4 оптимизации криптографических операций

    Скорее бонус в том, что криптография сервеной стороны на T4 работает намного-намного-намного быстрее, чем на других процах. И процов много и крипту считать оно может очень быстро.

    Вопрос с криптографией вообще сложный и темный. К примеру в java криптография встраивается в платформу через плагинизацию. Как эти ВНЕШНИЕ для JRE плагины будут оптимизироваться - большой вопрос.

     
     
  • 3.11, umbr (ok), 13:01, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Как эти ВНЕШНИЕ для JRE плагины будут оптимизироваться

    Наверно имеются ввиду оракловские крипто-плагины с нативными либами под Т4.

     
     
  • 4.14, VoDA (ok), 14:21, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>Как эти ВНЕШНИЕ для JRE плагины будут оптимизироваться
    > Наверно имеются ввиду оракловские крипто-плагины с нативными либами под Т4.

    Думаю, что оптимизация идет на уровне самой JMV за счет использования более мощных конструкций CPU для решения крипто-задач.

    Крипто-плагины в том числе и оракловые это java код. Потому любой java код на T4 использующий те же операции должен быть быстрее за счет оптимизаций уровня JMV.

     
     
  • 5.21, umbr (ok), 15:54, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    "Более мощные конструкции CPU" доступны в JVM только через объявление метода нативным и реализацию оного в нативной библиотеке, оптимизированной под конкретный процессор.
    Вся остальная оптимизация либо на уровне байткода, который ничего не знает про CPU, либо JIT-компилятор, который оптимизирует всё подряд, независимо от назначения.
     
     
  • 6.28, VoDA (ok), 19:41, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > "Более мощные конструкции CPU" доступны в JVM только через объявление метода нативным
    > и реализацию оного в нативной библиотеке, оптимизированной под конкретный процессор.
    > Вся остальная оптимизация либо на уровне байткода, который ничего не знает про
    > CPU, либо JIT-компилятор, который оптимизирует всё подряд, независимо от назначения.

    Под множеством методов лежит нативы. Думаю в крипто это еще больше. Так что использование базовых методов из своего java кода вероятно вызывает нативную криптографию где то в нутре JVM.

     
  • 3.13, Аноним (-), 13:17, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > корее бонус в том, что криптография сервеной стороны на T4 работает намного-намного-намного быстрее, чем на других процах. И процов много и крипту считать оно может очень быстро.

    я тестировал одно время, правда не на t4, а на t2, опять же на них количество крипто-функций ограниченное, то есть не всякую крипто-функцию можно отдать крипто процессору для работу. К тому же не забывайте, что у вас только 1 crypto unit на CPU core (8 кор в проце). В общем понятно, так как интелевое ядро гораздо быстрее спаркового, они это как бы доделали. Спрашивается что им мешало это раньше лет на 5 сделать, когда t2 вышли....

     
  • 2.12, h31 (ok), 13:06, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > а для интелей

    Уже давно AES-NI используют.

     

  • 1.6, toany (?), 12:15, 27/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    млин опять бот нет будет на маках, как достает , то что Apple задерживает обновы патча их!!!
    опять будут приходит пакеты в обновлениях по типу "remove mailware" : (((
     
     
  • 2.10, toany (?), 12:32, 27/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    перечитал еще раз новость -->

    >>представленных выпусках представлены только не связанные с безопасностью исправления

    фуххх. както по спокойней стало

     

  • 1.9, toany (?), 12:20, 27/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жду, не дождусь , когда уже Oracle сам допилет  Java Plugin и Java Web Start, JRE в сделующем или через релиз, чтобы свалить с шестерки сразу на семерку и самому контролировать обновы.
     
  • 1.45, ILYA INDIGO (ok), 00:08, 28/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я что один кто юзает openJDK и одному мне насрать на оракловскую жабу?
     
     
  • 2.49, JL2001 (ok), 01:55, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я что один кто юзает openJDK и одному мне насрать на оракловскую жабу?

    в качестве эталонной реализации Java SE 7 использован не проприетарный пакет JDK, а его открытая реализация OpenJDK. Релиз Java SE 7 был сформирован при тесном сотрудничестве инженеров Oracle с участниками мировой экосистемы Java, благодаря работе комитета JCP (Java Community Process) и сообщества OpenJDK.

    Все поставляемые Oracle бинарные файлы эталонной реализации Java SE 7 собраны на основе кодовой базы OpenJDK, сама эталонная реализация полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами. Используя OpenJDK в качестве эталонной реализации сторонние производители могут создавать полностью совместимые с Java SE 7 производные открытые реализации Java. Проприетарный Oracle JDK 7 отличается от OpenJDK наличием некоторых закрытых компонентов, таких как система плагинов, которые не определены в Java-стандарте и не входят в эталонную реализацию Java 7. Oracle JDK и бинарные файлы эталонной реализации, как и раньше, поставляются под лицензией BCL (Binary Code Licence).

    как-то так http://www.opennet.dev/opennews/art.shtml?num=31332

     
     
  • 3.50, ILYA INDIGO (ok), 02:03, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за разъяснение, но я так понял что ситуация с Java SE 7 и openJDK аналогична с MySQL и MariaDB, где имеем недосвободную ораколовскую реализацию, и открытый и более шустрый свободный форк.
     
     
  • 4.51, Java coder (?), 03:09, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Только в данном случае более шустрый вариант это Oracle JDK. И да, 90% разработчиков OpenJDK - работники Oracle.
     
  • 4.52, Avator (ok), 03:42, 28/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вы неправильно поняли. Реально начиная с 7ки разница фактически только в том, что JDK от Oracle поставляется в собранном виде под все платформы, а OpenJDK в виде сорцов (и мэинтейнеры для дистрибутивов сами пакеты из сорцов собирают).
    Разницы в коде фактически нет. (там что-то меньше 0,1% вроде бы было).
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру