Ага, читал…
Было бы интересно узнать реальную причину случившегося.
У меня была надежда, что в OracleClient в .NET 4 появится поддержка EF — а тут вон оно как.
Obsolete, как правило, помечаются методы (и указывается, какие методы реализованы взамен). Реже — классы. Мы же говорим об абстрактных (примеры, примеры!) технологиях, которые «от версии к версии сворачиваются без необходимости».
Что есть DHTML Editor? Это .NET-приложение?
У нас разговор об отвергнутых Microsoft технологиях в рамках .NET…
А с тем, что некоторые приложения не запускаются под Вистой, спорить глупо :)
Linq2sql был мертворожденным. К моменту его выхода уже была стабильная бета EF и можно было догадаться, какая судьба ждет Linq2Sql.
К слову, Linq2Sql все же поддерживается: например, в .NET 3.5 SP1 была реализована поддержка Sql Server 2008.
Считаю Linq2Sql исключением и в целом не вижу тенденции, описанной teran.
>>В .NET же от версии к версии MS вводит новые технологии отвергающие все что было ранее, зачастую это не необходимо.
Приведите пример .NET-технологий, которые MS свернула без необходимости, на Ваш взгляд, на то.
В чью пользу? В пользу Java? Где-то так и должно быть. А уж если учесть, что значительная часть .NET опенсорсных проектов — порты Java-проектов (как уже было отмечено в комментариях ниже)…
>>Знаю одно — в алгоритм выделения управления памяти для .net встроено знание о том, как сегментами выбирать(Commit, Reserve) память под Windows.
А что это знание дает .NET GC в контексте обсуждаемого нами вопроса?
То есть сойдемся на том, что сборщик мусора в .NET умнее и позволяет обойтись без «рукоприкладства»? :)
Меня, правда, смущает, что я знаю всего 3 настройки .NET'овского сборщика мусора и почти бесконечное их количество Java'вского. Надо будет утречком уточнить этот нюанс на rsdn'е…
Хм… Но ведь живут же как-то .NET-приложения, а в них такие ограничения не задаются (по крайней мере по умолчанию). И не занимаю они все память. И даже если им вдруг захочется занять всю оперативку, Винда ведь не станет отнимать ее у Винампа, IDE и других, она просто отдаст все свободное место (вероятно, вместе со свопом). Но это крайний случай, а в 99.999% случаев такая политика «сколько надо — столько берит» работает замечательно. А для того самого крайнего случая можно и ограничить максимальный объем процесса (полагаю, средства для этого есть).
Неужели в Java нельзя реализовать нечто подобное?
Я понимаю, что я Вас уже достал с этим вопросом… но он мне не дает покоя :)
>>их у Sun Java несколько разных на выбор… ага, лего
Если выбор каждого из них имеет смысл в зависимости от специфики программы, то почему бы и нет. В какой-то степени это можно рассматривать и как конкурентное преимущество перед .NET: не слышал об альтернативных сборщик для CLR (хотя не исключаю, что они и есть).
>>Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
Почему это реализуется только сейчас? О_О Неужели раньше не было такой потребности?
>>XmX задавать нужно, но, например, не нужно задавать:
Не пойму, зачем задавать Xmx, если единственным параметром является размер оперативной памяти (как было сказано выше). Xmx является обязательным параметром?
Как бы там ни было, эти танцы с бубном не красят JVM с точки зрения пользователя (который понятия не имеет, как расширить кучу, perm size и т. д.) Почему нет сбалансированного режима, который заключался бы в следующем:
1. собирал мусор со средней интенсивностью (думаю, в рамках конкретной реализации сборщика мусора это можно сформулировать более формализованно)
2. потреблял память столько, сколько ему нужно.
? Ведь примерно так и ведет себя .NET… и ничего зазорного в этом я не вижу.
Я акцент хотел сделать не на двухгодичной давности, а на том, что внутри используются продукты от Intellidimension. Для меня, например, это значит, что я не стану связываться с этим продуктом Microsoft.
Было бы интересно узнать реальную причину случившегося.
У меня была надежда, что в OracleClient в .NET 4 появится поддержка EF — а тут вон оно как.
Есть такой момент
>>Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
Каким именно API?
Есть такой момент
>>Интересно было бы посмотреть на сравнение производительности при обращений к онтологии средствами API.
Каким именно API?
У нас разговор об отвергнутых Microsoft технологиях в рамках .NET…
А с тем, что некоторые приложения не запускаются под Вистой, спорить глупо :)
К слову, Linq2Sql все же поддерживается: например, в .NET 3.5 SP1 была реализована поддержка Sql Server 2008.
Считаю Linq2Sql исключением и в целом не вижу тенденции, описанной teran.
Приведите пример .NET-технологий, которые MS свернула без необходимости, на Ваш взгляд, на то.
А что это знание дает .NET GC в контексте обсуждаемого нами вопроса?
Меня, правда, смущает, что я знаю всего 3 настройки .NET'овского сборщика мусора и почти бесконечное их количество Java'вского. Надо будет утречком уточнить этот нюанс на rsdn'е…
Неужели в Java нельзя реализовать нечто подобное?
Я понимаю, что я Вас уже достал с этим вопросом… но он мне не дает покоя :)
Если выбор каждого из них имеет смысл в зависимости от специфики программы, то почему бы и нет. В какой-то степени это можно рассматривать и как конкурентное преимущество перед .NET: не слышал об альтернативных сборщик для CLR (хотя не исключаю, что они и есть).
>>Этот GC не делит всю память на New (Eden) / Survivor / Old (Perm), а использует продвинутый алгоритм разбиения кучи на кусочки, который использует единственный параметр — размер оперативной памяти.
Почему это реализуется только сейчас? О_О Неужели раньше не было такой потребности?
>>XmX задавать нужно, но, например, не нужно задавать:
Не пойму, зачем задавать Xmx, если единственным параметром является размер оперативной памяти (как было сказано выше). Xmx является обязательным параметром?
1. собирал мусор со средней интенсивностью (думаю, в рамках конкретной реализации сборщика мусора это можно сформулировать более формализованно)
2. потреблял память столько, сколько ему нужно.
? Ведь примерно так и ведет себя .NET… и ничего зазорного в этом я не вижу.