Работает на самом деле быстрее, правда на GUI-приложениях не очень заметно. Зато теперь можно применять GTK для гуя, скорость на много выше, чем pureJava (правдв есть кое-какие недоработки...). Очень хорошо.
OFF: Если запускать все приложения Java под одной VM, то памяти жрет не много, работает быстро, и писать просто. :)
> Должно быть тест на котором они получили 376% производительности был уж очень синтетический. ;-).
Ты о чем это? Если об этом "...In certain situations, performance is 300 times faster than previous releases.", то это относится исключительно к JFileChooser.
Все таки Java развивается. А Microsoft как всегда передрал все мыслимые и немыслимые технологии, что такое C# это J++, а все остальное дополнительные усилия по выкачиванию денег из руководителей проектов.
Нет, я имел ввиду system dictionary reads. На практике, я не могу придумать ситуацию, чтобы его ускорение заметно сказывалось на работе приложения.
JFileChooser действительно стал быстрее. Больше я никаких заметных ускорений на заметил ни на серверной (jboss3.0.4), ни на клиентской (swing) стороне.
Ах да, стартует действительно быстрее. У меня на каждые 100 запусков будет экономиться 1 секунда времени.
Да ладно, кто же будет от java приложения скорости ждать? ;) Надеюсь, что пофиксили хотябы баги 1.4.1_02 из-за которых под линухом и солярисом(!) наше приложение вешало jvm и приходилось сидеть на 1.4.0_03... Пойду тесты запускать.
> Да ладно, кто же будет от java приложения скорости ждать? ;)
Ну повысить скорость всегда можно, если действительно все-все запускать из под одной JVM.
А еще на маках сделали разделяемую runtime-library. Типа все стандартные классы компилятся чуть ли не один раз для разных запусков VM. Пишут, что так работает лучше.
Я думаю, что есть и другие способы ускорить JVM, и о них прекрасно знают в сане. Просто похоже они шибко озобачены такими словами как security, reliability и т.п.
Если говорить о том же C#, единственное что есть там такое и нет в яве, так это - структуры, которые обычно создаются в стеке. А вот делегаты (как и nested classes) - все лишь другая точка зрения на inner classes :-)
Еще подозреваю, что в .NET действительно все может крутиться на одной VM... даже очень может быть...
А не подскажут благородные доны как заставить явовые приложения использовать гткашные темы или для этого необходима поддержка в самой ява программе? А то автоматом че-то не подхватывается темка-то... :(
> Я думаю, что есть и другие способы ускорить JVM, и о них прекрасно > знают в сане. Просто похоже они шибко озобачены такими словами как > security, reliability и т.п.
Да уж конечно... у них банально не хватает сил, вот и все.
В обнародованных (на этом сайте, кстати, это тоже обсуждалось)
внутренних письмах команды разработчиков видно, что им приходится
жертвовать Java/Solaris ради Java/Linux, потому что Linux сейчас
важнее -- JBoss'ы, Tomcat'ы и прочее чаще всего именно под
Linux крутятся.
> делегаты (как и nested classes) - все лишь другая точка зрения на > inner classes :-)
Глупость. И по факту это не так, и по эффективности, и по
удобству пользования. В C# есть многое, чего нет в Java.
Java обещают подтянуть к осени (enums, generics,
boxing-unboxing, ...). Посмотрим...
сравнeние C# и java - языковых фич - несерьёзно. Конечно если стоит вопрос - во что вкладывать - можно учить любой язык (в зависимости от традиции коллектива)
Для реального проекта вопрос выбора языка - второстепенен, и с другой стороны - одна маленькая деталь может быть критической и эта деталь уж никак не будет связана с удобством программера - это будет скорее: поддержка конкретной платформы + performance + наличие сырца, цена коммерческого софта итд. А в случае java и С# - это не синтаксис/фичи языков, а работоспособность/переносимость/скорость платформ: платформы java и платформы .NET
Прописать enums, bоxing - гораздо быстрей самому (часто быстрее чем смотрерь/искать в API); об оверхеде не говорю. generic и всякие так вкусности - это nice-to-have но даже если и есть - часто просто не используются (теми кто сточит свои испытанные годами безбаговые блоки работающего кода). Конечно, если фича очень большая (С++ vs C) - это для крупных проектов очень важно. Но не в случае перечисленных фич.
Чтобы по умлочанию включить GTKLookAndFeel, надо java при запуске указать опцию "-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
Если программа не вызывает метод UIManager.setLookAndFeel(UIManager.getSystemLookAndFeel()), то всё должно зарулить.
> Глупость. И по факту это не так, и по эффективности, и по удобству пользования. В C# есть многое, чего нет в Java. Java обещают подтянуть к осени (enums, generics, boxing-unboxing, ...). Посмотрим...
шаблоны и метаданныые - действительно новая вещь, а вот остальные фичи, такие как enums, boxing-unboxing и поддержка аналога foreach погоды не делают. их аналоги с таким же упехом могут быть запрограммированы уже существующими средствами, другое дело, что новые фичи несколько автоматизирует этот процесс, а значит и снижают риск внесения программистом ошибки.
возвращаяся к делегатам и внутренним классам; несмотря на очень разные внешние формы, основной вариант их использования один - это организация обратного вызова; все остальное - от лукавого :-)
> шаблоны и метаданныые - действительно новая вещь, а вот остальные > фичи, такие как enums, boxing-unboxing и поддержка аналога foreach > погоды не делают. их аналоги с таким же упехом могут быть
Согласен со всем (кроме enum), но изначально-то некие
субъекты утверждали, что C# ничем Java не превосходит.
Однако же, факты говорят об обратном. К счастью, это не
надолго (я надеюсь).
> возвращаяся к делегатам и внутренним классам;
> несмотря на очень разные внешние формы, основной
> вариант их использования один - это организация
> обратного вызова; все остальное - от лукавого :-)
Использования -- да. Но эффективность несравнима.
Помнится, раздрай между Java и MS начался как раз
с того, что Sun отказалась включить delegates в
Java, а опыт MS показывал, что они сильно повышают
"отзывчивость" GUI...
> Но эффективность несравнима. Помнится, раздрай между Java и MS начался как раз с того, что Sun отказалась включить delegates в Java, а опыт MS показывал, что они сильно повышают "отзывчивость" GUI.
Помнится это было в году так 1997-1998... и я лично рад, что Сан отстоял свою провоту, уж больно корявые эти делегаты...
А что ты понимаешь под "отзывчивостью"? Вообще, нет никаких причин тому, чтобы делегаты работали быстрее, чем стандартная модель object-event-listener.
Единственное, что нужно добавить, так это то, что в стандартных явовских библиотеках, как правило, принято на каждое событие создавать новый объект event. В дот-нете этого можно избежать, передавая два параметра (первый обычно - this, а второй часто EventArgs.Empty):
public delegate void XXXEventHandler (object, XXXEventArgs);
Вот здесь и может быть потеря в скорости в случае явы из-за лишнего создания объектов. Но это скорее проблема проектирования библиотек, а не самого языка.
И последнее, так в чем же C# реально превосходит яву? Я назвал только наличие структур (сановцы называют их иногда lightweight objects). Ничего другого не вижу, но боюсь эта тема уже становится оффтопиком.
По поводу скорости данного релиза. Ведь нормальным english написанно, что выигрыш в основном на многопроцессорных машинах. На одном CPU выигрыш незначительный и только местами.
Several key new features that improve scalability have been added to the J2SE platform in version 1.4.2. These include the new throughput and concurrent low-pause garbage collectors, Linux NPTL thread library support, and SSE/SSE2 register support for floating point operations.
</quote>
2Давид:
1) Примерчик из MSDN c делегатами:
delegate void MyDelegate(int i);
class Program
{
public static void Main()
{
TakesADelegate(new MyDelegate(DelegateFunction));
}
public static void TakesADelegate(MyDelegate SomeFunction)
{
SomeFunction(21);
}
public static void DelegateFunction(int i)
{
System.Console.WriteLine("Called by delegate with number: {0}.", i);
}
}
Не дураки сидят у мелких - "GoF" читают.
2) Код вида:
class EnumTest {
enum MyEnum { a, b };
public static void main(String[] args) {
for (MyEnum myEnum : MyEnum.VALUES) {
switch(myEnum) {
case MyEnum.a:
System.out.println("a");
break;
case MyEnum.b:
System.out.println("b");
break;
}
}
}
}
просто удобная форма записи для:
import java.util.*;
class EnumTest
{
static class MyEnum extends Enum
{
public final List family()
{
return VALUES;
}
public static List valueOf(String s)
{
return Enum.valueOf(VALUES, s);
}
public int compareTo(Enum enum)
{
return super.compareTo((MyEnum)enum);
}
public int compareTo(Object obj)
{
return super.compareTo((MyEnum)obj);
}
public static final List VALUES;
public static final MyEnum a;
public static final MyEnum b;
static
{
a = new MyEnum("a", 0);
b = new MyEnum("b", 1);
VALUES = Collections.unmodifiableList(Arrays.asList(new MyEnum[] {
a, b
}));
}
MyEnum(String s, int i)
{
super(s, i);
}
}
public static void main(String args[])
{
SimpleIterator simpleiterator = MyEnum.VALUES.iterator();
do
{
if(!simpleiterator.hasNext())
break;
MyEnum myenum = (MyEnum)simpleiterator.next();
MyEnum myenum1 = myenum;
if(myenum1 != MyEnum.a)
{
if(myenum1 == MyEnum.b)
System.out.println("b");
} else
{
System.out.println("a");
}
} while(true);
}
}
и
import java.util.*;
static class EnumTest$MyEnum extends Enum
{
public final List family()
{
return VALUES;
}
public static List valueOf(String s)
{
return Enum.valueOf(VALUES, s);
}
public int compareTo(Enum enum)
{
return super.compareTo((EnumTest$MyEnum)enum);
}
public int compareTo(Object obj)
{
return super.compareTo((EnumTest$MyEnum)obj);
}
public static final List VALUES;
public static final EnumTest$MyEnum a;
public static final EnumTest$MyEnum b;
static
{
a = new EnumTest$MyEnum("a", 0);
b = new EnumTest$MyEnum("b", 1);
VALUES = Collections.unmodifiableList(Arrays.asList(new EnumTest$MyEnum[] {
a, b
}));
}
EnumTest$MyEnum(String s, int i)
{
super(s, i);
}
}
3) При запуске Кошака сделайте "ps -ax". Мечты об "одной JVM" развеяьтся сразу.
PS. Впрочем, пока мой выбор - Java. Но враг не дремлет!
Cамое главное что есть поддержка NPTL - так что теперь должна стабильно работать на RedHat 9 - И следующая версия Оракла выйдет надеюсь с этой версией Жавы.
> При запуске Кошака сделайте "ps -ax". Мечты об "одной JVM" развеяьтся сразу.
спасибо за интересные примеры
а под словом "Кошак" ты имеешь ввиду tomcat? если да, то там скорее всего просто многопоточность, а вот WebSphere действительно позволяет деплоить (deploy) приложения в разных JVM... хотя теоретически - это не совсем правильно, но зато оправдывает себя на практике
наверное для Web сревера досточно и одной JVM с множеством потоков, а вот application-сервер с RMI переходами между EJB - совсем другое дело
а вообще, я тоже приверженец явы c 1997; просто уже третий месяц у меня проект на C#, и я несколько соскучился по старой доброй яве... нахожу много общего, в том числе и в библиотеках, но как-то все - не то
В 1.4 JVM уже стала Unicode программой или до сих пор работает с операционной системой как ASCII? Например - в Win в именах файлов можно использовать бувы любых языков, класс File в Java их даже видит, а зуб неймет - прочитать не может :(
>>>3) При запуске Кошака сделайте "ps -ax". Мечты об "одной JVM" развеяьтся сразу.
Не ты первый не ты последний, кто не сделал RTFM увидев нечто странное ;) Каждый тред, который запущен в линуховой jvm, ps покажет как отдельный процесс, но никаких нескольких jvm при этом не будет...
Сообразить что это лишь кажущиеся клоны одного процесса можно, обратив внимание на одинаковый размер памяти, занимаемой каждым процессом. А ещё, если тредов много - то легко может получиться будто jvm использует памяти в разы больше чем физический размер RAM + swap, при этом в свопе пусто :))) Последствия тридинга "один в один" - все многотридные программы так отображаются ps'ами разными...
Пять баллов. Только почитай еще книгу Митчелла, он там подробно рассказывает, что такое "трэд" под Linux и чем он отличается от Windows треда. Тогда и поймеш, почему ps показывает "процессы". Так что учись дальше, шибко грамотный.
>наверное для Web сревера досточно и одной JVM с множеством потоков, а вот application-сервер с RMI переходами между EJB - совсем другое дело
Абсолютно верно. J2EE sux изначально. Про "тяжелые" по сравнению с Windows нити в Linux согласен с предыдущим онанизмусом. Юношеский линукс-фанатизм - это одно, а реальная жизнь - это другое.
Ну надоже, такое ламерьё ещё и учить пытается. Урод ты интеллектуальный, почитай сам митчелла, а лучше kernel source. Вобщем так мразь, запусти многотредовый app и прибей root process, если ты прав то должны куча процессов болтаться остаться, иначе сдохни падла и не пизди тупица
Кстати, что там Митчелл писал про нити в Линукс? Неужели анонимус так глуп, что пропустит слова автора о том, то что эти ну просто очень шустрые треды НЕ создаются при помощи fork? Зачем это такое приписывать анонимусу? Или потом бороться будет удобнее? Или в книжке про затратность ресурсов на создание треда в Linux в отличие от Windows сказано, так что преимуществ по скорости по сравнению с обычными процессами в любительской системе никаких нет? Цитату, если можно.
Вот ему и кажется что все нефанатствующие считают потоки в линуксе процессами. Хотя лично так я не считаю, что официально заявляю. Тред в линуксе обладает внешне всеми свойствами виндусового треда, однако создается через одно место.