The Java language does not offer any way to explicitly allocate an object on the stack, but this fact doesn't prevent JVMs from still using stack allocation where appropriate. JVMs can use a technique called escape analysis, by which they can tell that certain objects remain confined to a single thread for their entire lifetime, and that lifetime is bounded by the lifetime of a given stack frame. Such objects can be safely allocated on the stack instead of the heap. Even better, for small objects, the JVM can optimize away the allocation entirely and simply hoist the object's fields into registers.
Иными словами, если JVM просекает, что в данном конкретном участке кода класс можно без последствий, грубо говоря, заменить структурой (для большей производительности) то это делается автоматически в runtime, без участия программиста.
> 3. Про дженерики и структуры вы сильно ошибаетесь.
Можно подробнее, в чем моя ошибка?
Зачем я должен ломать голову, что мне писать, структуру или класс, неужели компилятор за меня не может правильно оптимизировать в runtime? Видимо, не может, вот и переложили дизайнеры языка проблему со своей головы на голову конечного разработчика.
>4. TFS, а что?
Так это ж вроде Continuous integration, или конечный дистрибутив — тоже им?
>1. Так на десктопе все-таки отстает? С учетом распространения винды.
Не берусь судить, т.к. использую в равной степени мало как .Net так и Java-прог. Возможно, и да. Имхо, на десктопе обе платформы по-прежнему проигрывают старому доброму C++.
>3. Т. е. нормальные дженерики и лямбды не нужны? А зачем их тогда вообще к джаве стали прикручивать?
«Нормальные» обобщения — довольно спорный момент. Выгод для программиста они принесут реально мало, т.к. то, что они позволяют (пока приходит в голову new T()) сделает код менее понятным, при этом накладные расходы в runtime, понятно, возрастут.
Лямбды, видимо, нужны. А вот делегаты, структуры, невиртуальные методы, свойства — точно не нужны.
>npanday и nant
Кстати, хорошо что Вы их упомянули. Забавно, что эти проекты, как и NHibernate, NLucene, iText.NET, NPOI, Spring.NET,… (продолжите сами) — поклассовые порты именно с их Java-прародителей.
>4. Не смешно ;) Даже если не учитывать npanday и nant, дотнет остается энтерпрайзной платформой для которой, конечно же, полно решений для continuous delivery начиная от TFS.
Вот ради интереса, чем Вы собираете свой текущий .Net проект?
>но для оценки отставания достаточно запустить рядом два приложения — одно на WPF, другое на Swing.
А если попробовать запустить то же самое на linux/mac то, что-то мне подсказывает, что сравнение будет не в пользу .Net.
Не говоря уже о том, что десктоп — не основной козырь явы.
> отзывчивости и производительности
Признаться, особо не использовал прог с .Net интерфейсом, но то что использовал (Toad for MySQL & Sql Server Management Studio одну из последних) показалось очень неторопливым в плане отзывчивости. Особенно это было заметно после перехода с оснастки управления SQL Server 2000.
>Про язык думаю спорить не будете?
Вообще-то очень даже и могу. Имхо, многое, чем так похваляются C#-щики именно что не нужно.
>так уже пишу именно на C#, так как он сильно продуктивней.
А в чем выражается эта продуктивность? В том, что Visual Studio помогает писать код? Ну так и у Java'ы есть IntelliJ Idea. А вот есть ли у вас аналог maven'а или хотя бы захудалый ant?
И в чем же отстаёт? Почему Вы уверены, что все то что есть в C# так нужно яве, и вообще так уж нужно? А может быть некоторые вещи вовсе даже и не полезны?
>то платформа отстанет окончательно
Платформа != язык. А Java сильна именно платформой (виртуальная машина, стандарты, библиотеки), которая и не думала отставать.
Угу, но все имеет свою меру, и тут как раз речь об этой самой мере.
И потом, по закону умолчаний, большинство людей будут использовать именно дефолтное поведение, и лишь считанные единицы будут использовать более правильное поведение. В пхп поведение по умолчанию — неявное приведение типов.
Хм… По-поводу документации: всегда всё находилось в Python Manuals .chm-ке, поставляемой в комплекте с дистрибом (правда, под Win). Там же и поиск есть — можно сразу найти нужную функцию.
Забавно, что православная ява получила полную поддержку Unicode, включая поддержку ввода на японском, китайском и корейском языках в далеком 1998 году.
Угу, именно против этого и взбунтовался Sun, т.к. основная идея явы «Write once — run anywhere». А MS идеологически не могла развивать то, на что не могла повлиять в той мере, в которой ей того хотелось, а идеально — завладеть.
А Java может (http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html):
Иными словами, если JVM просекает, что в данном конкретном участке кода класс можно без последствий, грубо говоря, заменить структурой (для большей производительности) то это делается автоматически в runtime, без участия программиста.
Можно подробнее, в чем моя ошибка?
Зачем я должен ломать голову, что мне писать, структуру или класс, неужели компилятор за меня не может правильно оптимизировать в runtime? Видимо, не может, вот и переложили дизайнеры языка проблему со своей головы на голову конечного разработчика.
>4. TFS, а что?
Так это ж вроде Continuous integration, или конечный дистрибутив — тоже им?
Не берусь судить, т.к. использую в равной степени мало как .Net так и Java-прог. Возможно, и да. Имхо, на десктопе обе платформы по-прежнему проигрывают старому доброму C++.
>3. Т. е. нормальные дженерики и лямбды не нужны? А зачем их тогда вообще к джаве стали прикручивать?
«Нормальные» обобщения — довольно спорный момент. Выгод для программиста они принесут реально мало, т.к. то, что они позволяют (пока приходит в голову new T()) сделает код менее понятным, при этом накладные расходы в runtime, понятно, возрастут.
Лямбды, видимо, нужны. А вот делегаты, структуры, невиртуальные методы, свойства — точно не нужны.
>npanday и nant
Кстати, хорошо что Вы их упомянули. Забавно, что эти проекты, как и NHibernate, NLucene, iText.NET, NPOI, Spring.NET,… (продолжите сами) — поклассовые порты именно с их Java-прародителей.
>4. Не смешно ;) Даже если не учитывать npanday и nant, дотнет остается энтерпрайзной платформой для которой, конечно же, полно решений для continuous delivery начиная от TFS.
Вот ради интереса, чем Вы собираете свой текущий .Net проект?
А если попробовать запустить то же самое на linux/mac то, что-то мне подсказывает, что сравнение будет не в пользу .Net.
Не говоря уже о том, что десктоп — не основной козырь явы.
> отзывчивости и производительности
Признаться, особо не использовал прог с .Net интерфейсом, но то что использовал (Toad for MySQL & Sql Server Management Studio одну из последних) показалось очень неторопливым в плане отзывчивости. Особенно это было заметно после перехода с оснастки управления SQL Server 2000.
>Про язык думаю спорить не будете?
Вообще-то очень даже и могу. Имхо, многое, чем так похваляются C#-щики именно что не нужно.
>так уже пишу именно на C#, так как он сильно продуктивней.
А в чем выражается эта продуктивность? В том, что Visual Studio помогает писать код? Ну так и у Java'ы есть IntelliJ Idea. А вот есть ли у вас аналог maven'а или хотя бы захудалый ant?
И в чем же отстаёт? Почему Вы уверены, что все то что есть в C# так нужно яве, и вообще так уж нужно? А может быть некоторые вещи вовсе даже и не полезны?
>то платформа отстанет окончательно
Платформа != язык. А Java сильна именно платформой (виртуальная машина, стандарты, библиотеки), которая и не думала отставать.
И потом, по закону умолчаний, большинство людей будут использовать именно дефолтное поведение, и лишь считанные единицы будут использовать более правильное поведение. В пхп поведение по умолчанию — неявное приведение типов.
а юникод сделать не могут…
Забавно, что православная ява получила полную поддержку Unicode, включая поддержку ввода на японском, китайском и корейском языках в далеком 1998 году.
И удобнее на порядок и кроссплатформенно.
Synonym