Просто уже Microsoft внедряет don net. Вот и интересно. Конкуренция у МЕ конечно всегда была, но на dot net много людей пишут.

Всё зависит от производителей, насколько выгодно им будет то или иное. 
Я думаю в дальнейшем будут поддерживаться 2 среды и ME  и .NET

А вообще о многих маркетинговых темах Сан конечно тормозит, не сравнить с ушлостью и плагиатсвом Майкрософта.
Вот например сейчас считаю можно совершить большой скачёк Явы для JavaTV и JavaCard и сделать стандартом в будущем 
куда Мелкомягкие и суваться не станут. Но что-то особо засилия техникой с встроенной Явой мало, а это уж зависит от активности Сана.
Вот и получается что всё сами до такого допускают, а потом плачут и начинают метаться со словами "Что же делать, мелкомякие на пятки наступають!!!! =8-[ ] "

) 

Возможно dot net и будет конкурентом java, но честно говоря C++ тоже очень большой конкурент java во первых: Родной язык смартов, во вторых java достаточно молода, и возможностей  у нее много, вот только одна проблемма: производители не дают ей прав, как Guest в Windows. Что конечно немного разочаровывает  

Java уже очень не молода 

Но кс ожалению производители мобил а особенно смартов очень жестоки к java, что разочаровывает  

Samuil, в каком плане "жестоки"?

Вероятнее всего будут развиваться две платформы (три, если считать С/С++ под смарты). На то есть основания как у Sun, так и у Microsoft. Вобщем-то .NET вполне может потягаться с Java.
Но скорее всего они будут занимать рынки немного разных класов устройств. IMHO, конечно.
Просто, похоже, MS последнее время сконцентрировалась на медиа-решениях/приложениях, и они и будут развивать этот сегмент. Ну, а JavaME, это вроде как платформа "для всего".

javastic, 
В том плане, что java на смартах имеет очень мало возможностей, например: Нельзя управлять смартом, писать файловый менеджер и т.д.

Почему нельзя? Файловый менеджер писать можно если есть jsr-75.
А вообще Ява изначально делалась как безопасная среда по выполнению многих задач.

javastic, разве нокиа позволяет такое?

Samuil, всё зависит от того какая это нокиа. Открой ту прогу которую ты постил (по поводу разных моделей телефонов) и посмотри там. Или на сайте производителя.

в своё время довелось послушать Дэвида Чепела который в вопросе что порулит в HW Java vs .NET приводил стратегию развития Java через комитеты как главный аргумент против неё и в пользу .NET
И это ведь действительно медленнее, но зато может быть эффективнее.

Это сообщение отредактировал(а) redrick - 15.8.2006, 16:13

ТЕХНОЛОГИЯ BREW ГОРАЗДО БОЛЕЕ ПРОДВИНТУАЯ ЧЕМ JA2ME
НО ПОКА ТЕЛЕФОНОВ НА JAVA БОЛЬШЕ

Позвольте спросить - чем это Бру более продвинут ? С практической точки зрения программиста собирающегося заработать деньги на продаже своих програмных продуктов - чем ? Фрагментация по моделям телефонов и версиям Бру просто коллосальна , сложность разработки выше на порядок ,  плюс ко всему полная зависимость от Qualcоmm(а) в продажах , и обязательная сертификация (платная,помодельная а потому весьма дорогая) - даже для безобидных  не-сетевых игрушек. По одному только кривому "дизайну" CDMA/Бру телефонов , от никому не известных производителей можно определить что популярность сей платформы  падает , даже несмотря на то что Qualcomm держит монополию на мобильную связь в некотрых латиноамериканских странах. Ну и кроме того Qualcomm недавно сильно поссорился с Нокиа - и та послала его  Так о какой продвинутости речь ? или Вы полагаете - то что написано на С++ никогда не тормозит ? 

Добавлено @ 20:37 
По поводу сравнения С# и J2МЕ ,то приложения С# на Windows-смартфонах  (а те имеют процы как минимум OMAP  150 Мgz) работают намного быстрей и стабильней чем аналогичные  Java-проги (Симбиан-смартфоны с близкими процами ) , практически все аспекты написания программ решены в С# удобнее (imho) , возможно нормальное обьектно-ореентированое программирование - даже для графически нагруженых игр. На джаве приходиться писать неудобный ,процедуральный код, что-б обеспечить минимальный фреймрейт. Говорят что скоро появиться имплементация С# для Симбиан-смартов - если имплементация эта будет удачной - есть смысл переходить  полностью на C#.

Это сообщение отредактировал(а) Frog - 20.8.2006, 20:40

Frog, поясни пожалуйста вот этот момент. Что ты имел ввиду?

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

Добавлено @ 16:00 
Но теперь и телефоны получше стали, я сейчас использую огромное кол-во классов, и ничего... пока работает все нормально

Пожалуйста - классическое ООП предполагает использование классов и  наследования , где общие для всех классов методы наследуються от родительского класса . Взаимодействие между обьектами приложения проис ходит путем вызова соответствующих методов  классов , от которых данные обьекты были произведены.  Таким образом код оказываеться поделен на удобные , небольшие части - классы и методы , исключаються повторения кода , возможность утилизации кода в иных приложениях ессесно тоже улучшаеться. Всем известны выгоды и удобство ООП. НО - увы - за все надо платить -
многочисленные обьекты легко фрагментируют память (особенно heap ,без динамичекой аллокации ) ,а их создание порождает огромное количество "мусора" усугубляющего проблему. А главное - обращение к методу обьекта , причем даже к методу принадлежашему данному обьектку (!) занимает ,увы, значительное время ,иногда порядка сотен миллисекунд , что ,если Вы пишете игру ,или графически нагруженое приложение , и вынуждены перерисовывать экран хотя-бы 10-15 раз в секунду - недопустимо много. Причем торможение на вызовах методов совершенно не зависит от типа компайлера JVM (будь он AHEAD или JIT) или свойств самих классов ,будь они ,скажем , static или нет ... Понятно что на мощных девайсах типа 6630 или К700 торможение менее заметно ,однако для коммерческого кода ,расcчитанного на большое число телефонов, применение того самого процедурального кода оказываеться необходимым.
Процедуральным кодом принято называть код прямо описывающий действия программы - то есть , для J2МЕ игры - у нас есть только два класса - MIDlеt (он мал, но не может быть подвергнут обфускации - потому и вынесен), и самой игры - в классе игры все действия игровых персонажей и состояний (меню,плей) описаны последовательно ,управляються switch(aми) и if/else статементами ,причем всячески избегаються не только методы ,но и циклы (тоже жрут немало процессорного времени) - так писали еще на заре компютерной эры  - понятно что код получаеться длинный ,сложный , малопригодный для повторного использования в других играх/приложениях.  Зато сей код предельно быстр, и один раз загрузившись обьектов не плодит и память не фрагментирует.  

Нельзя ,однко, не сказать что практическая невозможность использования чистого ООП - один из самых серьезных недостатков всех ,имеющихся на данный момент времени, реализаций J2ME.

Добавлено @ 16:25 
to WOLF - а get и set методы для переменных Вы используете ? ООП - это целостная система и философия прежде всего , а не то или иное количество классов в приложении.

Это сообщение отредактировал(а) Frog - 21.8.2006, 16:19

Я до этого два года на с++ сидел. ТАк что наверно использую. И не надо тут рассказывать про ООП. Гради Буча наверно все читали. 

У меня есть знакомый, которого кол-во классов никогда не смущало, и он не использовал процедурный код. Он просто написал приложение, которое на уровне байткода ООП превращало в процедурное. И мы использовали ООП в полном его объеме, а при компиляции оно превращалось в 2 класса.

Добавлено @ 17:15 
И вообще, если не нравится j2ME - не надо ее здесь опускать ниже плинтуса

Не следует возводить технологию в ранг фетиша - четкое виденье текущих недостатков J2МЕ не делает ее менее ценной в наших глазах , а позволяет создавать более продвинутые програмные продукты.  
Собрать из ООП кода - процедуральный действительно возможно при использовании препроцессора при компиляции , я однако , предпочитаю писать вручную - для лучшего контроля . 
Рассказывать о путях создания програмного обеспечения ,а так-же обсуждать как общую стратегию так и частности - полагаю необходимым. Тем более что Гради Буча я не читал - до всего доходил своим умом , не без помощи добрых людей на форумах ,конечно. А вот использовать get и set методы для J2МЕ приложений - не рекомендую - это-же не С++  

Это сообщение отредактировал(а) Frog - 21.8.2006, 18:32

Мне кажется что чистота кода и алгоритмизация зависит от конкретного кодера. Можно написать всё в одном классе и потом вызывать методы (аля процедурный подход), а можно разбить на классы и реализовывать всю модель приложения дискретно, вызывая теже get и set без проблем для производительности. Я используювсегда второй подход и никогда бы не сказал что программирую с помощью процедурного подхода. Использую и наследование и интерфейсы (где модель приложения требует какой-то абстракции). Java достатчно ОО язык и не пользовться его приемуществами мне кажется плохо. А что касается производительности, то нужно для каждого устроиства компилить свой код, т.к. метод вызываемый (например) в Нокии будет тормозить в Мотороле (для каждого девайс свой код оптимизации, потому что техническая реализация хоть и похожа, но реализация разная). 
/информация с конференции Sun'a/

Конечно , существует огромное количество приложений в которых нам не требуеться перерисовывать экран телефона >10 раз в секунду , кроме того - для игр - если игра не слишком насыщена графикой , количество и размеры выводимых в кадре картинок не велики - то проблемы оптимизации отходят на второй план - и можно наслаждаться ООП кодингом в полной мере. Проблема в том, уважаемый Javastic , что именно в нагруженых графикой и логикой играх мы начинаем остро чувствовать даже разницу в скорости выполнения циклов - так "for где i++" работает явно медленнее чем "for где i--" - не говоря уж о вызове метода раз во фрейм , или там вложенных циклах - в текущих реализациях J2МЕ мы лишены возможностей ООП программирования именно там где оно нам больше всего нужно - при решении тяжелых ресурсоемких задач  - и это обьективно , и не зависит от вкуса - пока не сольешь все методы в один , и не пораскрываешь циклы - игра будет тормозить. А поскольку Java являеться буквально квинессенцией (эк завернул) ООП , то процедурально с ней работать неудобно и неловко. Таким образом, на мобильных девайсах, преимущества технологии Jаvа фактически сведены к нулю , а иной раз могут быть прямым недостатком (пример - фрагментация heap-memory наплодившимися многочисленными обьектами и завис приложения).

Полагаю ошибочным мнение что с ростом мощности телефонных процессоров проблема несовместимости с ООП снимиться и дальнейшему процветанию J2МЕ уже ничто не помешает- дело в том что высокая мощность позволит использовать еще более простые средства разработки - ту-же Flash Lite ,которая ,кстати ,уже наступает на пятки - в частности меня тревожит отсутствие интереса к J2МЕ у производителей мp3 и мультимедия плееров - многие имеют подходящие экраны ,джойстики , казалось-бы Java-игры (установка с компа) были-б к месту - ан нет - не поддерживают  ( Flash Lite зато поддерживает iRiver U10 - по крайней мере)

Это сообщение отредактировал(а) Frog - 23.8.2006, 02:37