Спасибо! Неплохой простой пример step-by-step для MapReduce.
У меня вопрос касательно подгружаемого jar с классом Reduce на нады кластера hadoop. В какую JVM он грузится? В JVM самой ноды hadoop под отдельный ClassLoader или как-то иначе?
Спасибо автору. Интересный прием с пустым finalize(){}; Конечно с оговорками, которые были упомянуты в посте.
Finalize конечно, в большом мире java достаточно редко используемая вешь, но где используется Week/SoftReference вполне возможная ситуация, когда finalize будет необходим.
За пост — пять!
Я имею в виду именно сам метод create у вас возвращает бесконтрольный на этапе компиляции объект.
С контролем типов есть большие трудности. Мне очевидно следует полностью пересмотреть идею хранения и контроля типов в кортеже. Это была первая, но возможна не самая удачная попытка. Именно для того чтобы как можно полней осознать все за и против этого способа храннеия кортежа я и вынес на обсуждение эту тему. Но с моей точки зрения всеже есть и явные «фишки» у такого рекурсивной способа описания структуры. Возможно кому-то будет удобно его применить совершенно в другой области. :)
Всеже справедливости ради надо сказать, что все так сконцентрировались на кортеже, но практически никто не смотрел на коллекции. В них собственно и весь «сахар» (я же писал о методах findAny и extract). В следующей версии скорее всего будет другая сруктура у кортежа, но то, что получилось сделать в коллекциях я постараюсь сохранить.
Да, Вы правы, усилить контроль над типами элеменентов кортежа стоит. Ваше предложение на счет create(Class<? extends Object>... types) разумно. Но опять же остаются грустные случаи когда программист сможет продекларировать кортеж с одним набором типов и кол-вом элементов, но вызвать приэтом метод create с совершенно иным набором типов и их кол-вом. Приведу пример:
Я к сожелению не могу придумать как проверить такую ситуацию на этапе компиляции. :( Если Вы можете подсказать решение, буду очень благодарен.
На счет:
Но ведь и сейчас он у вас совершенно без всякого контроля типов возвращает кортеж. Или я чего-то не понял?
Не везде контроль отсутствует. Если брать элементы поочередно методом getValue() тип контролируется на этапе компиляции.
Отсутствует контроль, когда происходит обращение к элементу по индексу как в getValue(int index).
Мне честно очень жаль, что Ваша грусть столь велика.
Но мне кажется Вы привели не совсем честный пример, отношение к которому не имеет моя библиотека. Я какраз хотел уйти от подобный кашмарных выражений типа
Но конечно же я не могу с Вами не согласиться в том, что название интрефейса Cortege возможно не очень удачно. Обязуюсь отнестись к Вашему замечанию серъезно и постараться решить этот вопрос.
Конечно отчасти Ваше замечание на счет громоздкости декларации кортежа справедливо, на данный момент я еще не придумал более компактной формы декларации типов, без потери неограниченности длины кортежа.
Согласен. Действительно есть трудность с пониманием смысла значения хронящегося в какой-либо позиции. Особенно когда тип элементов часто повторяется. Например,
Конечно лучше когда есть контейнер с вразумительными геттерами.
Но в некоторых случаях может понадобиться получить фрагмент кортежа и рассматривать его как самостоятельную сущность. Cortege как в примере,
Опять же, стоит обратить внимание на инструментарий, который дают имплементации коллекций как: CortegeSetи CortegeList. В посте есть пример использование некоторых возможностей. Например, найти подколлекцию по значению элемента в кортежах или по предикату. (методы findAny и extract)
Я именно о таком решении уже думал, но пока не решился на включение его в релиз: Cortege<Long, Cortege<String, Cortege.End>> cortegeLS = CortegeChain.create(Long.class,String.class);
Действительно, осуществлять проверку в runtime можно будет достаточно легко.
Но есть два минуса:
1. декларация кортежа более трех элементов (основная область применения) будет очень длинной :(
2. к сожалению проверка будет только на runtime мне кажется этого мало, хочется придумать красивое и компактное решение для котроля на этапе компиляции.
Но я полностью с Вами согласен, что предложеное решение позволит повысить контроль над типами. Очень возможно что в следующий релиз войдет Ваше решение. Спасибо.
Cortege не самое главно что мне хотелось показать. Если рассматривать Cortege как банальный контейнер для цепочки объектов, то проще использовать простой массив. :)
Более интересным с моей точки зрения является не кортеж, а коллекции CortegeSet и CortegeList.
Возможность использовать их как альтерантиву физической таблицы подобно как в реляционных базах, но в памяти.
Основной областью применения таких конструкций я вижу в первую очередь в случаях, когда нужно манипулировать с данными в таблице (искать, изменять, добавлять, удалять строки и/или элементы), но когда по окончанию жизненного цикла сама таблица больше не нужна (не сохраняется в базу данных). Например при формировании отчета.
У меня вопрос касательно подгружаемого jar с классом Reduce на нады кластера hadoop. В какую JVM он грузится? В JVM самой ноды hadoop под отдельный ClassLoader или как-то иначе?
Finalize конечно, в большом мире java достаточно редко используемая вешь, но где используется Week/SoftReference вполне возможная ситуация, когда finalize будет необходим.
За пост — пять!
С контролем типов есть большие трудности. Мне очевидно следует полностью пересмотреть идею хранения и контроля типов в кортеже. Это была первая, но возможна не самая удачная попытка. Именно для того чтобы как можно полней осознать все за и против этого способа храннеия кортежа я и вынес на обсуждение эту тему. Но с моей точки зрения всеже есть и явные «фишки» у такого рекурсивной способа описания структуры. Возможно кому-то будет удобно его применить совершенно в другой области. :)
Всеже справедливости ради надо сказать, что все так сконцентрировались на кортеже, но практически никто не смотрел на коллекции. В них собственно и весь «сахар» (я же писал о методах findAny и extract). В следующей версии скорее всего будет другая сруктура у кортежа, но то, что получилось сделать в коллекциях я постараюсь сохранить.
Подумаю как использовать.
create(Class<? extends Object>... types)разумно. Но опять же остаются грустные случаи когда программист сможет продекларировать кортеж с одним набором типов и кол-вом элементов, но вызвать приэтом метод create с совершенно иным набором типов и их кол-вом. Приведу пример:Я к сожелению не могу придумать как проверить такую ситуацию на этапе компиляции. :( Если Вы можете подсказать решение, буду очень благодарен.На счет:
Не везде контроль отсутствует. Если брать элементы поочередно методом
getValue()тип контролируется на этапе компиляции.Отсутствует контроль, когда происходит обращение к элементу по индексу как в
getValue(int index).Но мне кажется Вы привели не совсем честный пример, отношение к которому не имеет моя библиотека. Я какраз хотел уйти от подобный кашмарных выражений типа Но конечно же я не могу с Вами не согласиться в том, что название интрефейса
Cortegeвозможно не очень удачно. Обязуюсь отнестись к Вашему замечанию серъезно и постараться решить этот вопрос.Конечно отчасти Ваше замечание на счет громоздкости декларации кортежа справедливо, на данный момент я еще не придумал более компактной формы декларации типов, без потери неограниченности длины кортежа.
Конечно лучше когда есть контейнер с вразумительными геттерами.
Но в некоторых случаях может понадобиться получить фрагмент кортежа и рассматривать его как самостоятельную сущность.
Cortegeкак в примере,Опять же, стоит обратить внимание на инструментарий, который дают имплементации коллекций как:
CortegeSetиCortegeList. В посте есть пример использование некоторых возможностей. Например, найти подколлекцию по значению элемента в кортежах или по предикату. (методы findAny и extract)или
Cortege<Long, Cortege<String, Cortege.End>> cortegeLS = CortegeChain.create(Long.class,String.class);Действительно, осуществлять проверку в runtime можно будет достаточно легко.
Но есть два минуса:
1. декларация кортежа более трех элементов (основная область применения) будет очень длинной :(
2. к сожалению проверка будет только на runtime мне кажется этого мало, хочется придумать красивое и компактное решение для котроля на этапе компиляции.
Но я полностью с Вами согласен, что предложеное решение позволит повысить контроль над типами. Очень возможно что в следующий релиз войдет Ваше решение. Спасибо.
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>20040616</version>
</dependency>
И не увидел как можно сделать MultiKey длиней 5-ти элментов :(.
Возможно не так библиотека.
Но как альтернативу конечно тоже можно использовать.
Cortegeне самое главно что мне хотелось показать. Если рассматриватьCortegeкак банальный контейнер для цепочки объектов, то проще использовать простой массив. :)Более интересным с моей точки зрения является не кортеж, а коллекции CortegeSet и CortegeList.
Возможность использовать их как альтерантиву физической таблицы подобно как в реляционных базах, но в памяти.
Основной областью применения таких конструкций я вижу в первую очередь в случаях, когда нужно манипулировать с данными в таблице (искать, изменять, добавлять, удалять строки и/или элементы), но когда по окончанию жизненного цикла сама таблица больше не нужна (не сохраняется в базу данных). Например при формировании отчета.