Крадущийся тигр (Что нас ждет в Java 1.5)
От: Ноздреватых Ростислав aka Blazkowicz Россия  
Дата: 09.06.04 03:18
Оценка: 755 (18) -1
Статья:
Крадущийся тигр (Что нас ждет в Java 1.5)
Автор(ы): Ноздреватых Ростислав aka Blazkowicz
Дата: 27.07.2002
Выход проекта под кодовым именем Tiger на сегодняшний день – одно из самых ожидаемых событий в мире Java 2. Новая версия, 1.5, – это не просто ещё одна единичка в номере версии, это ряд революционных новшеств, которых, наверное, не было со времен появления Java 2. В этой статье будут рассмотрены основные из них.


Авторы:
Ноздреватых Ростислав aka Blazkowicz

Аннотация:
Выход проекта под кодовым именем Tiger на сегодняшний день – одно из самых ожидаемых событий в мире Java 2. Новая версия, 1.5, – это не просто ещё одна единичка в номере версии, это ряд революционных новшеств, которых, наверное, не было со времен появления Java 2. В этой статье будут рассмотрены основные из них.
Re[3]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: TK Лес кывт.рф
Дата: 10.06.04 07:28
Оценка: 12 (3)
Hello, "Blazkowicz"
>
> Или вот часто пример приводят с удаленными вызовами. Раньше как было. Есть класс. Нужно пометить какие методы могут вызываться удаленно. Для этого создавался интерфейс с такими же методами. В 1.5 просто в классе можно пометить эти методы. Хотя мне этот пример до конца не понятен. Все равно ведь на клиенте лучше иметь интерфейс а не такой же класс как на сервере.
>

Думаю, имеется в виду то, что для сгенерировать нужный интерфейс для клиента можно будет автоматически, на основании тех-же метаданных. В итоге — уменьшается количество сущностей в коде...
Posted via RSDN NNTP Server 1.9 alpha
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: ilya_ny  
Дата: 11.06.04 03:56
Оценка: -3
в SUN решили выпустить C#-killer путем копирования основных возможностей.
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 10.06.04 06:50
Оценка: 8 (2)
Здравствуйте, DemAS, Вы писали:

DAS> 1. Автобоксинг


DAS>
DAS>        Кроме этого, числовые операции теперь можно производить, не доставая из обертки значение:        
        
DAS>        Integer b = 10;
DAS>        b++;
DAS>

DAS> А разве раньше так нельзя было ?

Раньше — нельзя. int — базовый тип. Для работы с целочисленными значениями. Integer — класс-обертка над этим базовым типом. В Тигре попытались стереть разницу между ними. Производить операции непосредственно над обертками раньше нельзя было.

DAS> 2. Метаданные


DAS> Честно говоря так и не понял, в чем здесь смысл

DAS> Информацию о методах класса, его парамертрах и типе возвращаемого значения можно было и раньше получить через reflection.
DAS> Что нового дают метаданные ?

Метаданные позволяют добавлять свою собственную информацию. Например хочется написать XML сериализатор. И вместо того чтобы писать дополнительный маппиг. Можно разметить поля класса, какие хочется сериализовать в аттрибуты, какие в элементы и пр.

Или вот часто пример приводят с удаленными вызовами. Раньше как было. Есть класс. Нужно пометить какие методы могут вызываться удаленно. Для этого создавался интерфейс с такими же методами. В 1.5 просто в классе можно пометить эти методы. Хотя мне этот пример до конца не понятен. Все равно ведь на клиенте лучше иметь интерфейс а не такой же класс как на сервере.

Ещё один пример Deprecated это ведь тоже метаданные. Раньше они из java-doc записывались в класс. Можно так же посмотреть стандартные аннотации в JDK. Так на вскидку не вспомню их.
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 13.10.04 21:43
Оценка: +2
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

Выскажу своё эмоциональное мнение и философский взгляд на вещи.

Мне, например, резко не нравятся темплейты и генерики, по причине ещё одного "измерения" в семантическом пространстве выражения мыслей на языке (простите за слишком вумную фразу).

Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.

Не множьте сущности без необходимости! (Как сказал один мудрец)
Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!
Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?
Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

Да, размер исходного кода уменьшился значительно, но что взамен?
1. ВЫРОСЛА СЛОЖНОСТЬ КОМПИЛЯТОРА (он защищён от ошибок? для C++ компилятор писали годами...но не избавились от неоднозначностей до сих пор);
2. ВЫРОС ПОРОГ ПОНИМАНИЯ КОДА ЧЕЛОВЕКОМ (теперь необходимо знать (о ужас!) шаблоны и дженерики, от которых отказались вначале для простоты);
3. ВЫРОСЛО ЧИСЛО ДУБЛИРУЮЩИХ СУЩНОСТЕЙ, отравляющих жизнь вопросами выбора, — налицо потребительский подход к решению задач.

В общем, после версии 1.1.8 Java стала сложнее, а с выходом версии 1.5 язык потерял, наконец-то, всю прелесть простоты. От чего хотели уйти, к тому же и пришли — круг замкнулся.
Re[8]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 12.10.04 13:00
Оценка: 5 (1)
Здравствуйте, Batiskaf, Вы писали:

B>>>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


D>>Нет. Не разрешено.


B>Ясно... Да, крадущийся тигр, точно подмечено, только хочется бегущего тигра.


B>Ну а метаданные к примеру, можно ли например соорудить на этой фишке что то типа аспектов, что бы управление передавалось в метод анотации, типа если анотация присвоена члену класса то вызвать сначала метод анотации, которая с параметром чего то проделает а потом передать члену класса, тоже самое можно и в отношении методов класса делать, собственно тоже самое, что можно уже сегодня делать темплейтами на плюсах.


Снова нет. Для аспектов существует AspectJ.

Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

Кстати, существовало довольно много реализаций генериков на Java. Наиболее известные: PolyJ, NextGen, GJ. Tiger происходит главным образом от GJ.

Вот, может быть, будет интересна эта ссылка:
Java Generics: Final Report
--
Дмитро
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 17.06.04 08:00
Оценка: 1 (1)
Здравствуйте, dshe, Вы писали:

D>Интересно, как были переведены термины

D>generics (в отношении не только классов, но и методов)
D>type parameter
D>generic method
D>wildcard

Да в общем не мудрствовал сильно. Шаблоны классов, методов. wildcard можно перевести как маска.
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 14.10.04 08:33
Оценка: 1 (1)
Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:


ZEN>Выскажу своё эмоциональное мнение и философский взгляд на вещи.


ZEN>Мне, например, резко не нравятся темплейты и генерики, по причине ещё одного "измерения" в семантическом пространстве выражения мыслей на языке (простите за слишком вумную фразу).


ZEN>Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.


Ну так это же основная фишка в event handling в джава апликациях, потому как замыкания в джаве не придумали, и множественного наследования тоже нет, вам ли этого не знать!!?? Почему нельзя создать инстанс иннер класса вне класса внешнего, или даже в статическом методе внешнего класса, вы хоть задумывались??? Потому что при создании экземпляра в него в неявной форме передается ссылка на текущий экземпляр внешнего класса, эту ссылку руками передавать не нужно, фишка встроена в язык, тогда из метода иннер класса можно достукиваться к членам внешнего класса по такой конструкции:


public class Class1
{
    public Class1()
    {
    }
    private void F1()
    {
        System.out.println( "Class1::F1" );
    }

    public class Callback
    {
        public void F1()
        {
            System.out.println( "Class1::Callback::F1" );
            Class1.this.F1();//Специально для удобства программистов!!!
        }
    }

    Callback GetCallback()
    {
        return new Callback();
    }

    public static void main(String[] args)
    {
        Class1 obj = new Class1();
        Callback clb = obj.GetCallback();
        clb.F1();
    }
}


Таким образом калбэк класс может имплементировать методы какого то ивент адаптера ( внешний класс не может этого сделать, потому как нет множественного наследования, он наследует к примеру бизнес логику предметной области, остается только наследоваться от интерфейсов, что не всегда удобно и муторно ). Таким же макаром в общем случае можно имитировать множественное наследование.

ZEN>Не множьте сущности без необходимости! (Как сказал один мудрец)

Реальный мир гораздо сложнее того парника, который выдумывают себе люди.

ZEN>Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!

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



ZEN>Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?

ZEN>Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
ZEN>Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

Процитирую себя же: "Реальный мир гораздо сложнее того парника, который выдумывают себе люди".
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[6]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 29.10.04 06:48
Оценка: 1 (1)
Здравствуйте, dshe, Вы писали:

D>Ты можешь сказать на какой версии вы компилировали?


У меня есть подозрения, что вы компилировали eclipse'овым компилятором, который еще не совсем 1.5.
--
Дмитро
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 10.06.04 14:35
Оценка: +1
Здравствуйте, Oval, Вы писали:

O>А рефлексия-то у нее с 1.4 не совместима похоже ни бинарно ни синтаксически — щас еще 40 Мб выкачивать (


Что ты имел ввиду?

В чем заключается несовместимость рефлексии бинарно?
Рефликсия поменялась не значительно. Основные изменения связаны с генериками и метаданными. Код из 1.4 чудесно компилируется в 1.5. В чем не совместимость?
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 10.06.04 16:21
Оценка: +1
Здравствуйте, iZEN, Вы писали:

ZEN>Изврат.

ZEN>Кончилась эпоха чистого компилятора — введён препроцессор. (я не ошибаюсь?)
Да? Как-то не заметил. А откуда сведения?
Re[7]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 16.06.04 07:40
Оценка: +1
Здравствуйте, dshe, Вы писали:

D>Я, признаюсь, все равно не понял, что же тебе не понравилось в новом jdk.


Генерики которые ими не являются, так как не имеют никакого отношения к runtime (в отличие от того же шарпа). И автобоксинг, которые опять же лишь скрывает от программера то что происходит на самом деле. Вероятно повсеместное его использование может привести к понижению производительности системы. Тот же новый цикл...
Всё действительно наводит на мысли о прекомпиляции.

Enum-ы вот вроде более или менее реализованы.
Re[7]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: mselez  
Дата: 29.10.04 15:51
Оценка: :)
Здравствуйте, dshe, Вы писали:

Мы пока отложили эту затею применить яву 5 на сервере, там у нас и с сервлетами начались проблемы. Но на сервере мы сами хозяева. А вот если клиент — апплет, и пользователь поставит плагин 1.5, то будет весело. По крайней мере, наш апплет на 1.1.8, который до этого работал везде, сразу выдал кучу exceptions . Например, элемент java.awt.ScrollBar, который давал значения от 0 до мах , стал в верхнем положении давать -1 вместо 0. И соответственно получили ArrayOutOfBounds. А используем конструктор, в котором явно задаем мин и макс. Разберемся, конечно, исправим, и будет опять "написано однажды — работает везде".
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Denwer Россия  
Дата: 09.06.04 10:29
Оценка:
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

НРA>Статья:



НРA>Авторы:

НРA> Ноздреватых Ростислав aka Blazkowicz

НРA>Аннотация:

НРA>Выход проекта под кодовым именем Tiger на сегодняшний день – одно из самых ожидаемых событий в мире Java 2. Новая версия, 1.5, – это не просто ещё одна единичка в номере версии, это ряд революционных новшеств, которых, наверное, не было со времен появления Java 2. В этой статье будет рассмотрены основные из них.

Собственно здесь все это написано, но на английском правда.
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 09.06.04 12:55
Оценка:
B>... В этой статье будет рассмотрены основные из них.
...мда-а...
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: DemAS http://demas.me
Дата: 10.06.04 05:56
Оценка:
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

А можно несколько вопросов от человека поверхостно разбирающегося в Java, но старающегося следить, что там происходит ?

1. Автобоксинг

        Кроме этого, числовые операции теперь можно производить, не доставая из обертки значение:        
        
        Integer b = 10;
        b++;


А разве раньше так нельзя было ?

2. Метаданные

Честно говоря так и не понял, в чем здесь смысл
Информацию о методах класса, его парамертрах и типе возвращаемого значения можно было и раньше получить через reflection.
Что нового дают метаданные ?

Спасибо.
... << Rsdn@Home 1.1.4 beta 1 >>
Re[4]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 10.06.04 08:07
Оценка:
Здравствуйте, TK, Вы писали:

TK>Думаю, имеется в виду то, что для сгенерировать нужный интерфейс для клиента можно будет автоматически, на основании тех-же метаданных. В итоге — уменьшается количество сущностей в коде...


точно
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Oval  
Дата: 10.06.04 14:32
Оценка:
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

НРA>Статья:



НРA>Авторы:

НРA> Ноздреватых Ростислав aka Blazkowicz

НРA>Аннотация:

НРA>Выход проекта под кодовым именем Tiger на сегодняшний день – одно из самых ожидаемых событий в мире Java 2.

А рефлексия-то у нее с 1.4 не совместима похоже ни бинарно ни синтаксически — щас еще 40 Мб выкачивать (
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 10.06.04 15:52
Оценка:
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

НРA>Выход проекта под кодовым именем Tiger на сегодняшний день – одно из самых ожидаемых событий в мире Java 2. Новая версия, 1.5, – это не просто ещё одна единичка в номере версии, это ряд революционных новшеств, которых, наверное, не было со времен появления Java 2. В этой статье будут рассмотрены основные из них.


Изврат.
Кончилась эпоха чистого компилятора — введён препроцессор. (я не ошибаюсь?)
Re[3]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 13.06.04 10:33
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, iZEN, Вы писали:


ZEN>>Изврат.

ZEN>>Кончилась эпоха чистого компилятора — введён препроцессор. (я не ошибаюсь?)
B>Да? Как-то не заметил. А откуда сведения?

Декомпилировать полученный байт-код не пробовали?
Попробуйте, тогда посмотрим.
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 13.06.04 10:34
Оценка:
Здравствуйте, ilya_ny, Вы писали:

_>в SUN решили выпустить C#-killer путем копирования основных возможностей.

Не. Им суждено слиться в экстазе общей среды.
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Аноним  
Дата: 13.06.04 23:44
Оценка:
Здравствуйте, ilya_ny, Вы писали:

_>в SUN решили выпустить C#-killer путем копирования основных возможностей.


Изначально все было совсем наоборот
Да прибудет с Джавой сила!
Re[4]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 14.06.04 06:57
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, Blazkowicz, Вы писали:


B>>Здравствуйте, iZEN, Вы писали:


ZEN>>>Изврат.

ZEN>>>Кончилась эпоха чистого компилятора — введён препроцессор. (я не ошибаюсь?)
B>>Да? Как-то не заметил. А откуда сведения?

ZEN>Декомпилировать полученный байт-код не пробовали?

ZEN>Попробуйте, тогда посмотрим.

Интересно, какой именно байт-код наводит мысли о препроцессоре? И что именно в нем тебе не нравится?
--
Дмитро
Re[4]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 14.06.04 08:38
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>>>Изврат.

ZEN>>>Кончилась эпоха чистого компилятора — введён препроцессор. (я не ошибаюсь?)
B>>Да? Как-то не заметил. А откуда сведения?

ZEN>Декомпилировать полученный байт-код не пробовали?

ZEN>Попробуйте, тогда посмотрим.

Если ты имеешь ввиду, что в результате компиляции данные о типах теряются. И никакой оптимизации кода не происходит. То может ты и прав. Но это можно показать и без декомпиляции. Простым примером.

        List<String> list = new ArrayList<String>();
        Object o = list;
        List<Integer> l = (List<Integer>) o;
        l.add(new Integer(3));
        System.out.println(l.get(0));


Генерики в яве это что-то среднее между шаблонами в плюсах и генриками в шарпе. Вот 2 интересные ссылки по теме.

http://www.artima.com/intv/generics2.html
http://www.zefhemel.com/archives/2003/11/21/the-difference-between-c---templates-and-generics

Да, согласен. Плеваться есть на что. Интересно а в планах Sun есть перенесение генериков в рантайм на уровень байткода?
Re[5]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 15.06.04 17:34
Оценка:
Здравствуйте, dshe, Вы писали:

ZEN>>Декомпилировать полученный байт-код не пробовали?

ZEN>>Попробуйте, тогда посмотрим.

D>Интересно, какой именно байт-код наводит мысли о препроцессоре? И что именно в нем тебе не нравится?


Вот, навскидку.
Попробуйте откомпилировать код с новым энумератором (фор-ич, если не ошибаюсь; шаблоны-генерики).
Далее декомпилируйте class-файл.
Что получится? Во что превратится код? Один-в-один, я думаю, вряд ли получится.
(У меня к сожалению нет 1.5, но хочу выяснить некоторые моменты новой версии).
Re[6]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 16.06.04 06:23
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, dshe, Вы писали:


ZEN>>>Декомпилировать полученный байт-код не пробовали?

ZEN>>>Попробуйте, тогда посмотрим.

D>>Интересно, какой именно байт-код наводит мысли о препроцессоре? И что именно в нем тебе не нравится?


ZEN>Вот, навскидку.

ZEN>Попробуйте откомпилировать код с новым энумератором (фор-ич, если не ошибаюсь; шаблоны-генерики).
ZEN>Далее декомпилируйте class-файл.
ZEN>Что получится? Во что превратится код? Один-в-один, я думаю, вряд ли получится.
ZEN>(У меня к сожалению нет 1.5, но хочу выяснить некоторые моменты новой версии).

Я, признаюсь, все равно не понял, что же тебе не понравилось в новом jdk. Но чтобы говорить предментно, приведу пример с циклом for в новом стиле и в старом. Что касается нового синтаксиса, то это не более, чем синтаксический сахар (о чем говирит то, что enumList1 и enumList2 оттранслировались в абсолютно одинаковый байт-код). Тем не менее, я считаю, что for в новом стиле более удобен.

Такой исходник
import java.util.*;

public class Main {
    public static void enumList1(List<String> l) {
        for(String o: l) {
            System.out.println(o);
        }
    }
    public static void enumList2(List<String> l) {
        Iterator<String> i = l.iterator();
        while(i.hasNext()) {
            String o = i.next();
            System.out.println(o);
        }
    }
    public static void enumArray1(String[] l) {
        for(String o: l) {
            System.out.println(o);
        }
    }
    public static void enumArray2(String[] l) {
        for(int i=0, n=l.length; i<n; ++i) {
            String o = l[ i];
            System.out.println(o);
        }
    }
}


компилируется в такой байт-код
Compiled from "Main.java"
public class Main extends java.lang.Object
  SourceFile: "Main.java"
  minor version: 0
  major version: 0
  Constant pool: ...omitted...

{
public Main();
  Code:
   Stack=1, Locals=1, Args_size=1
   0:    aload_0
   1:    invokespecial    #1; //Method java/lang/Object."<init>":()V
   4:    return
  LineNumberTable: 
   line 3: 0

public static void enumList1(java.util.List);
  Code:
   Stack=2, Locals=3, Args_size=1
   0:    aload_0
   1:    invokeinterface    #2,  1; //InterfaceMethod java/util/List.iterator:()Ljava/util/Iterator;
   6:    astore_1
   7:    aload_1
   8:    invokeinterface    #3,  1; //InterfaceMethod java/util/Iterator.hasNext:()Z
   13:    ifeq    36
   16:    aload_1
   17:    invokeinterface    #4,  1; //InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
   22:    checkcast    #5; //class java/lang/String
   25:    astore_2
   26:    getstatic    #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   29:    aload_2
   30:    invokevirtual    #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   33:    goto    7
   36:    return
  LineNumberTable: 
   line 5: 0
   line 6: 26
   line 7: 33
   line 8: 36
  Signature: length = 0x2
   00 12 

public static void enumList2(java.util.List);
  Code:
   Stack=2, Locals=3, Args_size=1
   0:    aload_0
   1:    invokeinterface    #8,  1; //InterfaceMethod java/util/List.iterator:()Ljava/util/Iterator;
   6:    astore_1
   7:    aload_1
   8:    invokeinterface    #3,  1; //InterfaceMethod java/util/Iterator.hasNext:()Z
   13:    ifeq    36
   16:    aload_1
   17:    invokeinterface    #4,  1; //InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object;
   22:    checkcast    #5; //class java/lang/String
   25:    astore_2
   26:    getstatic    #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   29:    aload_2
   30:    invokevirtual    #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   33:    goto    7
   36:    return
  LineNumberTable: 
   line 10: 0
   line 11: 7
   line 12: 16
   line 13: 26
   line 14: 33
   line 15: 36
  Signature: length = 0x2
   00 12 

public static void enumArray1(java.lang.String[]);
  Code:
   Stack=2, Locals=5, Args_size=1
   0:    aload_0
   1:    astore_1
   2:    aload_1
   3:    arraylength
   4:    istore_2
   5:    iconst_0
   6:    istore_3
   7:    iload_3
   8:    iload_2
   9:    if_icmpge    31
   12:    aload_1
   13:    iload_3
   14:    aaload
   15:    astore    4
   17:    getstatic    #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   20:    aload    4
   22:    invokevirtual    #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   25:    iinc    3, 1
   28:    goto    7
   31:    return
  LineNumberTable: 
   line 17: 0
   line 18: 17
   line 17: 25
   line 20: 31

public static void enumArray2(java.lang.String[]);
  Code:
   Stack=2, Locals=4, Args_size=1
   0:    iconst_0
   1:    istore_1
   2:    aload_0
   3:    arraylength
   4:    istore_2
   5:    iload_1
   6:    iload_2
   7:    if_icmpge    27
   10:    aload_0
   11:    iload_1
   12:    aaload
   13:    astore_3
   14:    getstatic    #6; //Field java/lang/System.out:Ljava/io/PrintStream;
   17:    aload_3
   18:    invokevirtual    #7; //Method java/io/PrintStream.println:(Ljava/lang/String;)V
   21:    iinc    1, 1
   24:    goto    5
   27:    return
  LineNumberTable: 
   line 22: 0
   line 23: 10
   line 24: 14
   line 22: 21
   line 26: 27

}
--
Дмитро
Re: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 17.06.04 07:26
Оценка:
Здравствуйте, Ноздреватых Ростислав aka Blazkowicz, Вы писали:

НРA>Статья:



НРA>Авторы:

НРA> Ноздреватых Ростислав aka Blazkowicz

НРA>Аннотация:

НРA>Выход проекта под кодовым именем Tiger на сегодняшний день – одно из самых ожидаемых событий в мире Java 2. Новая версия, 1.5, – это не просто ещё одна единичка в номере версии, это ряд революционных новшеств, которых, наверное, не было со времен появления Java 2. В этой статье будут рассмотрены основные из них.

Интересно, как были переведены термины
generics (в отношении не только классов, но и методов)
type parameter
generic method
wildcard

PS
К сожалению, статью в журнале не читал.
--
Дмитро
Re[3]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 10:44
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[4]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 12.10.04 10:46
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


Извиняюсь не силен в генериках, что значит "параметризированнное наследование"?
Re[5]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 10:54
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Batiskaf, Вы писали:


B>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


B>Извиняюсь не силен в генериках, что значит "параметризированнное наследование"?


Да я тоже не силен, я по С++ темплейтам больше, речь идет о такой фишке, которая доступна в С++ шаблонах:


template<typename T>
struct A : public T
{
//bla bla
};

//а еще так
template<template<class> class T>
struct A: public T<A>
{
//bla bla
};
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[6]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 12.10.04 10:58
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Да я тоже не силен, я по С++ темплейтам больше, речь идет о такой фишке, которая доступна в С++ шаблонах:


B>
B>template<typename T>
B>struct A : public T
B>{
B>//bla bla
B>};

B>//а еще так
B>template<template<class> class T>
B>struct A: public T<A>
B>{
B>//bla bla
B>};

B>


А для тех кто в танке можно по русски что требуется? Я просто на плюсах писал в далёком студентчестве без всяких шаблонов. И такой код для меня полная загадка.
Re[7]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:13
Оценка:
Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Batiskaf, Вы писали:


B>>Да я тоже не силен, я по С++ темплейтам больше, речь идет о такой фишке, которая доступна в С++ шаблонах:


B>>
B>>template<typename T>
B>>struct A : public T
B>>{
B>>//bla bla
B>>};

B>>//а еще так
B>>template<template<class> class T>
B>>struct A: public T<A>
B>>{
B>>//bla bla
B>>};

B>>


B> А для тех кто в танке можно по русски что требуется? Я просто на плюсах писал в далёком студентчестве без всяких шаблонов. И такой код для меня полная загадка.


Допустим у меня есть некая типовая имплементация методов, имплементация эта может быть выражена в виде шаблона (джава дженерика ), и эту функциональность я могу как бы насадить на любой класс, расширить тем самым этот класс, может даже переопределить некоторые методы расширяемого класса, например, класс А содержит пять методов, которые очень здорово присоединить к классу В и получить в миксе класс С. В джаве это решается путем наследования В от А, но хотелось бы вот одной строкой получить новый класс С а не влазить в реализацию класса В. А еще если в классе А определены методы, которые еще и в В присутствуют, то полусится переопределение метода, очень гибкие идиомы вокруг этого разворачиваются в С++, без этих фишек шаблоны будут иметьочень ограниченную сферу применения.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[6]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 12.10.04 11:19
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Здравствуйте, Blazkowicz, Вы писали:


B>>Здравствуйте, Batiskaf, Вы писали:


B>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


Нет. Не разрешено.
--
Дмитро
Re[8]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:23
Оценка:
Здравствуйте, Batiskaf, Вы писали:


B>Допустим у меня есть некая типовая имплементация методов, имплементация эта может быть выражена в виде шаблона (джава дженерика ), и эту функциональность я могу как бы насадить на любой класс, расширить тем самым этот класс, может даже переопределить некоторые методы расширяемого класса, например, класс А содержит пять методов, которые очень здорово присоединить к классу В и получить в миксе класс С. В джаве это решается путем наследования В от А, но хотелось бы вот одной строкой получить новый класс С а не влазить в реализацию класса В. А еще если в классе А определены методы, которые еще и в В присутствуют, то полусится переопределение метода, очень гибкие идиомы вокруг этого разворачиваются в С++, без этих фишек шаблоны будут иметьочень ограниченную сферу применения.


Пожалуй стоит проилюстрировать ( псевдо код ):


struct Person
{
   void SetName(string name){}
};

struct Product
{
   void SetName(string name) {}
};

template< typename T >
struct CheckNameLength : public T
{
  void SetName(string name)
  {
    if( name.length() > 0 )
      T::SetName(name);
    else
      throw ZerroLengthError(...);
  }
};

CheckNameLength<Person> vasya;
vasya.SetName("Vasya");
CheckNameLength<Product> windowsXP;
windowsXP.SetName("Windows XP");
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[8]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:24
Оценка:
Здравствуйте, Batiskaf, Вы писали:


B>Допустим у меня есть некая типовая имплементация методов, имплементация эта может быть выражена в виде шаблона (джава дженерика ), и эту функциональность я могу как бы насадить на любой класс, расширить тем самым этот класс, может даже переопределить некоторые методы расширяемого класса, например, класс А содержит пять методов, которые очень здорово присоединить к классу В и получить в миксе класс С. В джаве это решается путем наследования В от А, но хотелось бы вот одной строкой получить новый класс С а не влазить в реализацию класса В. А еще если в классе А определены методы, которые еще и в В присутствуют, то полусится переопределение метода, очень гибкие идиомы вокруг этого разворачиваются в С++, без этих фишек шаблоны будут иметьочень ограниченную сферу применения.


Пожалуй стоит проилюстрировать ( псевдо код ):


struct Person
{
   void SetName(string name){}
};

struct Product
{
   void SetName(string name) {}
};

template< typename T >
struct CheckNameLength : public T
{
  void SetName(string name)
  {
    if( name.length() > 0 )
      T::SetName(name);
    else
      throw ZerroLengthError(...);
  }
};

CheckNameLength<Person> vasya;
vasya.SetName("Vasya");
CheckNameLength<Product> windowsXP;
windowsXP.SetName("Windows XP");
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[7]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 11:42
Оценка:
Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Batiskaf, Вы писали:


B>>Здравствуйте, Blazkowicz, Вы писали:


B>>>Здравствуйте, Batiskaf, Вы писали:


B>>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


D>Нет. Не разрешено.


Ясно... Да, крадущийся тигр, точно подмечено, только хочется бегущего тигра.

Ну а метаданные к примеру, можно ли например соорудить на этой фишке что то типа аспектов, что бы управление передавалось в метод анотации, типа если анотация присвоена члену класса то вызвать сначала метод анотации, которая с параметром чего то проделает а потом передать члену класса, тоже самое можно и в отношении методов класса делать, собственно тоже самое, что можно уже сегодня делать темплейтами на плюсах.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[9]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 13:38
Оценка:
Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Batiskaf, Вы писали:


B>>>>>>Интересно, а параметризированнное наследование в джава дженериках разрешено? Бегло пробежал презенташку, вроди не нашел...


D>>>Нет. Не разрешено.


B>>Ясно... Да, крадущийся тигр, точно подмечено, только хочется бегущего тигра.


B>>Ну а метаданные к примеру, можно ли например соорудить на этой фишке что то типа аспектов, что бы управление передавалось в метод анотации, типа если анотация присвоена члену класса то вызвать сначала метод анотации, которая с параметром чего то проделает а потом передать члену класса, тоже самое можно и в отношении методов класса делать, собственно тоже самое, что можно уже сегодня делать темплейтами на плюсах.


D>Снова нет. Для аспектов существует AspectJ.


А в одном флаконе можно? : Странно как то, хочется использовать продвинутые парадигмы программинга, а тебе предлагают типизированный вектор построить, сиди и не выступай Вот из-за таких вещей я не долюбливаю джаву, сколько лет кричали что как здорово что появилась джава, в ней все гораздо проще, и даже этих ужастных темплейтов нету, а когда разобрались наконец что без таких мега средств сегодян нельзя то выдали блин...

D>Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

Потому что темплейт в С++ это инструмент имплементации а не инструмент для дизайна. Диагностика ошибок это все еще недочеты компиляторов, над этим работают, за последние несколько лет диагностика ошибок в плюсах улучшилась в разы.

D>В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

Ну разницы на самом деле никакой, что компилировать по нормальному, что он зе флай как в дотнет, все равно идет раздувание сегмента кода как и в случае с темплейтами, просто мы не видим, как Reflection.Emit монтирует новые классы в процесс. А если же джава и вовсе их компилирует на в байт код во время основной компиляции то тогда не вижу причины упрощать параметризирование, разработай нормальную диагностику ошибок и дай людям полноценный инструмент.

D>Кстати, существовало довольно много реализаций генериков на Java. Наиболее известные: PolyJ, NextGen, GJ. Tiger происходит главным образом от GJ.


D>Вот, может быть, будет интересна эта ссылка:

D>Java Generics: Final Report
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[10]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 12.10.04 14:31
Оценка:
Здравствуйте, Batiskaf, Вы писали:

D>>Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

B>Потому что темплейт в С++ это инструмент имплементации а не инструмент для дизайна. Диагностика ошибок это все еще недочеты компиляторов, над этим работают, за последние несколько лет диагностика ошибок в плюсах улучшилась в разы.

Я не думаю, что без ограниченного параметризма можно удовлетворительно диагностировать ошибки.
Java не позволит откомпилировать такой класс:
public class Sample {
     <T> boolean less(T a, T b) {
          return (a.compareTo(b) < 0);
     }
}

потому, что компилятор не знает откуда взялось compareTo и как его вызвать. А вот так
public class Sample {
     <T extends Comparable<T>> boolean less(T a, T b) {
          return (a.compareTo(b) < 0);
     }
}

очень даже откомпилируется. И для VM этот класс будет выглядеть приблизительно так:
public class Sample {
     boolean less(Comparable a, Comparable b) {
          return (a.compareTo(b) < 0);
     }
}

И этот самый код будет использоваться и для Sample.less<Integer>, и для Sample.less<String>. А вот Sample.less<Thread> вызовет ошибку компиляции поскольку Thread не реализует интерфейс Comparable<Thread>. И эта ошибка внятно об этом сообщит. Причем (это важно отметить!) компилятор будет руководствоваться исключительно декларацией метода, а не тем, как же этот метод внутри реализован.

В C++ же каждая новая инстанция шаблона компилируется "заново", что приводит во-первых к code bloat, а во-вторых, к тому, что в случае неправильного использования шаблона (параметризации его неверным типом) компилятор в состоянии только указать на то, что же именно в недрах шаблонного класса ему не понравилось, вынуждая тем самым программиста, который использует данный шаблонный класс, разбираться в его реализации. (Конечно, в C++ существуют приемы, которые позволяют "ограничивать" параметры шаблонов. Однако, поскольку это не является частью языка, разработчики шаблонов могут ими не пользоваться или ошибаться -- т.е. не указывать все ограничения.)

D>>В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

B>Ну разницы на самом деле никакой, что компилировать по нормальному, что он зе флай как в дотнет, все равно идет раздувание сегмента кода как и в случае с темплейтами, просто мы не видим, как Reflection.Emit монтирует новые классы в процесс.

В .NET идет генерация кода только для value-типов (object-типы разделяют общий код). В С++ отдельный код создается для каждой инстанции шаблона.
--
Дмитро
Re[11]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Batiskaf Израиль http://www.mult.ru/
Дата: 12.10.04 15:13
Оценка:
Здравствуйте, dshe, Вы писали:

D>Здравствуйте, Batiskaf, Вы писали:


D>>>Темплейты в C++ действительно более мощная и выразительная вещь, чем генерики. Основа их мощности, на мой взгляд, в том, что С++ параметризм неограниченный. Т.е. не существует языковых средств, которые контролировали параметры-типы, которые передаются при инстанцировании шаблона, и поэтому передавать туда можно все, что угодно. Однако, в связи с этим возникают некоторые проблемы -- ошибки компиляции появляются только при инстанцировании шаблона, их диагностика ужасна, шаблоны нельзя откомпилировать (и собрать их них, например, dll'ку) -- их код обязан быть целиком в хеадерах.

B>>Потому что темплейт в С++ это инструмент имплементации а не инструмент для дизайна. Диагностика ошибок это все еще недочеты компиляторов, над этим работают, за последние несколько лет диагностика ошибок в плюсах улучшилась в разы.

D>Я не думаю, что без ограниченного параметризма можно удовлетворительно диагностировать ошибки.

D>Java не позволит откомпилировать такой класс:
D>
D>public class Sample {
D>     <T> boolean less(T a, T b) {
D>          return (a.compareTo(b) < 0);
D>     }
D>}
D>

D>потому, что компилятор не знает откуда взялось compareTo и как его вызвать. А вот так
D>
D>public class Sample {
D>     <T extends Comparable<T>> boolean less(T a, T b) {
D>          return (a.compareTo(b) < 0);
D>     }
D>}
D>

D>очень даже откомпилируется. И для VM этот класс будет выглядеть приблизительно так:
D>
D>public class Sample {
D>     boolean less(Comparable a, Comparable b) {
D>          return (a.compareTo(b) < 0);
D>     }
D>}
D>

D>И этот самый код будет использоваться и для Sample.less<Integer>, и для Sample.less<String>. А вот Sample.less<Thread> вызовет ошибку компиляции поскольку Thread не реализует интерфейс Comparable<Thread>. И эта ошибка внятно об этом сообщит. Причем (это важно отметить!) компилятор будет руководствоваться исключительно декларацией метода, а не тем, как же этот метод внутри реализован.
Ну так пиши себе Comparable, зачем тебе параметризировать шаблоном, который сводится к тупому варианту Если уж javac.exe бежит, то в случае явного инстанцирования метода можно заглянуть в прототип класса, который опускается в less, и понять что метода такого не существует. Какая разница между двумя строчками:

public class Sample {
     <T> boolean less(T a, T b) {
          return (a.Fuck(b) < 0);
     }
}

void main(...)
{
   string str1 = "str1";
   string str2 = "str2";
   Sample s = new Sample();
   s.less(str1, str2 );

   str2.Fuck(); // почему компилятор в состоянии понять что метод не сущестует в интерфейсе класса, а в случае less не желает этого проверять и предпочитает обезопаситься??
}



D>В C++ же каждая новая инстанция шаблона компилируется "заново", что приводит во-первых к code bloat, а во-вторых, к тому, что в случае неправильного использования шаблона (параметризации его неверным типом) компилятор в состоянии только указать на то, что же именно в недрах шаблонного класса ему не понравилось, вынуждая тем самым программиста, который использует данный шаблонный класс, разбираться в его реализации. (Конечно, в C++ существуют приемы, которые позволяют "ограничивать" параметры шаблонов. Однако, поскольку это не является частью языка, разработчики шаблонов могут ими не пользоваться или ошибаться -- т.е. не указывать все ограничения.)

Ну так в том примере не компилируется заново потому что только одна версия и генерится, только какой прикол тогда использовать генерики, пиши себе Comparable, такое и в плюсах делать можно, только никакой гибкости. Мало того что в джаве нет перегрузки операторов, так еще и параметры нужно ограничивать, очень примитивные средства. А те вещи, о которых я говорю на самом деле должны компилироваться по новой, потому что речь идет о более высшей модульности темплейтных компонент, мне все равно сколько кода нагенерится для решения этой задачи, лучше пусть компилятор нагенерит, нежели я руками буду сам это генерить. И еще одна причина раздутого кода, это инлайн, практически всесь СТЛ инлайнится, чем и обусловлена хорошая производительность контейнеров их этой библиотеки, напиши свои контейнеры без инлайна и размер выходного файла существенно сократится, только проиграет производительность.



D>>>В Java пошли несколько иным путем -- параметризм в ней ограниченный, что позволяет генерик классы компилировать в байт-код. В добавок, информация о генериках необходима только на этапе компиляции -- виртуальная машина ничего не знает о генериках, поэтому на этапе выполнения не происходит никаких "телодвижений" (.NET 2.0, например, производит генерацию кода для новых инстанций).

B>>Ну разницы на самом деле никакой, что компилировать по нормальному, что он зе флай как в дотнет, все равно идет раздувание сегмента кода как и в случае с темплейтами, просто мы не видим, как Reflection.Emit монтирует новые классы в процесс.

D>В .NET идет генерация кода только для value-типов (object-типы разделяют общий код). В С++ отдельный код создается для каждой инстанции шаблона.


Возможно что я многих расстрою, но на рынке появляются уже С++ компиляторы, которые пошли еще дальше чем дот нет:


std::vector<int>;
std::vector<long>;


код для этих двух разных векторов будет общим, в этом направлении очень много потенциала для оптимизации, это только начало. Что касается параметризирования контейнеров указателями разных типов, то многие компиляторы уже давно справляются с этой ситуацией и генерят только одну специализацию вектора на всех типов указателей.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Re[2]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: Blazkowicz Россия  
Дата: 14.10.04 07:35
Оценка:
Здравствуйте, iZEN, Вы писали:

ZEN>Выскажу своё эмоциональное мнение и философский взгляд на вещи.


ZEN>Мне, например, резко не нравятся темплейты и генерики, по причине ещё одного "измерения" в семантическом пространстве выражения мыслей на языке (простите за слишком вумную фразу).


Ну не знаю. Для меня это не та причина по которой можно не любить генерики.

ZEN>Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.


А по-моему прикольно. Я уже привык и часто пользуюсь.

ZEN>Не множьте сущности без необходимости! (Как сказал один мудрец)

ZEN>Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!
ZEN>Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?
ZEN>Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
ZEN>Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

Вот такое есть. Новичков особенно запутывает.

ZEN>Да, размер исходного кода уменьшился значительно, но что взамен?

ZEN>1. ВЫРОСЛА СЛОЖНОСТЬ КОМПИЛЯТОРА (он защищён от ошибок? для C++ компилятор писали годами...но не избавились от неоднозначностей до сих пор);
Да, по-моему не сильно. Накрутили на него сторонние проекты и всего-то делов.

ZEN>2. ВЫРОС ПОРОГ ПОНИМАНИЯ КОДА ЧЕЛОВЕКОМ (теперь необходимо знать (о ужас!) шаблоны и дженерики, от которых отказались вначале для простоты);

Да и не только. Метаданные, новый улучшенный цикл, автобоксинг, аргументы переменной длины, всё это требует дополнительных знаний для понимания.

ZEN>3. ВЫРОСЛО ЧИСЛО ДУБЛИРУЮЩИХ СУЩНОСТЕЙ, отравляющих жизнь вопросами выбора, — налицо потребительский подход к решению задач.

Не знаю что ты имеешь в виду под "потребительским подходом". Но вот если сравнивать с производством другой продукции, то нельзя потребителю предоставлять слишком большие возможности по вариации продуктом. Потребитель должен иметь просто качественный продукт, а не продукт из которого можно сделать все что угодно.

То есть к примеру если вы издаёте журнал, то нельзя позволять читателю влиять на его дизайн. Нужно просто делать хороший дизайн. Тут ты на 100% прав.

ZEN>В общем, после версии 1.1.8 Java стала сложнее, а с выходом версии 1.5 язык потерял, наконец-то, всю прелесть простоты. От чего хотели уйти, к тому же и пришли — круг замкнулся.


Угу. Особенно меня раздражает в работе Sun не то что делается, а как. Такое ощущение что они идут по пути наименьшего сопротивления. Как бы побыстрее и попроще сделать, а на сколько хорошо в итоге получиться.
Re[3]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: iZEN СССР  
Дата: 15.10.04 09:17
Оценка:
Здравствуйте, Batiskaf, Вы писали:

B>Здравствуйте, iZEN, Вы писали:

iZEN>>Что ещё мне не нравится в Java2 ещё с версии 1.2 так это вложенные классы, которые используются как затычки, чтобы "не протекало" (ведь в откомпилированном коде они представляют собой обычные классы, в названии которых стоит дурацкий разделитель "$"). Опять же, ещё не одна семантика использования этих сущностей.

B>Ну так это же основная фишка в event handling в джава апликациях, потому как замыкания в джаве не придумали, и множественного наследования тоже нет

Интерфейсы моделируют множественное наследование не хуже. В редких случаях, правда, приходится обходить одинаковые сигнатуры.
А вот Event-обработка (Паттерн Observer, очевидно) может работать БЕЗ внутренних классов.
Что касается излишней "доступности" классов-обработчиков (Adaptee), то это спорный вопрос (а может в будущем понадобится делать отдельную ветку наследования обработчиков — с внутренними классами это получится не очень красиво).

B>Почему нельзя создать инстанс иннер класса вне класса внешнего<...>

<...>
B>Таким образом калбэк класс может имплементировать методы какого то ивент адаптера ( внешний класс не может этого сделать, потому как нет множественного наследования, он наследует к примеру бизнес логику предметной области, остается только наследоваться от интерфейсов, что не всегда удобно и муторно ). Таким же макаром в общем случае можно имитировать множественное наследование.
Это понятно.
Но сложности перекладываются на компилятор (Сейчас вообще — монстрина). Это мешает развиваться сторонним компиляторам, которые вынуждены копировать всё больше "особенностей" (если такие есть, ведь C++ компилер до сих пор неоднозначен) оригинального Sun-овского.

iZEN>>Не множьте сущности без необходимости! (Как сказал один мудрец)

B>Реальный мир гораздо сложнее того парника, который выдумывают себе люди.

iZEN>>Чего только стоит новый класс java.lang.StringBuilder — я офигеваю — мало классов-коллекций на каждый чих-аспект работы, пожалуте, — своя коллекция. От LinkedList до ArrayList в качестве аспекта общего контейнера Vector, так ещё параллельно StringBuffer-у ещё StringBuilder придумали, а методов у него — зашибись и все полезные оказывается!!!

B>Мне кажется все вполне логично, обычный стринг предназначен для хранения, передачи, легких модификаций, в билдере упор делается на удобный интерфейс построения, конкатинации стрингов, частых массивных модификаций, с более адаптированными под такие вещи стратегиями памяти. Такие вещи не возникают на прямом месте, вот просто так программисты ковыряли в носу и выдумали класс, рождение этого класса стало заключением некоторого опыта, частных решений специфических проблем, неважными результатами профилировки приложений. Насколько я понимаю стринг билдер это далеко не коллекция, это контейнер, но со своими, заточенными под определенные операции средствами.
Стратегия памяти не должна показывать свои уши в прикладном коде вообще — это касается LinkedList и ArrayList. Рантайм должен сам на лету определять, что куда быстро перемещается, и реагировать на это изменением стратегии планирования/распределения ресурсов.
В Java2 сделали всё наоборот: переложили на прикладной код системные вещи (BufferedStream-ы — типичная системная особенность) — это нужно было делать в нативной среде рантайма, а для Java-программиста оставить простые потоки, читалки, писалки и т.д.

iZEN>>Не, а разве не могли сделать один единственный класс java.lang.String более функциональным?

iZEN>>Разве нельзя сделать класс java.util.Vector более приспособленным для разных коллекций?
iZEN>>Зачем плодить сущности попусту? Расцвет видов и ареала обитания? Так это в живой природе только хорошо работает,...или хотят сделать из изначально компактной и простой платформы левиафана.

B>Процитирую себя же: "Реальный мир гораздо сложнее того парника, который выдумывают себе люди".

Так легче создать "парник" и сидеть там, чем колбаситься в этом дер...ом мире.
Re[4]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: mselez  
Дата: 28.10.04 18:51
Оценка:
Вот тут дисскуссии все о высоком.
Мы попробовали проект перевести на 1.5 . И сразу облом.

Уже не работает так:

StringBuffer buf = new StringBuffer();
buf.append(1.0f).append("kuku").append...


а работает так

StringBuffer buf = new StringBuffer();
buf.append(1.0f);//здесь возвращается AbstractStringBuilder
buf.append("kuku");
buf.append...


догадываюсь, что это только начало.
Re[5]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: dshe  
Дата: 29.10.04 06:37
Оценка:
Здравствуйте, mselez, Вы писали:

M>Вот тут дисскуссии все о высоком.

M>Мы попробовали проект перевести на 1.5 . И сразу облом.

M>Уже не работает так:


M>
M>StringBuffer buf = new StringBuffer();
M>buf.append(1.0f).append("kuku").append... 
M>


M>а работает так


M>
M>StringBuffer buf = new StringBuffer();
M>buf.append(1.0f);//здесь возвращается AbstractStringBuilder
M>buf.append("kuku");
M>buf.append... 
M>


Странно... Посмотрел в javadoc. Ни в 5.0, ни 1.5.0-beta2 никакого AbstractStringBuilder'а не нашел. StringBuffer.append(...) возвращает StringBuffer, StringBuilder.append(...) возвращает StringBuilder. Даже если бы возвращался AbstractStringBuilder, было бы странно, если бы у него не было такого полезного метода как append.

Ты можешь сказать на какой версии вы компилировали?
--
Дмитро
Re[7]: Крадущийся тигр (Что нас ждет в Java 1.5)
От: mselez  
Дата: 29.10.04 14:36
Оценка:
Здравствуйте, dshe, Вы писали:


D>У меня есть подозрения, что вы компилировали eclipse'овым компилятором, который еще не совсем 1.5.


компилировали из-под JBuilder. В API действительно написано, что возвращается StringBuffer и все должно работать. Разбираемся.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.