LINUX.ORG.RU

"Багфиксы, добавлены два новых L&F: GTK+ и WindowsXP" - читаю и херею, добавлены два новых багфикса, GTK+ и WindowsXP :)

anonymous
()

jvm быстрее на 376% ?!??!?

Должно быть тест на котором они получили 376% производительности был уж очень синтетический. ;-).

Сейчас качаю, если окажусь неправ возьму свои слова назад с удовольствием.

alt-x ★★★★★
()

Работает на самом деле быстрее, правда на GUI-приложениях не очень заметно. Зато теперь можно применять GTK для гуя, скорость на много выше, чем pureJava (правдв есть кое-какие недоработки...). Очень хорошо.

OFF: Если запускать все приложения Java под одной VM, то памяти жрет не много, работает быстро, и писать просто. :)

anonymous
()

> Должно быть тест на котором они получили 376% производительности был уж очень синтетический. ;-).

Ты о чем это? Если об этом "...In certain situations, performance is 300 times faster than previous releases.", то это относится исключительно к JFileChooser.

Там же все написано, по-английски ;-)

anonymous
()

>все приложения Java под одной VM

Кремлевский мечтатель! :)))

anonymous
()

Все таки Java развивается. А Microsoft как всегда передрал все мыслимые и немыслимые технологии, что такое C# это J++, а все остальное дополнительные усилия по выкачиванию денег из руководителей проектов.

Вадим

anonymous
()

>C# это J++

Юморист-пионЭр, в J++ встроенные в язык делегаты есть?

anonymous
()

>Юморист-пионЭр, в J++ встроенные в язык делегаты есть?
>anonymous (*) (2003-06-27 17:03:36.346917)

А это считается шибко круто?

del
()

> Юморист-пионЭр, в J++ встроенные в язык делегаты есть?

долбоёб пустозвон, софт написанный на C# уже и в мобилы встраивают, уже на нём и под QNX real-time писать можно ?

anonymous
()

jvm быстрее на 376% ?!??!?

Нет, я имел ввиду system dictionary reads. На практике, я не могу придумать ситуацию, чтобы его ускорение заметно сказывалось на работе приложения.

JFileChooser действительно стал быстрее. Больше я никаких заметных ускорений на заметил ни на серверной (jboss3.0.4), ни на клиентской (swing) стороне.

Ах да, стартует действительно быстрее. У меня на каждые 100 запусков будет экономиться 1 секунда времени.

Да ладно, кто же будет от java приложения скорости ждать? ;) Надеюсь, что пофиксили хотябы баги 1.4.1_02 из-за которых под линухом и солярисом(!) наше приложение вешало jvm и приходилось сидеть на 1.4.0_03... Пойду тесты запускать.

alt-x ★★★★★
()

> Да ладно, кто же будет от java приложения скорости ждать? ;)

Ну повысить скорость всегда можно, если действительно все-все запускать из под одной JVM.

А еще на маках сделали разделяемую runtime-library. Типа все стандартные классы компилятся чуть ли не один раз для разных запусков VM. Пишут, что так работает лучше.

Я думаю, что есть и другие способы ускорить JVM, и о них прекрасно знают в сане. Просто похоже они шибко озобачены такими словами как security, reliability и т.п.

Если говорить о том же C#, единственное что есть там такое и нет в яве, так это - структуры, которые обычно создаются в стеке. А вот делегаты (как и nested classes) - все лишь другая точка зрения на inner classes :-)

Еще подозреваю, что в .NET действительно все может крутиться на одной VM... даже очень может быть...

Давид

anonymous
()

А может кто запосить шот приложения на яве с GtkLook&Feel? Желательно и с нестандартной темой тоже..

anonymous
()

А не подскажут благородные доны как заставить явовые приложения использовать гткашные темы или для этого необходима поддержка в самой ява программе? А то автоматом че-то не подхватывается темка-то... :(

anonymous
()

Кстати, WindowsXP plaf есть только под WinXP. Мне, вообще-то, его наличие до лампочки.

pitekantrop

anonymous
()

2anonymous (*) (2003-06-27 22:37:55.353947)

Когда люди сначала читать будут, а потом спашивать? Там же все написано!

UIManager.setLookAndFeel("com.sun.java.swing.plaf.gtk.GTKLookAndFeel")

anonymous
()

Читать то я читал, но проблема в другом - это же еще и понять нужно!

anonymous
()
Ответ на: комментарий от anonymous

> Я думаю, что есть и другие способы ускорить JVM, и о них прекрасно > знают в сане. Просто похоже они шибко озобачены такими словами как > security, reliability и т.п. 

  Да уж конечно... у них банально не хватает сил, вот и все.
  В обнародованных (на этом сайте, кстати, это тоже обсуждалось)
  внутренних письмах команды разработчиков видно, что им приходится
  жертвовать Java/Solaris ради Java/Linux, потому что Linux сейчас
  важнее -- JBoss'ы, Tomcat'ы и прочее чаще всего именно под
  Linux крутятся.

> делегаты (как и nested classes) - все лишь другая точка зрения на > inner classes :-) 

  Глупость. И по факту это не так, и по эффективности, и по
  удобству пользования. В C# есть многое, чего нет в Java.
  Java обещают подтянуть к осени (enums, generics, 
  boxing-unboxing, ...). Посмотрим... 

anonymous
()

сравнeние C# и java - языковых фич - несерьёзно. Конечно если стоит вопрос - во что вкладывать - можно учить любой язык (в зависимости от традиции коллектива)

Для реального проекта вопрос выбора языка - второстепенен, и с другой стороны - одна маленькая деталь может быть критической и эта деталь уж никак не будет связана с удобством программера - это будет скорее: поддержка конкретной платформы + performance + наличие сырца, цена коммерческого софта итд. А в случае java и С# - это не синтаксис/фичи языков, а работоспособность/переносимость/скорость платформ: платформы java и платформы .NET

Прописать enums, bоxing - гораздо быстрей самому (часто быстрее чем смотрерь/искать в API); об оверхеде не говорю. generic и всякие так вкусности - это nice-to-have но даже если и есть - часто просто не используются (теми кто сточит свои испытанные годами безбаговые блоки работающего кода). Конечно, если фича очень большая (С++ vs C) - это для крупных проектов очень важно. Но не в случае перечисленных фич.

Anode
()

Чтобы по умлочанию включить GTKLookAndFeel, надо java при запуске указать опцию "-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel".
Если программа не вызывает метод UIManager.setLookAndFeel(UIManager.getSystemLookAndFeel()), то всё должно зарулить.

anonymous
()

> Глупость. И по факту это не так, и по эффективности, и по удобству пользования. В C# есть многое, чего нет в Java. Java обещают подтянуть к осени (enums, generics, boxing-unboxing, ...). Посмотрим...

шаблоны и метаданныые - действительно новая вещь, а вот остальные фичи, такие как enums, boxing-unboxing и поддержка аналога foreach погоды не делают. их аналоги с таким же упехом могут быть запрограммированы уже существующими средствами, другое дело, что новые фичи несколько автоматизирует этот процесс, а значит и снижают риск внесения программистом ошибки.

возвращаяся к делегатам и внутренним классам; несмотря на очень разные внешние формы, основной вариант их использования один - это организация обратного вызова; все остальное - от лукавого :-)

давид

anonymous
()
Ответ на: комментарий от anonymous

> шаблоны и метаданныые - действительно новая вещь, а вот остальные > фичи, такие как enums, boxing-unboxing и поддержка аналога foreach > погоды не делают. их аналоги с таким же упехом могут быть 

  Согласен со всем (кроме enum), но изначально-то некие
  субъекты утверждали, что C# ничем Java не превосходит.
  Однако же, факты говорят об обратном. К счастью, это не
  надолго (я надеюсь).

> возвращаяся к делегатам и внутренним классам; 
> несмотря на очень разные внешние формы, основной 
> вариант их использования один - это организация 
> обратного вызова; все остальное - от лукавого :-) 

  Использования -- да. Но эффективность несравнима.
  Помнится, раздрай между Java и MS начался как раз
  с того, что Sun отказалась включить delegates в 
  Java, а опыт MS показывал, что они сильно повышают
  "отзывчивость" GUI...

anonymous
()

> Но эффективность несравнима. Помнится, раздрай между 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). Ничего другого не вижу, но боюсь эта тема уже становится оффтопиком.

Давид

anonymous
()
Ответ на: комментарий от yuriy123

Java Runtime для Windows весит 14Мб, для Linux - 13Mb.

anonymous
()

По поводу скорости данного релиза. Ведь нормальным english написанно, что выигрыш в основном на многопроцессорных машинах. На одном CPU выигрыш незначительный и только местами.

Korwin ★★★
()

<quote>
New Performance and Scalability Features

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>

anonymous
()

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. Но враг не дремлет!

anonymous
()

Cамое главное что есть поддержка NPTL - так что теперь должна стабильно работать на RedHat 9 - И следующая версия Оракла выйдет надеюсь с этой версией Жавы.

anonymous
()

Гы-гы-гы! Язык brainfuck - вообще лучший язык! И по фичности уделывает всех!

anonymous
()

> При запуске Кошака сделайте "ps -ax". Мечты об "одной JVM" развеяьтся сразу.

спасибо за интересные примеры

а под словом "Кошак" ты имеешь ввиду tomcat? если да, то там скорее всего просто многопоточность, а вот WebSphere действительно позволяет деплоить (deploy) приложения в разных JVM... хотя теоретически - это не совсем правильно, но зато оправдывает себя на практике

наверное для Web сревера досточно и одной JVM с множеством потоков, а вот application-сервер с RMI переходами между EJB - совсем другое дело

а вообще, я тоже приверженец явы c 1997; просто уже третий месяц у меня проект на C#, и я несколько соскучился по старой доброй яве... нахожу много общего, в том числе и в библиотеках, но как-то все - не то

давид

anonymous
()

В 1.4 JVM уже стала Unicode программой или до сих пор работает с операционной системой как ASCII? Например - в Win в именах файлов можно использовать бувы любых языков, класс File в Java их даже видит, а зуб неймет - прочитать не может :(

anonymous
()

>>>3) При запуске Кошака сделайте "ps -ax". Мечты об "одной JVM" развеяьтся сразу.

Не ты первый не ты последний, кто не сделал RTFM увидев нечто странное ;) Каждый тред, который запущен в линуховой jvm, ps покажет как отдельный процесс, но никаких нескольких jvm при этом не будет...

Сообразить что это лишь кажущиеся клоны одного процесса можно, обратив внимание на одинаковый размер памяти, занимаемой каждым процессом. А ещё, если тредов много - то легко может получиться будто jvm использует памяти в разы больше чем физический размер RAM + swap, при этом в свопе пусто :))) Последствия тридинга "один в один" - все многотридные программы так отображаются ps'ами разными...

speer
()

> ...хотя теоретически - это не совсем правильно

чуть не забыл; конечно, речь идет об однопроцесорной системе ala Windows на персоналке

давид

anonymous
()

>все многотридные программы так отображаются

Пять баллов. Только почитай еще книгу Митчелла, он там подробно рассказывает, что такое "трэд" под Linux и чем он отличается от Windows треда. Тогда и поймеш, почему ps показывает "процессы". Так что учись дальше, шибко грамотный.

anonymous
()

>наверное для Web сревера досточно и одной JVM с множеством потоков, а вот application-сервер с RMI переходами между EJB - совсем другое дело

Абсолютно верно. J2EE sux изначально. Про "тяжелые" по сравнению с Windows нити в Linux согласен с предыдущим онанизмусом. Юношеский линукс-фанатизм - это одно, а реальная жизнь - это другое.

anonymous
()
Ответ на: комментарий от speer

Спыыр, красноглазик ты наш, сходи не www.volano.com. Поглазей на бенчмарки под Windows и Linux. Зацени.

anonymous
()

2 anonymous:

1. Надо подписыватся

2. Надо следить за темой

3. Надо делать внятные заявления, а потом их аргументировать, особенно когда они не по теме

В противном случае кваканье из сточной канавы привлечёт внимание только твоих сородичей.

speer
()
Ответ на: комментарий от anonymous

"Так что учись дальше, шибко грамотный"

Ну надоже, такое ламерьё ещё и учить пытается. Урод ты интеллектуальный, почитай сам митчелла, а лучше kernel source. Вобщем так мразь, запусти многотредовый app и прибей root process, если ты прав то должны куча процессов болтаться остаться, иначе сдохни падла и не пизди тупица

anonymous
()

Я зарегистрировался.

Так зачам были нужны green threads?

anonymous666
()

>прибей root process, если ты прав то должны куча процессов болтаться остаться,

В чем прав тот анонимус? Что он утверждал что остальные процессы не прибьются и где конкретно он это утверждал? Ссылочку в студию.

anonymous
()

Деградировавшему уёбку ляпнувшему хуйню типа "Ну ты и 3.14здобол красноглазый!"

Ты урод сначала нам продукт на этом дерьме покажи. Что нету продукта ? Продолжай сосать мразь.

VLS

//пароль забыл

anonymous
()

VLS? Есть великий и могучий VSL, а ты клон-клоун.

anonymous
()

Извините, а что за книгa Митчелла такая?

anonymous
()

Да speer, мало того, что косит под Луговского, еще и читать не умеет:

http://www.microsoft.com/presspass/press/2003/jun03/06-17ToshibaTECPR.asp

Кстати, что там Митчелл писал про нити в Линукс? Неужели анонимус так глуп, что пропустит слова автора о том, то что эти ну просто очень шустрые треды НЕ создаются при помощи fork? Зачем это такое приписывать анонимусу? Или потом бороться будет удобнее? Или в книжке про затратность ресурсов на создание треда в Linux в отличие от Windows сказано, так что преимуществ по скорости по сравнению с обычными процессами в любительской системе никаких нет? Цитату, если можно.

anonymous
()

speer понахватался на LORe от умных людей фраз:

"Потоковые функции, соответствующие стандарту POSIX, реализованы в Linux не так, как в большинстве других версий UNIX..."

http://www.ozon.ru/?context=detail&id=986013

Вот ему и кажется что все нефанатствующие считают потоки в линуксе процессами. Хотя лично так я не считаю, что официально заявляю. Тред в линуксе обладает внешне всеми свойствами виндусового треда, однако создается через одно место.

Это на самом деле страница 92. Глава 4.5.

anonymous666
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.