Autumn of Agile Screencast Series.

Летом Stephen A. Bohlen (вчера, кстати, он стал членом команды NHibernate) записал серию скинкастов "Summer of NHibernate", подробно демонстрирующую основные возможности NHibernate. Так же в ней демонстируются способы эффективного тестирования с помощью TestDriven.NET и MbUnit  и способы организации тестов для кода доступа к данным с использованием NDbUnit. Я думаю данная серия будет интересна многим разработчикам, даже не работающим с NHibernate.

В сентябре же Stephen начал новую серию - "Autumn of Agile". В этой серии он рассматривает основные agile-принципы разработки изнутри (со стороны процесса разработки). Мне кажется получится очень достойная серия, советую смотреть.

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

Породы программистов(часть 2).

В сообщении Породы программистов(часть 1) были перечислены основные породы программистов, здесь же будут перечислены редкие.

Волшебник

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

Минималист

Несмотря на удивительно скромный объем кода, производимого минималистами, код обычно оказывается очень функциональным. каждая процедура умещается в редакторе кода на одном экране. Объекты стройны, выстроены четко и недвусмысленно сообщают о своем назначении. Звучит неплохо, не правда ли? В общем, да, только стоило бы учитывать мативы такого поведения. Ведь иногда они кроются в том, что человек хочет побыстрее разобраться с текущим проектом и перейти к следующему, который его больше захватывает. Иногда (кстати говоря, эта характеристика распространяется и на архитекторов) минималисты, решив поставленную задачу, быстро теряют к ней всякий интерес, и уж, конечно, при обнаружении в ходе альфа-тестирования каких-либо проблем высказывают устойчивое нежелание их исправлять. Иногда минималисты капризны и очень придирчиво выбирают область приложения своих сил. С сопровождением кода дела у них обстоят хуже всех.

Аналогист

Ну ладно, ладно - слово "аналогист" я взял с потолка. Только не подумайте, что это медсестра, которая делает наркоз перед операцией. Нет - это программист, который не слишком силен в абстракции, но прекрасно справляется с аналогиями. Во время проектных совещаний аналогисты, постоянно выдумывающие все новые и новые аналогии, способны свести с ума любого. Но при этом нельзя не признать, что, как правило, они очень быстро схватывают суть задачи и в результате создают удобный, в том числе и для сопровождения, код. У некоторых аналогистов есть любимые аналогии, которые они наровят применить ко всем без исключения проблемам разработки программных продуктов. Они воображают компоненты маховиками, а успешно справившись со своей задачей, хвалятся тем, что их код "воспламеняется во всех цилиндрах". Их аналогии всегда привязаны к осязаемым объектам, поскольку, как я уже говорил, с абстрагированием дела у них обстоят неважно. Ну, в общем, вы меня поняли. Посадите аналогиста вместе с архитектором, и если они друг друга не прикончат, скорее всего, у них получится превосходный продукт. Правда, поскольку аналогисты не дружат с абстракцией, создавать объекты с четкими межуровневыми интерфейсами у них получается не всегда. Дело в том, что возможность создания в достаточной мере абстракного интерфейса объекта - это одно из величайших преимуществ объектно-ориентированного программирования, и поэтому конкретное мышление иногда мешает успешно справляться с поставленными задачами.

Трюкач

Трюкачи слишком увлекаются разными технологическими трюками.Они постоянно осваивают разные новинки, но результат от этого не улучшается. По правде говоря, нас всех в той или иной степени привлекают забавные технологические приемы. Я вот, например, помню мой первый компьютер. Он был аналоговым, и, аоворачивая диски, я переключал ветви в предустановленном аппаратном алгоритме. Эта штука была похожа на гипертрафированную логарифмическую линейку. В общем, я до сих пор люблю забавляться со всякими высокотехнологическими штуковинами.Если вам приходится работать с трюкачами, попытайтесь направить их увлечение игрушками на решение их первоочередной задачи, а именно на производство бизнес-решения. Если им удалось втиснуть на экран, который, как предполагается, будет работать с разрешением 800х600, 30 разных элементов пользовательского интерфейса, это еще совершенно не обозначает, что они решили сво задачу в соответствии с реальными потребностями пользователей. Трюкачи, при всех их познаниях в технологии, часто не могут усвоить конечное назначение программы. Полагая, сто их функции ограничиваются забавами с разными интрументальными средствами, они отказываются учитывать те аспекты программирования, благодаря которым мы не затрачиваем на сопровождение титанических усилий.

Разгильдяй

Что сказать о разгильдяях? Некторые люди небрежны, и это проявляется в коде, который они создают.Они не обращают внимания на такие мелочи, как правильное написание имен переменных и правила венгерской нотации. Зачастую качественно выполнять свои обязанности им мешают проблемы личного плана. Тому, как пишется эффективный код, их нужно учить. Они любят начать с одного стиля, а через процедуру - другую перейти к новому. Читать их код очень утомительно - иногда поздними ночами его приходится переписывать, поскольку иначе есть риск не успеть к сроку сдачи проекта. Если вы не справились с задачей по их вине, прошу вас: отнеситесь к ним снисходительно. В конце концов, они просто отъявленные разгильдяи, котрых лучше всего пересадить в отдел бета-тестирования. Хотя нет - так вы просто заморозите проблему, в итоге она все равно может может проявиться. Если разгильдяй действительно любит писать код, при условии, что вы уделяете достаточно внимания, он имеет шансы реабелитироваться. Всех, кому это не удается, нужно просто пнуть под зад или познакомить с консультантом по трудоустройству.

Тормоз

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

Любитель

Любители очень хотят стать настоящими программистами. Тщательно изучив какой-нибудь инструмент написания макрокоманд, они возводят себя в ранг хакеров. Единственная причина, по которой они бросают уютные места в отделах поддержки пользователей и тестирования, заключается в том, что, по их мнению, быть программистом - это очень круто. Да, мы, действительно, крутые, но, по большому счету, это лишь побочное следствие нашей основной деятельности. Любителям не хватает образования, но по мере их обучения мы должны пристально за ними следить и лишь при условии определенных достижений с их стороны поручать им работу над критически важными приложениями. Узнав на собственном опыте, как трудно заниматься программированием и какое серьезное внимание к деталям требуется программисту, любители часто разочаровываются в своем выборе. Они отказываются признавать превосходство объектно-ориентированных методов над процедурной парадигмой - и все потому, что нужное прозрение их еще не посетило. В защиту любителей вспомним замечательное высказывание: Любители построили ковчег, профессионалы построили титаник. На самом деле иногда свежий, не зашоренный взгляд начинающего программиста очень помогает нам - старым брезгливым технорям.

Профан

Программист-профан - это тот, кто называется тупицей. Хуже всего, когда профан не догадывается о своей тупости. Остерегайтесь таких людей. Иногда они могут достаться вам в наследство от предыдущих руководителей, но сами, я вас прошу, никогда их не нанемайте. У меня нет никаких предубеждений относительно умственно ущербных людей, но я твердо уверен, что в профессии требующей постоянного самосовершенствования и обучения, таким не место. Если человек невежда, но хочет стать лучше, - дайте ему шанс. Отправьте его, например, в отдел тестирования - иногда не отличающиеся выдающимися умственными способностями пользователи находят себя в отлове багов. ще одно одно соображение насчет глупости: на самом деле мы все постоянно страдаем от несовершенства того, что находится между клавиатурой и стулом. Но, в конце концов, если бы для написания кода не требовались мозги, этим бы занимались все без разбора, так ведь? Я советаю не путать невежество с глупостью. Невежество исправимо, а с глупостью лучше просто не связываться. Если вы унаследовали кадры, подобранные не программистом, вполне возможно, что среди ваших подчиненных есть такие типажи. Руководители, имеющие весьма отдаленное представление о технологии, иногда покупаются на необоснованные заверения бездарных претендентов на место.

Эклектик

Можно сказать, что эклектики просто стряпуют программные продукты. Представитель этой породы сочетает в себе какчества инженера, разгильдяя и не слишком талантливого художника, причем упомянутые ингредиенты находятся в чудовищной диспропорции. Результат их деятельности представляет собой винегрет из стилей кодирования и подключаемых модулей при невероятной путанице коде. Все это выглядет довольно привлекательно, но стоит лишь попробывать кусочек, как наступят необратимые последствия. Отправьте такого программиста на кулинарные курсы и обязательно проверьте, не скрывается ли за внешней оболочкой талантливости банальный разгильдяй. В классичсеком виде эта дворянская порода встречатеся довольно редко, а упомянул я ее по той причине, что отдельные ее черты проявляются в ситях кодирования самых разных типов программистов. Если они не считают нужным следовать корпоративным стандартам, вам придется посвящать все рабочее время напряженным попыткам выяснить, что же они все-таки имели в виду и как сопровождать их код. основным средством реабелитации эклектиков служит критика кода.

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

Благодарности автору книги "Herding Cats. A primer of programmers who lead programmers" J. Hank Rainwater'у за хороший материал и отдельное спасибо моей супруге Ирине за помощь, в переносе материала.

Породы программистов(часть 1).

Недавно была опубликована интересная заметка, которая заставила меня вспомнить о книге "Herding Cats. A primer of programmers who lead programmers" by J. Hank Rainwater. В ней, по-моему мнению, очень точно описаны типичные породы программистов :

Основные:

• архитектор;
• конструктивист;
• художник;
• инженер;
• ученый;
• лихач.

Редкие:

• волшебник;
• минималист;
• аналогист;
• трюкач;
• разгильдяй;
• тормоз;
• любитель;
• профан;
• эклектик.

Архитектор*

Большинство руководителей обожают этот тип программистов - и, действительно, любой такой деятель окажется ценным приобретением для вашей команды. В основном архитекторы концентрируются на общей структуре кода. Они мыслят объектами, а их лучший друг - лист белой бумаги. Посвящая себя без остатка решению бизнес-задач, они строят абстракции, проводят анализ систем, после чего переходят к кодированию конкретных решений. Слов нет - все это очень важные элементы программирования, но для комплексного выполнения задач их еще не достаточно. Зачастую в высшей степени разумные замыслы архитектора воплощаются в настолько общем и непонятном коде, что людей, могущих разобраться в нем и продолжить начинание, просто не находится. Особи, способные генерировать удачную идею в глове (а лучше в Visio), а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Недостаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорическо отказывается. Некторые архитекторы очень любят набросать структуру кода, с тем чтобы впоследствии передать его на растерзание программистам более "низкой" квалификации. Иногда в коде, написанном архитекторами, встречаются весьма странные конструкции - например, окна с сообщениями о системных прерываниях из-за ошибок, появляющихся по той лишь причине, что код предполагалось исполнять в виде библиотеки DLL на сервере.

* - Термином архитектор в данном случае обозначен один из личностных типов программистов и совершенно не имеется в виду полноценный программный архитектор.

Конструктивист

Конструктивисты получают удовольствие от процесса написания кода и его результата. Стратегическим планированием они себя утруждают не всегда, но факт в том, что с написанием кода они справляются быстро, причем в большинстве случаев ошибок в нем не обнаруживается даже на этапе альфа-тестирования. Код конструктивисты пишут по наитию, а потому их логика не всегда понятна. У некторых конструктивистом все в порядке и с интуицией, и со стратегическим планированием, поэтому код выступает естественным продолжением хода их мыслей. Но стоит попросить конструктивиста составить документацию, он обязательно ответит, что код самодокументируемый. В прочем, если на него немного надавить и дать понять, что без документации никуда не деться, он, вероятно, согласится ее составить - и сделает это качественно. Кто спорит - код должен быть самодокументриуемым, но следует иметь в виду, что основное внимание программисты этого типа уделяют процессу создания кода, поэтому остальное для них не так уж важно. Количеству сборок, которое конструктивист выдает за день, позавидует даже Microsoft. Соответственно, их код обычно отличается надежностью. Однако же по мере разбухания (а этот процесс неизбежен) надежность улетучивается, а конструктивист начинает судорожно искать новые, "заплаточные" решения - ведь для него важно видеть результат и пребывать в уверенности в том, что он справился с поставленной задачей. Констуркивист в сочетании с архитектором имеет все шансы стать прекрасной командой. Если же вы умудритесь отыскать конструктивиста и архитектора в одном лице, считайте, что львиная доля кадровых проблем решена.

Художник

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

Инженер

Инженеры вам понравятся. Эти ребята имеют обыкновение скупать все возможные средства сторонних производителей, писать десятки COM-объектов и сводить их воедино, так что они прекрасно работают в версии 1. Присущая им тяга к усложнению провляется лишь тогда, когда речь заходит о версии 1.1. Программирование часто приравнивают к инжененрии программных средств - и, действительно, многие стороны нашей профессии подчиняются этой методологии. Но давать инженерам карт-бланш нельзя. В программных продуктах, выстроенных инженерными методами, нет ничего предрассудительного - в конце концов, согласно классическому определению, инженерия есть научные принципы, задействованные при решении программных задач. Нам нужны программисты, которые не боятся сложностей, но те из них, которые любят усложнять все и вся, представляют серьезную опасность. Поймите меня правильно: я совершенно не собираюся бросать камень в огород инженеров. В конце концов, я сам многие годы трудился над аппаратным обеспечением компьютеров. Но аппаратная направленность иногда входит в противоречие с теми аспектами программного обеспечения, благодаря которым оно становится программируемым (то есть гибким и многократным используемым). Любое аппаратное устройство обычно служит одной, четко определенной цели, а для программного обеспечения такой подход неприемлим.

Ученый

Ученые - это мальчики и девочки, которые считают себя последователями Бебиджа и Тьюринга. Никогда в жизни они не вставят в код инструкцию GoTo. Отодвигая художественную составляющую программирования на второй план, они делают все в соответствии с фундаментальными принципами компьютерных наук. И как раз в этом обычно и заключается проблема. В то время, как они одержимы безупречностью своих трудов, ваша главная забота как руководителя состоит в том, чтобы разработать доброкачественный продукт и сдать его к установленному сроку.  Программисты такого типа на самом деле очень полезны, и когда речь заходит об особо трудных задачах кодирования , их идеям нет цены. Вы просто должны следить за тем, что бы их педантичность не привысила практические соображения. У инженеров и ученых есть общая черта  - те и другие любят все усложнять.  Иногда даже кажется, что они поклоняются богу сложности (и даже приносят ему жертвы!).  Отдавая должную оценку глубочайшим познаниям ученых и по мере необходимости обращаясь к ним, руководитель не должен допускать их полновластия в вопросах написания кода - иначе они сделают его слишком сложным.

Лихач

Лихачи - это те товарищи, которые делают все быстро. Забывая о комментариях, отступах и соглашениях об именовании, они, тем не менее, умудряются достигать результата очень оперативно - и, что самое замечательное, вплоть до первой неперехваченной ошибки их продукты вполне успешно работают. Иногда такое поведение характерно для молодых программистов, горящих желанием впечатлить вас, - они опрометчиво считают, что оперативность в достижении результата в полной мере соответствует вашим ожиданиям Признайтесь: мы часто сами выстраиваем у них столь ложное представление, а значит, веди мы себя по-другому, никаких лихачей бы не было. Наши собственные начальники устраивают совещания, на которых устанавливают контрольные сроки, а потом сообщают их нам. Как мы добьемся выполнения поставленных задач  - это уже наша проблема. Вспомните, как часто идут разговоры о бессмысленности установления крайних сроков кодирования до окончательного выяснения всех требований! Так вот, вам придется к этому привыкнуть.

Описание редких пород читайте в последующих записях блога.

Интересный факт о безопасности загрузки сборок из GAC.

Поскольку я по образованию "защитник информации"(075400 МИЭТ), то постоянно интересуюсь новостями в этой области, и сегодня увидел интересную статью по теме.  Автор описывает способ внедрения вредоносного кода в разные части .NET Framework, например, в метод аутентификации из System.Web.dll с последующей пересылкой логинов и паролей злоумышленнику, в метод чтения строк подключения к базе данных, компрометации классов из System.Security.Cryptography,  javascript кода XSS в System.Web.dll, компроментации CAS т.е. отключение  CodeAccessPermission::Demand(),   CodeAccessPermission::Deny(),   CodeAccessPermission::Assert(),  FileIOPermission, RegistryPermission, и т.п., простого backdoor  в любой код Framework'а, ну и прочих гадостей, не подчиняюшихся CAS. Им так же написана утилита позволяющая частично автоматизировать этот процесс.  Конечно это "post exploitation" атака, т.е. что бы все это проделать необходимы права администратора на машине, но это на самом деле не так важно.

Изменение кода управляемой библиотеки представляет собой тривиальную задачу(даже подписанной), но основная польза от исследования автора заключается в том, что он отметил следующее поведение: если сборка загружена в GAC, то загрузчик не пытается проверять подпись, а просто загружает сборку по соотвествующему(версия, культура, маркер открытого ключа) физическому пути(например для mscorlib.dll C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll). Именно этот факт, позволяет просто перекомпилировать сборки из GAC, игнорируя хаки с подписью совсем, с дальнейшим копированием сборок по соответствующему физическому пути файловой системы. Кстати, стоит отметить, что для сборок(подписанных, разговор только о них), которые не установлены в GAC, проверка осуществляется каждый раз при загрузке приложения.

Байт-код провайдеры в NHibernate 2.1

Один из авторов NHibernate Fabio Maulo сообщил в своем блоге, что на данный момент в trunk внесены изменения позволяющие выбирать между несколькими прокси-генераторами. До сих пор использовался Casle.DynamicProxy2, теперь его монополия нарушена LinFu, который по словам автора(и по словам Fabio, кстати, тоже) быстрее предыдущего, планируется, так же, возможность подключения фабрики прокси из Spring.NET.

В конфигурацию session-factory добавлен новый обязательный параметр - proxyfactory.factory_class:

<hibernate-configuration  xmlns="urn:nhibernate-configuration-2.2" >
    <session-factory name="YourAppName">
        <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
        <property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>
        <property name="connection.connection_string">
            Server=(local);initial catalog=nhibernate;Integrated Security=SSPI
        </property>
        <property name="proxyfactory.factory_class">NHibernate.ByteCode.LinFu.ProxyFactoryFactory, NHibernate.ByteCode.LinFu</property>
    </session-factory>
</hibernate-configuration>

Для тех кто использует в своих приложения IOC контейнер Windsor или реализацию Active Record для NHibernate от Castle, тем благоразумнее остаться с DynamicProxy2, остальным же можно выбирать. Возможность заменять такую важную деталь(как генерация прокси) очень важна для проекта NHibernate, и еще раз подтверждает его расширяемость. Поскриптум Fabio ))): "Let me say that something strange happened in my heart when I had remove the last reference to Castle in NH-Core and NH-Tests."

IntelliJ IDEA 8 Released.

Сегодня был выпущен релиз одной из самых лучших(возможно самой лучшей) IDE для разработки на java от компании JetBrains. Далее приводится информация с официального сайта:

Languages & Frameworks

• SQL-92, MySQL, SQLite with coding assistance and Console to run SQL scripts from the IDE
• Template languages: FreeMarker, Velocity
• XPath/XSLT, including XPath expression evaluation
• Groovy/Grails with advanced editing, new refactorings and Gant
• JBoss Seam
• Struts 2
• Spring 2.5
• Spring Webflow
• Spring MVC
• Spring Dynamic Modules
• GWT 1.5
• RESTful WebServices

Features & Improvements

• 7 New Java Refactorings
• Dataflow to This — see the where an arbitrary parameter value comes from
• Create new test for class intention and navigation between classes/tests
• UML class diagrams with navigation to the source code and refactorings
• Thread dump analyzer
• Automatic namespace import for HTML/XML/JSP
• JavaScript debugger
• Flex debugger
• Advanced Flex code editor for MXML and ActionScript files, with Flash 10 generics
• Maven: create new module from archetype, Repository Browser, pom.xml validation and editing assistance
• Subversion 1.5 merge tracking support

От себя хочу добавить одну мысль, которая давно сформировалась в голове, в процессе долгой работы с продуктами от компании JetBrains: "Все сделано просто и работает максимально эффективно, т.е. специально для людей, а не для киборгов!". Спасибо. Побольше бы таких продуктов.

Путешествия из .NET в Java и обратно с IKVM.NET

И так, сегодня хочу упомянуть  проект IKVM.NET - реализация Java для .NET Framework и Mono с открытым исходным кодом. IKVM.NET состоит из: 

• виртуальной машины(JVM) реализованной на .NET;
• реализации на .NET библиотеки основных классов из OpenJDK;
• набора средств обеспечивающих возможность взаимодействия .NET и Java.

Поскольку в описании для IKVM.AWT.WinForms.dll сказано:

Very limited and broken implementation of a few AWT peers. This is a low priority issue until the platform stabilizes and works sufficiently well.

решил осуществить путешествие с использования именно "слабой" стороны(предпочитаю именно такой подход). Сделал маленькое приложение на Java:

java -jar ikvm-test.jar

Запустил на ikvm(на машине не установлена java):

ikvm -jar ikvm-test.jar

Улыбнуло. Выполнил:

ikvmc ikvm-test.jar

на выходе ikvm-test.exe, запуск:

 

Снова улыбнуло. Далее вызвал команду:

ikvmstub mscorlib.dll

на выходе получил mscorlib.jar ))), на который можно ссылаться при компиляции приложений на java, однако запуск таких приложений возможен только с использованием ikvm или в .net/mono после использования ikvmc.

Конечно, вряд ли стоит говорить о полном воссоединении технологий, но сам по себе проект очень занимательный, которому, несмотря на то, что он еще находится в разработке, уже нашлось применение в реальной жизни: Eclipse, JmDNS, JGroups, Jetty. Вообще, у автора IKVM.NET очень интересный блог, особенно для тех, кто глубоко интересуется  обоими технологиями.