На этом форуме часто читаю, что на десктопах win Java хуже, чем C#.
А чем хуже-то. Конечно, все зависит от задачи.
Ну давайте предложу довольно стандартную задачку написания интерфейса
к базе данных на: Access, MS SQL 2000, DB2. Насколько я понимаю
для клиента это не столь важно.
От себя могу сказать, что наиболее просто такие дела пишутся на Access.
Но при усложнении алгоритмов получения/записи данных преимущества
Access wizards нивелируются а затем Access начинает вообще проигрывать
даже в сравнении с родственным ему VB. А что же Java?
Здравствуйте, Titus, Вы писали:
T>На этом форуме часто читаю, что на десктопах win Java хуже, чем C#.
А оба хороши, памяти жрут неимоверно. Просто сложилось мнение, что интерфейс написанный на С# выглядит лучше, чем на Java. На самом деле он просто выглядит стандартно. А мне вот например IntllliJ и WebLogic Workshop нравятся — красивый GUI.
Здравствуйте, Mishka, Вы писали:
T>>На этом форуме часто читаю, что на десктопах win Java хуже, чем C#.
M>А оба хороши, памяти жрут неимоверно. Просто сложилось мнение, что интерфейс написанный на С# выглядит лучше, чем на Java. На самом деле он просто выглядит стандартно. А мне вот например IntllliJ и WebLogic Workshop нравятся — красивый GUI.
Ну если руки оттуда растут то красивый GUI можно сделать на чем угодно.
Проблема в том, что на WinForms с дизайнером в VS можно сделать нормальный GUI гораздо быстрее, чем на Swing.
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, Titus, Вы писали:
T>>На этом форуме часто читаю, что на десктопах win Java хуже, чем C#.
M>А оба хороши, памяти жрут неимоверно. Просто сложилось мнение, что интерфейс написанный на С# выглядит лучше, чем на Java. На самом деле он просто выглядит стандартно. А мне вот например IntllliJ и WebLogic Workshop нравятся — красивый GUI.
На самом деле, в Swing (GUI библиотека для Java) предусмотрена смена Look&Feel (аналог скинов). Соответственно, если выставить скин как Win32 под JRE 1.3, то приложение выглядит почти как родное. Если сделать то же под JRE 1.4, то похожесть еще сильнее усилится. IntelliJ Idea использует другой скин, видимо, ради кросс-платформенности внешнего вида .
Здравствуйте, Titus, Вы писали:
T>На этом форуме часто читаю, что на десктопах win Java хуже, чем C#. T>А чем хуже-то. Конечно, все зависит от задачи. T>Ну давайте предложу довольно стандартную задачку написания интерфейса T>к базе данных на: Access, MS SQL 2000, DB2. Насколько я понимаю T>для клиента это не столь важно. T>От себя могу сказать, что наиболее просто такие дела пишутся на Access. T>Но при усложнении алгоритмов получения/записи данных преимущества T>Access wizards нивелируются а затем Access начинает вообще проигрывать T>даже в сравнении с родственным ему VB. А что же Java?
Во-первых, ява теоретически должна работать медленнее, чем C#, т.к. она работает в сановской виртуальной машине, а C# — в родной микрософтовской. Так что по идее должна быть некоторая разница в скорости.
Во-вторых (а скорее во-первых), дистрибутив каждого ява-приложение должен будет включать в себя JRE , что немаловажно для десктопного приложения. Либо будут некие сложности с настройкой (если ставить JRE отдельно).
А .Net Framework, как опять-таки родная для винде штука, устанавливается один раз на все приложения.
В общем, для простых пользователей приложения, написанные на C# удобнее.
Здравствуйте, Cider, Вы писали: C>Во-первых, ява теоретически должна работать медленнее, чем C#, т.к. она работает в сановской виртуальной машине, а C# — в родной микрософтовской. Так что по идее должна быть некоторая разница в скорости.
А логично-ли будет предположить, что С# будет работать медленнее на солярисе, т.к. .НЕТ будет работать в микросовтовской машине, а ява — в родной, сановской ))
Но на самом-то деле, это безразлично. Микрософт виртуальную машину для Явы не пишет! А САН в свою очередь заботиться о скорости работы C>Во-вторых (а скорее во-первых), дистрибутив каждого ява-приложение должен будет включать в себя JRE , что немаловажно для десктопного приложения. Либо будут некие сложности с настройкой (если ставить JRE отдельно).
Вообще-то, для .НЕТ наличие вреймворка тоже обязательно!! Так что немаловажно что .НЕТ приложение должно будет включать в себя .НЕТ вреймворк. Либо будут некоторые сложности с его работой.. если ставить его отдельно C>А .Net Framework, как опять-таки родная для винде штука, устанавливается один раз на все приложения. C>В общем, для простых пользователей приложения, написанные на C# удобнее.
А Ява-таки не менее родная штука, как и любая устанавливаемая на мастдай программулина. Поэтому приложение написанное на яве ничем не хуже и не лучше написанного на C# (при прочих равных)
И все бладко пока существует только "первая" версия фреймворка, а потом ведь и будут следующие!??...
C>Cider
ЗАО "Чих-Пых"
ЗЫ: Я только хотел обратить твое внимаение на "однобокое" рассмотрение вопроса. Это вообще вопрос личного предпочтения. Но я в свое время выбрал для себя яву, хотя бы по той причине, что на ней можно писать всякие штучки на юниксе, которые нужны мне в повседневной работе как администратору.
Стоп-стоп... отвечу всем свои мысли после первого знакомства со свингом джавы.
Первое, как правильно заметил mikkri > На самом деле, в Swing (GUI библиотека для Java) предусмотрена смена Look&Feel
второе, свинговая модель мне понравилась уже тем, что не надо писать обработчики
на отрисовку компонент при изменении размера окна. Что ни говори, а в Layout manager
есть своя изюминка. > C# — в родной микрософтовской
Насколько мне известно, дот.нет не присутствует в дистрибутивах операционных систем.
Так что родной не родной — не важно, важно, чтобы не глючило. У меня на win 2000 с JRE пока
ярко выраженных глюков не было, хотя сборщик мусора работает на редкость не эффективно. >А .Net Framework, как опять-таки родная для винде штука, устанавливается один раз на все приложения.
JRE хоть и не родная, но ... абсолютно такая же ботва
Есть еще какие-нибудь аргументы?
Здравствуйте, CMEX_, Вы писали:
CME>А логично-ли будет предположить, что С# будет работать медленнее на солярисе, т.к. .НЕТ будет работать в микросовтовской машине, а ява — в родной, сановской )) CME>Но на самом-то деле, это безразлично. Микрософт виртуальную машину для Явы не пишет! А САН в свою очередь заботиться о скорости работы
Щас специально набросал маленький тестик: создается 1000000 простеньких объектов и провоятся чуть-чуть вычислений...
Java — 44665 mиллисекунд.
C# — 4.9071540 секунд
Разница — на порядок. Могу дать сорцы, благо они маленькие
Разумеется этот тест не является репрезентативным, но в какой-то степени отражает тенденцию.
CME>Вообще-то, для .НЕТ наличие вреймворка тоже обязательно!! Так что немаловажно что .НЕТ приложение должно будет включать в себя .НЕТ вреймворк. Либо будут некоторые сложности с его работой.. если ставить его отдельно
Тем не менее, практически любое ява приложение, не предназначенное для установки специальными админами, поставляется вместе с JRE — так меньше геморроя при установке.
CME>А Ява-таки не менее родная штука, как и любая устанавливаемая на мастдай программулина. Поэтому приложение написанное на яве ничем не хуже и не лучше написанного на C# (при прочих равных) CME>И все бладко пока существует только "первая" версия фреймворка, а потом ведь и будут следующие!??...
Фреймворк существует уже в 2-х версиях (1.0 и 1.1)... Так что у дотнетовцов есть свой геморрой
CME>ЗЫ: Я только хотел обратить твое внимаение на "однобокое" рассмотрение вопроса. Это вообще вопрос личного предпочтения. Но я в свое время выбрал для себя яву, хотя бы по той причине, что на ней можно писать всякие штучки на юниксе, которые нужны мне в повседневной работе как администратору.
Разумеется, все сказанное — IMHO, но безумно извиняясь за переход на личности, если ты юниксовый админ, то вряд ли тебя можно назвать простым пользователем
Я могу на своем компе сконфигурять практически любое ява-приложение (ну, почти ), но десктопные приложения по идее, нужные простым юзерам, которые не будут ковыряться с classpath, ставить разные версии JRE под разные продукты и радостно конфигурять все это из командной строки.
Здравствуйте, Cider, Вы писали:
C>Я могу на своем компе сконфигурять практически любое ява-приложение (ну, почти ), но десктопные приложения по идее, нужные простым юзерам, которые не будут ковыряться с classpath, ставить разные версии JRE под разные продукты и радостно конфигурять все это из командной строки.
Вот интересный вопрос. .NET ставится так, что одновременно несколько версий иметь нельзя (или я не прав?). А как быть пользователям, которые хотят разные приложения запускать под разными версиями .NET ???
Sun пошла другим путем. Она ставит так, что JRE может быть поставлено несколько раз. Сложнее, но проблема с версиями стоит не так жестко.
Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, Cider, Вы писали:
C>>Я могу на своем компе сконфигурять практически любое ява-приложение (ну, почти ), но десктопные приложения по идее, нужные простым юзерам, которые не будут ковыряться с classpath, ставить разные версии JRE под разные продукты и радостно конфигурять все это из командной строки.
M>Вот интересный вопрос. .NET ставится так, что одновременно несколько версий иметь нельзя (или я не прав?). А как быть пользователям, которые хотят разные приложения запускать под разными версиями .NET ???
M>Sun пошла другим путем. Она ставит так, что JRE может быть поставлено несколько раз. Сложнее, но проблема с версиями стоит не так жестко.
Сложнее ??? Интересно чем... Вот у меня, так уж получилось, что на компе 3 версии JRE:
Oracle с собой ставит
IDEA с собой ставит
Сам поставил J2SDK 1.4.2
И ничего сложного тут не вижу... а вот .NET не поставиться так... он только один... и не понятно как быть ?
Я знаю только то, что я ничего не знаю (c) Сократ
Re: Мы отвлеклись от темы ;) Первоначально вопрос был следую
Здравствуйте, Titus, Вы писали:
T>На этом форуме часто читаю, что на десктопах win Java хуже, чем C#. T>Ну давайте предложу довольно стандартную задачку написания интерфейса T>к базе данных на: Access, MS SQL 2000, DB2. Насколько я понимаю T>для клиента это не столь важно. T>От себя могу сказать, что наиболее просто такие дела пишутся на Access. T>Но при усложнении алгоритмов получения/записи данных преимущества T>Access wizards нивелируются а затем Access начинает вообще проигрывать T>даже в сравнении с родственным ему VB. А что же Java?
Если говорить только о интерфейсе к Акцесс базе, то на Яве сделать конечно можно, но возможно не совсем логично. Но если в сроках не ограничен, то лучше ява, по причине ее "универсальности".
Что-бы чем-то овладеть нужно этим заниматься постоянно Поэтому лучше не распыляться и выбрать что-нибудь "надолго"
А выбирать нужно межу C# и Java. Я IMHO в свое время выбрал Java.
Здравствуйте, arTik, Вы писали:
T>Здравствуйте, mikkri, Вы писали:
M>>Здравствуйте, Cider, Вы писали:
C>>>Я могу на своем компе сконфигурять практически любое ява-приложение (ну, почти ), но десктопные приложения по идее, нужные простым юзерам, которые не будут ковыряться с classpath, ставить разные версии JRE под разные продукты и радостно конфигурять все это из командной строки.
M>>Вот интересный вопрос. .NET ставится так, что одновременно несколько версий иметь нельзя (или я не прав?). А как быть пользователям, которые хотят разные приложения запускать под разными версиями .NET ???
M>>Sun пошла другим путем. Она ставит так, что JRE может быть поставлено несколько раз. Сложнее, но проблема с версиями стоит не так жестко.
T>Сложнее ??? Интересно чем... Вот у меня, так уж получилось, что на компе 3 версии JRE: T>Oracle с собой ставит T>IDEA с собой ставит T>Сам поставил J2SDK 1.4.2
T>И ничего сложного тут не вижу... а вот .NET не поставиться так... он только один... и не понятно как быть ?
Вы хоть про .NET читали кроме как в Java форуме?
1/ В ОС .NET Server входит FrameWork .NET
2/ На одной машине может стоять от 1 до N, где N > 1 версий FrameWork .NET
3/ Приложение написаное на версии N может работать на версии M, где M > N, а N >= 1.0
4/ Некоторые классы из FrameWork .NET работают шустрее их аналогов из JRE, а некоторые наоборот. А некооторых нету
5/ Я вот например портировал JavaCC и честно сказать, JavaCC скомпиленый на J# работет немного быстрее чем родной.
6/ У Java свои заморочки, а у .NET свои. И не надо эти заморочки сравнивать.
Здравствуйте, arTik, Вы писали:
M>>Sun пошла другим путем. Она ставит так, что JRE может быть поставлено несколько раз. Сложнее, но проблема с версиями стоит не так жестко.
T>Сложнее ??? Интересно чем... Вот у меня, так уж получилось, что на компе 3 версии JRE: T>Oracle с собой ставит T>IDEA с собой ставит T>Сам поставил J2SDK 1.4.2
T>И ничего сложного тут не вижу... а вот .NET не поставиться так... он только один... и не понятно как быть ?
Сложнее хотя бы тем, что их несколько, а значит и администрировать в случае чего нужно несколько виртуальных машин. А если выяснится, что какую-нибудь из них нужно пропатчить (вроде как нетипичная ситуация, к счастью)? Однозначно, чем больше софта/компонент/библиотек, тем сложнее система. В том числе, сложнее в эксплуатации при прочих "равных" условиях.
Здравствуйте, V.Petrovski, Вы писали:
VP>2/ На одной машине может стоять от 1 до N, где N > 1 версий FrameWork .NET
Как, если вкратце?
VP>3/ Приложение написаное на версии N может работать на версии M, где M > N, а N >= 1.0
Наличие depricated методов в 1.1 свидетельствует, что скоро будут проблемы с обратной совместимостью. А учитывая то, что даже под разными Win32 не все приложения работают одинаково, полной уверености лично у меня нет и не будет ближайшие несколько лет.
C>Щас специально набросал маленький тестик: создается 1000000 простеньких объектов и провоятся чуть-чуть вычислений... C>Java — 44665 mиллисекунд. C>C# — 4.9071540 секунд C>Разница — на порядок. C>Могу дать сорцы, благо они маленькие
В студию. Есть ощущение, что считается время подъема JVM.
Во время оно я немного занимался тестированием производительности. На тестах создания объектов и вычислениях .NET 1.0 была шустрее Sun JRE, но не на порядок. IBM JRE 1.3.1 был пошустрее .NET. Просад возможен в основном на I/O операциях.
C>Разумеется этот тест не является репрезентативным, но в какой-то степени отражает тенденцию.
"Это все неправда, но что-то в этом есть", ага.
Здравствуйте, mikkri, Вы писали:
M>Здравствуйте, V.Petrovski, Вы писали:
VP>>2/ На одной машине может стоять от 1 до N, где N > 1 версий FrameWork .NET
M>Как, если вкратце?
Да очень просто.
При установки FrameWork .NET он прописывает свою версию в реестер типа
C:\Windows\.NetFrameWork\1.0.3705 — это старая версия
C:\Windows\.NetFrameWork\1.1.4322 — это новая версия
и для програмы написаной на старой версии можно прописать в конфиг файле использовать новый .NetFrameWork
если стоят оба, если стоит один то он использйется всегда
VP>>3/ Приложение написаное на версии N может работать на версии M, где M > N, а N >= 1.0
M>Наличие depricated методов в 1.1 свидетельствует,
В .NET их называют disposed
И в C# есть понятие дерективы предкомпиляции
int i = 0;
#if Ver103705
i = DisposedMethod();
#elif Ver114322
i = NewMethod();
#endif
M> что скоро будут проблемы с обратной совместимостью. M>А учитывая то, что даже под разными Win32 не все приложения работают одинаково, полной уверености лично у меня нет и не будет ближайшие M> несколько лет.
А это в стиле MC, она то свои старые ОС не поддерживает, если не ошибаюсь поддержка ведется последних (двух)трех продуктов в линейке.
... << RSDN@Home 1.1 beta 1 U2 — In a little while>>
Здравствуйте, mikkri, Вы писали:
VP>>2/ На одной машине может стоять от 1 до N, где N > 1 версий FrameWork .NET M>Как, если вкратце?
Вкратце — берёшь и ставишь новую версию, и она будет спокойно жить с предыдущими. Проверено
VP>>3/ Приложение написаное на версии N может работать на версии M, где M > N, а N >= 1.0 M>Наличие depricated методов в 1.1 свидетельствует, что скоро будут проблемы с обратной совместимостью. А учитывая то, что даже под разными Win32 не все приложения работают одинаково, полной уверености лично у меня нет и не будет ближайшие несколько лет.
Тут есть одна специфическая фича .NET, которая спасёт Microsoft — на runtime приложение может работать сразу с несколькими версиями framework, в конкретнее — каждая сборка будет работать с той версией, под которую она компилировалась. Представь, что у тебя есть класс, работающий под JRE 1.2, а другой под JRE 1.4. Было бы неплохо, чтоб они на runtime работали в с разными JRE, правда?
Здравствуйте, Mishka, Вы писали:
M>Тут есть одна специфическая фича .NET, которая спасёт Microsoft — на runtime приложение может работать сразу с несколькими версиями framework, в конкретнее — каждая сборка будет работать с той версией, под которую она компилировалась. Представь, что у тебя есть класс, работающий под JRE 1.2, а другой под JRE 1.4. Было бы неплохо, чтоб они на runtime работали в с разными JRE, правда?
Вот это интересная фича. Сам используешь одну JRE, библиотеки запускаешь под другими... Вот только обмен между двумя JRE, скорее всего, убьет производительность.
Как с этим в .NET?
Здравствуйте, nant, Вы писали:
N>В студию. Есть ощущение, что считается время подъема JVM.
JVM запускается один раз, как и фреймворк. N>Во время оно я немного занимался тестированием производительности. На тестах создания объектов и вычислениях .NET 1.0 была шустрее Sun JRE, но не на порядок. IBM JRE 1.3.1 был пошустрее .NET. Просад возможен в основном на I/O операциях.
В данном случае происходит в основном создание объектов.
Вот код, если кто хочет проверить (не доверяете ? ):
Java:
public class Benchmark {
static long counter = 0;
long i;
double d;
String s;
public Benchmark(long i, double d)
{
this.i = i;
this.d = d;
counter++;
}
public static void main(String[] args)
{
long before = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++)
{
Benchmark c = new Benchmark(i, 1f / i);
c.calculate();
}
long after = System.currentTimeMillis();
System.out.println(after - before);
}
public void calculate()
{
s = "" + i * counter + d;
}
}
C#
class Class1
{
static long counter = 0;
long i;
double d;
String s;
public Class1(long i, double d)
{
this.i = i;
this.d = d;
counter++;
}
static void Main(string[] args)
{
DateTime before = DateTime.Now;
for (int i = 0; i < 1000000; i++)
{
Class1 c = new Class1(i, 1f / i);
c.calculate();
}
DateTime after = DateTime.Now;
Console.Out.WriteLine(after.Subtract(before));
}
public void calculate()
{
s = "" + i * counter + d;
}
}
N>"Это все неправда, но что-то в этом есть", ага.
Это не неправда, а реальные результаты... к сожалению, так как мне ява нравится больше, чем С#.
Я читал статью, в которой сравнивалась производительность Java и .NET. В ней было выявлено, что точность работы с плавающей точкой в .NET специально понижена, по сравнению с Java и C++ (каким не помню, GNU, наверное). Попробуй убрать дробные числа из теста, что выйдет?
.
)) 
), но десктопные приложения по идее, нужные простым юзерам, которые не будут ковыряться с classpath, ставить разные версии JRE под разные продукты и радостно конфигурять все это из командной строки.
