Доступны (http://www.oracle.com/technetwork/java/javase/downloads/inde...) корректирующие выпуски Java SE 6 Update 32 (http://www.oracle.com/technetwork/java/javase/releasenotes-1...) с исправлением 45 ошибок (http://www.oracle.com/technetwork/java/javase/2col/6u32bugfi...) и Java SE 7 Update 4 (http://www.oracle.com/technetwork/java/javase/7u-relnotes-51...) с устранением 473 ошибок (http://www.oracle.com/technetwork/java/javase/2col/7u4bugfix...). В представленных выпусках представлены только не связанные с безопасностью исправления, устранения уязвимостей были представлены в версиях Java SE 6 Update 31 и Java SE 7 Update 3 (http://www.opennet.ru/opennews/art.shtml?num=33094). Большое число исправлений в Java SE 7 Update 4 связано с тем, что данная версия является вторым корректирующим выпуском после релиза Java SE 7 (http://www.opennet.ru/opennews/art.shtml?num=31332), кодовая база которого подверглась дополнительной стабилизации.
Среди новшеств, добавленных в Java SE 7 Update 4:
- Обеспечена поддержка платформы Mac OS X (ранее компания Apple выпускала своими силами сборки JDK). Java SE 7u4 представлен (http://www.oracle.com/technetwork/java/javase/downloads/inde...) только в 64-разрядной сборки для Mac OS X Lion и более новых версий. В состав не включены клиентские составляющие, такие как Java Plugin и Java Web Start. JRE для Mac OS X будет доступен в следующих обновлениях JDK 7. До этого момента предлагается (http://jdk7.java.net/macportpreview/7u6index.html) установить предварительную тестовую версию Java SE 7 Update 6 с JRE и поддержкой выполнения апплетов;
- До 23 версии обновлена виртуальная машина HotSpot, в которой портированы некоторые возможности JRockit JVM, такие как расширенный агент JMX, поддержка текстовых дампов состояния VM, набор диагностических команд (jcmd);
- В число официально поддерживаемых сборщиков мусора включён G1 (Garbage First), оптимизированный для работы с приложениями, потребляющими большой объём памяти и работающими на многоядерных системах, требуя при этом предсказуемых и контролируемых задержек вызванных необходимостью сборки мусора;- В состав интегрирован JavaFX 2.1 Runtime;
- JAXP обновлён до версии 1.4.6 (http://jaxp.java.net/1.4/1.4.6/ReleaseNotes.html);
- БД Java DB обновлена до версии 10.8.2.2 (http://db.apache.org/derby/releases/release-10.8.2.2.cgi);
- Задействованы специфичные для процессоров SPARC T4 оптимизации криптографических операций
- Добавлена опция "-XX:+UnlockCommercialFeatures", позволяющая контролировать доступность возможностей, подлежащих коммерческому лицензированию.URL: http://www.oracle.com/technetwork/java/javase/downloads/inde...
Новость: http://www.opennet.ru/opennews/art.shtml?num=33711
ура,это офигенно. JavaFX в составе Java – это круче чем WPF для клиентских приложений. Вместе со Scene Builder это супер
Как раз наоборот :'(JavaFX упилена и не позволяет устранить один из фундаментальных недостатков java - сложность создания GUI приложений.
Тот же C# на поле GUI легко рвет java в лохмотья (((
PS senior java developer, так что могу спорить о вкусе устриц и java ;)))
NetBeans удовлетворительно эти самые гуи делает.
Именно удовлетворительно. Поработай с нативными MS гридами, а затем повтори то же самое на чистом Swing. И засеки сколько времени ушло на разобраться.По java я был вынужден прочитать несколько книг чтобы понимать механику работы... под MS C# достаточно было посмотреть на работающие примеры и скопировать.
PS на вопрос что мешало копировать java отвечу, что layout managers это зло. И необходимость под каждый класс делать биндинг на контролы в таблицах тоже зло.
Ты не "senior java developer", ты просто толстый. JavaFX не связан со swing никак.
+1Вот что бывает когда человек хочет прикинутся тем кем он не является. )))
P.S. Для тех кто не понял, тот "senior java developer" даже близко не понимает о чем идет речь.
а каким еще образом рисовать UI после того как JavaXF script был удален из JavaFX?
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();
}
}
Это конечно лучше голого свинга, но как вывести таблицу с данными из листа объектов?MS C# делает это out-of-box. Для swing нужно было писать адаптеры или подобную хрень. JavaFX начальных версий могла похвастаться удобным table, но позже table скипнули. Как сейчас с выводом табличных данных?
PS редактируемые таблички - основа для энтерпрайзных решений.
Давай я почитаю документацию за тебя:TableView<Person> table = new TableView<Person>();
ObservableList<Person> teamMembers = getTeamMembers();
table.setItems(teamMembers);
> Давай я почитаю документацию за тебя:Спасибо, действительно сделали какую то реализацию тейбла.
Хотя криворукость разработчиков поражает воображение. Вместо использования собственного стандарта POJO, они сделали пепелац в виде:
The Person class will consist of a first name and last name properties
//
private StringProperty firstName;
public void setFirstName(String value) { firstNameProperty().set(value); }
public String getFirstName() { return firstNameProperty().get(); }
public StringProperty firstNameProperty() {
if (firstName == null) firstName = new SimpleStringProperty(this, "firstName");
return firstName;
}
//Лучше бы JavaFX script оставили для UI =)))
Fxml
FXML не является стандартом для java-программирования.
Так толсто, что даже толсто.
> layout managers это зло.layout manager-ы - мягкие, теплые и пушистые... Вы просто не умеете их готовить. Регулируйте расположение элементов дополнительными JPanel-ями, и познайте дао.
>> layout managers это зло.
> layout manager-ы - мягкие, теплые и пушистые... Вы просто не умеете их
> готовить. Регулируйте расположение элементов дополнительными JPanel-ями, и познайте
> дао.Опять таки, речь не о Swing, а JavaFX, так что вопрос можно снимать (Там дао можно познать исключительно на layout manager-ах)...
>> layout managers это зло.
> layout manager-ы - мягкие, теплые и пушистые... Вы просто не умеете их
> готовить. Регулируйте расположение элементов дополнительными JPanel-ями, и познайте
> дао.Совсем не умею. Пробовал и переплевался =((( даже книга Портянкина не помогла ощутить дао =(((
>Регулируйте расположение элементов дополнительными JPanel-ями, и познайте дао.Костыль же?
В Java существуют два способа размещения визуальных элементов: жестко фиксированный и плавающий. Лично я предпочитаю плавающий, для которого и приходится устанавливать дополнительные элементы. В плюсах - красивое и удобное масштабирование окон. Но можно задать местоположение и жестко - что удобно лишь для диалоговых окон, зато ничего вспомогательного не требует.
>Лично я предпочитаю плавающий, для которого и приходится устанавливать дополнительные элементы.Приходиться если кое чего не осилил http://docs.oracle.com/javase/6/docs/api/javax/swing/GroupLa...
Предпочитаю BorderLayout, более простой и ясный.
ИМХО MigLayout самодостаточен (за исключением некоторых вещей типа CardLayout), а если еще взять JavaSwingBuilder, то можно получить плюшки в виде декларативного описания фейсов, биндингов и валидации...
То есть, удобных способов построения пользовательского интерфейса достаточно. Что и требовалось доказать. :)
а лучше BoxLayout в связке с BorderLayout, практически для всего хватает.
Толсто.
Если нативные МС гриды так хороши, зачем тогда, почти на вопрос "вменяемый грид для C# .net winforms" дают ответ DevExpress xtragrid.
Признайся, ты не ведь не senior java developer.
Синьор не станет писать такую чушь: http://www.opennet.ru/opennews/art.shtml?num=33711#14
> 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
По мне, так никогда бы.
Иначе может быть следующее:http://lurkmore.to/%D0%9A%D0%BE%D0&...
Такие сипатишные алиасы...
> По мне, так никогда бы.
> Иначе может быть следующее:
> http://lurkmore.to/%D0%9A%D0%BE%D0&...
> Такие сипатишные алиасы...хаха! мем зачотный между прочим..
...ноо неее... вполне ОЧЕВИДНО же что #define это зло.. тут никто не спорит :-)
но я надеюсь зоркие комментаторы смогли различить суть #define от сути import-as ???
если нет, то объясняю некоторые различия :) :
1. #define делает алиасы чего угодно, а import-as делает алиас только импортируемой чужемодульной сущности
2. #define работает глобально (включая действие на другие модули), а import-as имеет своё синонимическое воздействие только внутри текущего модуля
>...когда в Java (языке) появится конструкция на подобие:
>
>
> import java.util.Date as UtilDate;
> import org.blahblablah.db.Date as DbDate;
>Пользуясь случаем отвечу: никогда :)
В ней много чего еще не появится. Если вам это нужно, то используйте как вы сказали scala. Если Вы этого ждете именно в java, то зря, не дождетесь, используйте что-то другое (то что вы назвали).
>..короткие алиасы нельзя делать в Java -- чтобы побольше текста было в программах? чтобы каждый раз писать в тексте программы полностью "org.blahblablah.db.Date" и типа программа выглядет СОЛИДНЕЕ так?? xDТро-ло-ло :)
Java славится своим выпрямлением рук даже у быдлокодеров. Это одна из фич, не пускающих быдлокодеров в уютную java. Или ты пишешь программы нормально, или идешь писать на чем то еще. Если у тебя относительно часто возникает указанная тобою проблема (а не в очень частных случаев) значит это противоречит нормальному дизайну программы, значит тебе не место носить гордое имя Java разработчика для сурового и надежного Ынтерпрайза :)
>[оверквотинг удален]
> пользуясь случаем присутствия специалиста -- спрошу следущее...
> ...когда в Java (языке) появится конструкция на подобие:
>
> import java.util.Date as UtilDate;
> import org.blahblablah.db.Date as DbDate;
>
> ???
> во всех же языках это есть (включая C++ и Scala, которые какбы
> родственники чтоле) кроме Java , но Java-создатели решили выделиться чтоли в
> этом смысле?Sun-овцы решили закрыть еще одну возможность гов... криво писать.
Когда в одном файле используются несколько классов с одинаковыми названиями, то это повод отрефакторить код и сменить имена похожих классов.
В стандартных библиотеках utils и sql действительно есть разные классы Date. Иногда это доставляет неудобство: приходится писать название целиком. Но ради буквально единичного случая внедрять "ошибко-опасные" решения - по-моему, перебор.
> внедрять "ошибко-опасные" решения - по-моему, перебор.пусть тогда исключат while-и-for из языка ... ато вдруг бесконечный цыкл... ВНИМАНИЕ ОПАСНО!!! xD xD
# p.s.: а вот что опасного в алиасе (алиасе-во-время-импорта именно!) -- не очень вобщето понятно (пример можно в студию? :))...
этоже не #define`какойнить`страшный# p.p.s.: только пожааааааааалуйста -- НЕ надо примеры на подобие:
import org.blahblablah.db.Date as ArrayList; // ну ведь по случайной ошибке такое написать не получится xD
> Sun-овцы решили закрыть еще одну возможность гов... криво писать.<sarcasm>
UtilDate dateA = new UtilDate(); // говнокод!
// ...
Date dateB = new Date(); // отличный код!
// ...
java.util.Date dateC = new java.util.Date(); // тоже отличный код!</sarcasm>
проснитесь! АУ!!
Перед вами все разложили.А так +1
ну и я разложил :) ведь
> java.util.Date dateC = new java.util.Date(); // тоже отличный код!...а главное солидный!
# fixed :-)
Meine lieber gott...
Ну, если уж так свербит, кто мешает сделать вот так:public class UtilDate extends java.util.Date {
}UtilDate dateB = new UtilDate();
слава иегове! отличный костль!не всё потеряно значит в этом языке xD
спасибо, буду пользовать xD
ой нет... кое где придётся в коде всётаки писать "java.util.Date" ... например если функция [некая, чужамодульная] возвращает объекты этого типа "java.util.Date" (а не принимает его в качестве аргумента)
вобщем не подходит.. нужны нормальные импортоалиасы
> ой нет... кое где придётся в коде всётаки писать "java.util.Date" ... например если функция [некая, чужамодульная] возвращает объекты этого типа "java.util.Date" (а не принимает его в качестве аргумента)Вы вообще хоть что-нибудь на жабе писали или так, просто мимо проходили?
есть метод java.util.Date doSomething(int i)
UtilDate dateB = new UtilDate();
...
dateB = (UtilDate)doSomething(10);Дальше что?
> есть метод java.util.Date doSomething(int i)который [предположим] возврашает НЕ объекты класса "UtilDate" а совершенно другие реализации-или-наследники класса "java.util.Date"
следовательно нижняя строчка выраст ошибку в Runtime --
> dateB = (UtilDate)doSomething(10);
# p.s.: яже выше (в других постах) писалже :-) что метод должен быть -- ЧУЖЕМОДУЛЬНЫЙ... и следовательно об "UtilDate" он вообще ничо не знает :-)
Если такая аллергия на написание полного пути - можно попробовать и через интерфейсы реализовать, только зачем?
Алиасы - совершенно излишняя сущность, без которой можно обойтись, и с помощью которой можно хорошо запутать код. Не боитесь призрака Оккама, который придет с серпом вместо бритвы?
> Когда в одном файле используются несколько классов с одинаковыми названиями, то это повод отрефакторить код и сменить имена похожих классов.здесь мы имеем дело с Коллизией Имён (проблема которая устранена у всех остальных языков (кроме Java), в которых есть пространства имён)
(тоесть в Java существуют пространства имён, но они не избавляют от коллизий xD.. <sarcasm>ГЕНИАЛЬНО!!!</sarcasm>)
а теперь давайте подумаем когда же возникают вероятности появления этих Коллизии Имён в Java (???)...
а очень просто..: вероятности возникают тогда, когда используются два сторонних модуля (авторы которых друг друга НЕ знают, и случайно назвали классы имён одинаково... но якобы страшного ничего нет ведь пространства имён-то разные... но страшного ничего нет -- лишь во всех языках кроме Java :))
но так как разработка программ -- это всегда от части эксперименты со смешиванием новых компонентов (модулей).. зачастую разработчикам модулей заранее сложно предсказать какой "коктель" из других модулей будет использован в будущем :-), так как вообще трудно заранее сказать какие в будущем будут новые виды программ
И НАФИГА ТОГДА вообще в Java нужны пространства имён, если они доконца не защщищают от коллизий имён классов? похоже на какуюто инженерную чушь xD
...в таком случае -- создатели Java могли-бы срать...(простите за выражение)...срать классами прямо в глобальное пространство имён xD !! [также, как это было в старом PHP, до версии PHP-5.3] а в моменты коллизий умникибы точно также говорилибы: "Когда используются несколько классов с одинаковыми названиями, то значит надо сменить имена классов"
но это же явная недоработка Java-Языка... а вы тут на форуме говорите что это якобы приемущество.. *LOL*
> Sun-овцы решили закрыть еще одну возможность гов... криво писать.
просто сглупили. недоглядели... то что это есть недоделка это очевидно... :-)
...вопрос лишь в том когда они собираются это исправлять
А ещё Java не меняет пелёнки, так что это инструмент не для всех, да :-)
> В число официально поддерживаемых сборщиков мусора включён G1 (Garbage First)Название неимоверно доставляет.
Прямо рекламный слоган Java - Garbage First.
> Задействованы специфичные для процессоров SPARC T4 оптимизации криптографических операцийа для интелей они AES и/или AVX не задействовали? *lol*
Не *lol* а маркетинг. Надо ж эту хрень (SPARC T4) как-то продавать.
>> Задействованы специфичные для процессоров SPARC T4 оптимизации криптографических операцийСкорее бонус в том, что криптография сервеной стороны на T4 работает намного-намного-намного быстрее, чем на других процах. И процов много и крипту считать оно может очень быстро.
Вопрос с криптографией вообще сложный и темный. К примеру в java криптография встраивается в платформу через плагинизацию. Как эти ВНЕШНИЕ для JRE плагины будут оптимизироваться - большой вопрос.
>Как эти ВНЕШНИЕ для JRE плагины будут оптимизироватьсяНаверно имеются ввиду оракловские крипто-плагины с нативными либами под Т4.
>>Как эти ВНЕШНИЕ для JRE плагины будут оптимизироваться
> Наверно имеются ввиду оракловские крипто-плагины с нативными либами под Т4.Думаю, что оптимизация идет на уровне самой JMV за счет использования более мощных конструкций CPU для решения крипто-задач.
Крипто-плагины в том числе и оракловые это java код. Потому любой java код на T4 использующий те же операции должен быть быстрее за счет оптимизаций уровня JMV.
"Более мощные конструкции CPU" доступны в JVM только через объявление метода нативным и реализацию оного в нативной библиотеке, оптимизированной под конкретный процессор.
Вся остальная оптимизация либо на уровне байткода, который ничего не знает про CPU, либо JIT-компилятор, который оптимизирует всё подряд, независимо от назначения.
> "Более мощные конструкции CPU" доступны в JVM только через объявление метода нативным
> и реализацию оного в нативной библиотеке, оптимизированной под конкретный процессор.
> Вся остальная оптимизация либо на уровне байткода, который ничего не знает про
> CPU, либо JIT-компилятор, который оптимизирует всё подряд, независимо от назначения.Под множеством методов лежит нативы. Думаю в крипто это еще больше. Так что использование базовых методов из своего java кода вероятно вызывает нативную криптографию где то в нутре JVM.
> корее бонус в том, что криптография сервеной стороны на T4 работает намного-намного-намного быстрее, чем на других процах. И процов много и крипту считать оно может очень быстро.я тестировал одно время, правда не на t4, а на t2, опять же на них количество крипто-функций ограниченное, то есть не всякую крипто-функцию можно отдать крипто процессору для работу. К тому же не забывайте, что у вас только 1 crypto unit на CPU core (8 кор в проце). В общем понятно, так как интелевое ядро гораздо быстрее спаркового, они это как бы доделали. Спрашивается что им мешало это раньше лет на 5 сделать, когда t2 вышли....
> а для интелейУже давно AES-NI используют.
млин опять бот нет будет на маках, как достает , то что Apple задерживает обновы патча их!!!
опять будут приходит пакеты в обновлениях по типу "remove mailware" : (((
перечитал еще раз новость -->>>представленных выпусках представлены только не связанные с безопасностью исправления
фуххх. както по спокойней стало
Жду, не дождусь , когда уже Oracle сам допилет Java Plugin и Java Web Start, JRE в сделующем или через релиз, чтобы свалить с шестерки сразу на семерку и самому контролировать обновы.
Я что один кто юзает openJDK и одному мне насрать на оракловскую жабу?
> Я что один кто юзает 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.ru/opennews/art.shtml?num=31332
Спасибо за разъяснение, но я так понял что ситуация с Java SE 7 и openJDK аналогична с MySQL и MariaDB, где имеем недосвободную ораколовскую реализацию, и открытый и более шустрый свободный форк.
Только в данном случае более шустрый вариант это Oracle JDK. И да, 90% разработчиков OpenJDK - работники Oracle.
вы неправильно поняли. Реально начиная с 7ки разница фактически только в том, что JDK от Oracle поставляется в собранном виде под все платформы, а OpenJDK в виде сорцов (и мэинтейнеры для дистрибутивов сами пакеты из сорцов собирают).
Разницы в коде фактически нет. (там что-то меньше 0,1% вроде бы было).