Java полностью свободна под лицензией GPL

>Вот простейший пример. На яве надо написать кэш чего-нибудь (например картинок, скачанных из инета с помощью Великого Браузера На Чистой Яве -- как он там назывался?). Но проблема в том, что объект (картинка), лежа в кэше, держит на себя активную ссылку, и даже когда все страницы, реально юзающие картинки, закрыты, одна ссылочка-то остается!

Я .уею. Ты проводишь аналогию между URL и объектными ссылками в Java?! OOoo

> Плюсы ужасны, но у них есть перспектива. У явы ее нет.

Я имел в виду что перспектива есть у плюсовой идеологии. У самих плюсов перспективы тоже нет.

> Я .уею. Ты проводишь аналогию между URL и объектными ссылками в Java?! OOoo

Если ты по-русски и коротко не понимаешь, вот тебе по-английски и подробно -- там инженер санок то же самое говорит...

http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html

>> А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации.

> Это называется Smart Pointer, и он выносит мусор, когда он не нужен, а не когда запускается сборщик мусора.

Понимаешь, тут жабщики нас попрекают отстутсвием анализа достижимости и compacting gc, и я соображаю, нельзя ли это тоже сделать...

>А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации.

Прикинь: сановская JVM написана на С++. Посмотри там. Ж))

>> А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации. > Прикинь: сановская JVM написана на С++. Посмотри там. Ж))

Ты или шутишь, или ничего не понимаешь.

> Если ты по-русски и коротко не понимаешь, вот тебе по-английски и подробно -- там инженер санок то же самое говорит...

> http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html

"Ethan Nicholas is the lead engineer for the Yahoo! Publishing Tools team, and was the original author of the Swing-based Yahoo! SiteBuilder web design application. In his spare time he is developing JAXX, an XML-based user interface language for creating Java desktop applications. "

Что-то не вижу что он инженер санок.

Кроме того, мы уже обсудили перспективность применения UnusedReference.

>А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации.

Кури стандарт C++ ANSI/ISO и дедуцируй из него эту невозможность.

Да тут человек предлагает сделать свой собственный С. Наверно это будет C+++ или C$. Вообще, если делать будете, то почитайте для начала про язык D. Очень полезно. (может и отпадёт желание делать свой С).

> Что-то не вижу что он инженер санок.

Я этот вывод сделал исходя из блога на ява.ком и того, что экзаменует ява-девелоперов, вполне возможно что ошибся.

> почитайте для начала про язык D. Очень полезно. (может и отпадёт желание делать свой С).

пока что не отпало. но читать полезно.

>Что-то не вижу что он инженер санок.

Бывшего инженера санок ты уже инженером и не считаешь?

Before I joined Sun, I thought I knew a lot about Java.

( http://weblogs.java.net/blog/enicholas/ )

Кроме того, я подозреваю что написать спецификацию на язык, составить грамматику, реализовать компилятор (ничего задачка, а?), а потом спроектировать и реализовать API к нему у вас просто не хватит сил. Думаете rt.jar весит 12М и это мелочь? это выстраданные 12М не за многие годы. Хотя бы это заслуживает уважение. А ведь нужно сначала всё продумать прежде чем начинать писать спецификацию и грамматику. Нужно также видеть это в связи с будующей API, спецификации на которую у вас не будет к тому моменту. А API в свою очередь будет зависеть от грамматики. Не забудьте также про non-x86, little/big-endian и прочую морочь. Самое большое на мой взгяд вы сможете сделать - написать какой-нить moc-процессор и реализовать какой-то примитивный GC (едва ли надёжный). Хорошо если будет хоть какая-то спека на всё это.

> Но проблема в том, что объект (картинка), лежа в кэше, держит на себя активную ссылку, и даже когда все страницы, реально юзающие картинки, закрыты, одна ссылочка-то остается!

Бред.

Когда из поля зрения программы выйдет сама страница, то она И все на что ссылалась только она (в вашем случае картинка) станет доступно сборщику мусора. Если страниц несколько, то после окончания работы с последней будет убрана и картинка.

WeakReference - совсем для другого варианта. В вашем примере и в большинстве приложений 99% оно нафиг не нужно.

> Но проблема в том, что объект (картинка), лежа в кэше, держит на себя активную ссылку, и даже когда все страницы, реально юзающие картинки, закрыты, одна ссылочка-то остается!

Забыл добавить. Если вы создадите набор объектов и зациклите ссылки, то даже в этом случае GC соберет их (конечно если в основной программе вы их перестали использовать).

WeakReference тут тоже нафиг не нужен.

> Думаете rt.jar весит 12М и это мелочь? это выстраданные 12М не за многие годы.

у меня под линуксом rt.jar это 50 метров, кстати, а не 12

1. библиотеки с языком вообще ничего общего не имеют (хотя язык надо создавать таким, чтобы на нем библиотеки писались легко)

2. явно неявно высказана мысль, что типа там аж столько метров кода почти божественного происхождения... да ничего уникально, коллекции я-ля STL и все обертки к либам в основном, и юзается то в основном совсем не много (ваш пост был -- что реально юзается)

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

4. ну и тащить за собой legacy многих лет

> В каком вопросе разнообразие? Быдлоподсчета быдлоссылок в мейнстримной Яве нет.

За ВСЕХ не скажу, ибо каждый производитель может изващаться по своему.

Правильно, подсчета ссылок в Sun Java - нет.

даже и не пытайтесь копировать

>Плюсы ужасны, но у них есть перспектива. У явы ее нет.

оттянуть (довольно быстрый) полный переход от плюсов к платформам типа .net или java могут IMHO только тулкиты типа qt. но этого не случится ввиду того что сам qt полупорприетарен, других подобных кроссплатформенных тулкитов писать у других фирм/независимых разработчиков желания мало. а если учесть наступление по всем фронтам скриптовых языков, которые и перестают быть просто скриптовыми и обзавозятся своими jit (даже lua), то не только будущее у плюсов под вопросом, оно (их положение) уже сейчас вызывает тревогу.

> Бред.

Отсюда делаю вывод, что ты не только кратко по-русски, но и подробно по-английски не осилил.

> 1. библиотеки с языком вообще ничего общего не имеют (хотя язык надо создавать таким, чтобы на нем библиотеки писались легко)

Я это говорил в контексте языка, совместимого хотя бы с С (С++,Д,...), а не вообще любого.

Да, а вот вы в своей Великой Яве какую библитечку наклепали, которая не имеет С/С++ аналога? (ваши рюшечки вокруг сишных либок не в счет, и офигенно-тяжелые-фреймворки тоже)

Даже если вы такую уникальную и полезную наклепаете -- все равно ее на С/С++ перепишут, ибо там она нужна всем.

>Правильно, подсчета ссылок в Sun Java - нет.

В RTSJ - есть. Но не через смарт-указатели.

ScopedMemory.enter(new Runnable(){
  void run() {
    Entity entity = new Entity(); //Allocated in refcounted memory
    ...
  }
});

>> Бред.

> Отсюда делаю вывод, что ты не только кратко по-русски, но и подробно по-английски не осилил.

Отсюда делаю вывод что вы ничего не поняли из того что я говорил. Можно прекрасно придумать такой жизненный цикл кэша, при котором всякие мягкие ссылки будут не нужны. Например, если вы будете писать этот кэш на сях, то у вас и этой возможности не будет (мягких ссылок). Вы будете ОБЯЗАНЫ продумать жизненный цикл кэша и условие/механизм инвалидации. Так и в яве: вам никто не может запретить делать кэш по-человечкски. Совсем другое дело, что применяя эту мягкую ссылку можно сделать этот кэш за одну минуту не продумывая никой жизненный цикл - вот в чём идея.

> Забыл добавить. Если вы создадите набор объектов и зациклите ссылки,

Перечитай дискуссию. Там про это уже было.

>> Бред.

> Отсюда делаю вывод, что ты не только кратко по-русски, но и подробно по-английски не осилил.

Отвечу более подробно. перечитал http://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html, особено Weak references. Увидел простейший пример кода.

Описания ЗАЧЕМ ЭТО НУЖНО там нет. Применительно к вашему примеру про страницу и картинки это не нужно. Ваш пример прекрасно будет работать на Strong references.

Потому сделал вывод, что WeakReference для данной задачи использовать - "Бред". )))))))

ООО.. вот про RTSJ вы это зря. В RTSJ предусмотрено много всяких придумок, есть даже отсутвие кучи в привычное её понимании, возможность тормознуть GC и пр. В данном случае я имею ввиду именно обычную яву (JavaSE и JavaEE).

>Да, а вот вы в своей Великой Яве какую библитечку наклепали, которая не имеет С/С++ аналога?

thin-драйвер к Ораклу.

>> Забыл добавить. Если вы создадите набор объектов и зациклите ссылки,

> Перечитай дискуссию. Там про это уже было.

Читал с начала, но не помню такого. Можно тынц?

>В данном случае я имею ввиду именно обычную яву (JavaSE и JavaEE).

Обычная Ява c подсчетом ссылок скорее всего не пройдет сановские тесты.

> Перечитай дискуссию. Там про это уже было.

А что там ему перечитывать? я уже говорил об анализе достижимости.. циклические ссылки это фигня. никакие мягкие ссылки для этого не нужны.

> Можно прекрасно придумать такой жизненный цикл кэша, при котором всякие мягкие ссылки будут не нужны.

Ты всерьез думаешь, что полнота по Тьюрингу явы без мягких ссылок будет для меня открытием?

> Совсем другое дело, что применяя эту мягкую ссылку можно сделать этот кэш за одну минуту не продумывая никой жизненный цикл - вот в чём идея.

Вот просветил... как бы я жил без таких гуру?

> Я в сане работаю недавно, но знаю уже несколько хороших уважаемых инженеров. Они не используют эти референсы именно потому что у них не возникала в этом необходимость.

Как можно с тобой связаться ? сам я работаю рядом - можно замутить бизнес-ланч, пообщаться по технологиям обмену опытом и т.п. ;)

>На самом деле игры на Java пишут (для мобильников, например). Но это такой кошмар, когда эмулируют с помощью ООП структурно-ориентированный подход и даже Фортран — якобы для того, "штобы не тормозило". И ведь, действительно, такие проги не тормозят!!! :) И это считается хорошим тоном у геймдевелоперов.

>Во што они превращают ООП в своих поделиях? В МЯСО, которое "разбрасывается" кусками там и сям (благо, что размер кода не переваливает аз несколько тысяч строк — можно обозреть одному программисту за несколько дней). А ну как в обычных девайсах отменят ограничение на размер JAR, что тогда? Будет полная ЗА..ЦА! Геймдевелоперы-мобильщики не эволюционировали дальше примитивных объектов-представлений персонажей и канвы, которые используются исключительно в стиле автоматного управления.

Ну так и Вы еще удивляетесь, что они не хотят мучаться с жавой еще и на ПК?

>Вот в чём преимущества — в ОДНОЗНАЧНОСТИ порождаемого кода. Ну а JIT можно и подкручивать так же, как и GCC, но пусть это делают системщики, которые ЛУЧШЕ разбираются в архитектуре конкретного процессора — оставьте оптимизации прикладного кода прикладникам, системного кода — системщикам. Так будет лучше, так будет Unix-wayнее.

Ой ну только не нужно жаву юних-веем называть, я Вас умоляю.

>Сколько ещё это будет продолжатся? Хотя результаты на лицо. Некоторые жабокодеры уже стали сомневаться в троекратном превосходстве Java над Си, как им благополучно наврали сановцы.

Значит флейм прошел не зря :)

> Вот просветил... как бы я жил без таких гуру?

Да потому что вы упёрлись в этот несчастный кэш и говорите что вот мол, не проживёте вы без UnusedReference и ссылаетесь на блог сантехника, что вот мол и он говорит что никак нельзя прожить и это мол так все советуют делать.

>А какие компиляторы + "среды исполнения" поддерживают C99 и С++98?

>PS я пришу "среда исполнения" в ковычках потому что это не термин, а понятие ))) Или как можно более правильно охарактеризовать необходимый для запуска набор предусловий типа ядерный АПИ + наличие библиотек и т.п ?!?

GCC + POSIX.

>Они элегантны и качественны. И код их использующий тоже красив.

Красивый императивный код?! ПОКАЖИТЕ!

> > Я в сане работаю недавно, но знаю уже несколько хороших уважаемых инженеров. Они не используют эти референсы именно потому что у них не возникала в этом необходимость.

> Как можно с тобой связаться ? сам я работаю рядом - можно замутить бизнес-ланч, пообщаться по технологиям обмену опытом и т.п. ;) VoDA (*) (23.06.2008 16:17:07)

Хорошо. Я в питере работаю. Можете мне написать на мыло: Sergey /dot/ Mashkov {at} Sun.COM.

>Чудо Инженерной Мысли Эклипс, которое ява-фаны часто приводят как Показательный Пример Того Что Без Божественной Явы И На Другом Языке Не Написать, использует софт референсы.

Кстати от Эклипса польза есть. Лучше уж я буду писать в WindRiver Workbench на его основе, чем в Tornado... Проприетарщики упорно не хотят реализовывать это на Эмаксе...

>оттянуть (довольно быстрый) полный переход от плюсов к платформам типа .net или java могут IMHO только тулкиты типа qt. но этого не случится ввиду того что сам qt полупорприетарен, других подобных кроссплатформенных тулкитов писать у других фирм/независимых разработчиков желания мало. а если учесть наступление по всем фронтам скриптовых языков, которые и перестают быть просто скриптовыми и обзавозятся своими jit (даже lua), то не только будущее у плюсов под вопросом, оно (их положение) уже сейчас вызывает тревогу.

Вы с ума сошли? Никто не будет весь этот легаси код на всяких жабах переписывать ближайшие годы. Да и если Вы обратили внимание МС не очень спешит новые версии своих програмных продуктов на точкаНЕТ писать. Видимо понимают, что Виста+Офис+Ишак+ВС только на кластерах тогда можно будет запускать...

>Потому сделал вывод, что WeakReference для данной задачи использовать - "Бред". )))))))

да....

This makes them an excellent foundation for a cache, such as the image cache described above, since you can let the garbage collector worry about both how reachable the objects are (a strongly reachable object will never be removed from the cache) and how badly it needs the memory they are consuming.

>> В данном случае я имею ввиду именно обычную яву (JavaSE и JavaEE).

> Обычная Ява c подсчетом ссылок скорее всего не пройдет сановские тесты.

Ты бы хоть аргументировал как-то...

http://www.linux.org.ru/jump-message.jsp?msgid=2856573&cid=2866109

>>> В данном случае я имею ввиду именно обычную яву (JavaSE и JavaEE).

>> Обычная Ява c подсчетом ссылок скорее всего не пройдет сановские тесты.

>Ты бы хоть аргументировал как-то...

Что тут аргументировать - поведение программ будет совсем другое. Если вкратце, память будет течь рекой из-за циклических ссылок.

Да, тесты не пройдёт. Есть тесты на утечки памяти.

> Обычная Ява c подсчетом ссылок

Правда я не знаю где такую найти? думаю даже gcj и тот не использует такой убогий алгоритм.

>Если ты дашь ссылки на бенчмарки, то обязательно прочту.

На, читай http://www.linux.org.ru/view-message.jsp?msgid=1813576 http://www.ibm.com/developerworks/library/j-jtp12214/ http://www.ryanlowe.ca/blog/archives/000447_java_microbenchmarks_are_evil.php http://www.ece.cmu.edu/~ece749/docs/acmCompSurveyHighPerfJava.pdf http://www.jroller.com/ff/date/20050603#lies_damn_lies http://www.javalobby.org/java/forums/t18985.html?start=15 http://osdir.com/ml/lang.smalltalk.croquet.devel/2007-03/msg00006.html

>>Если ты дашь ссылки на бенчмарки, то обязательно прочту.

>На, читай http://www.linux.org.ru/view-message.jsp?msgid=1813576 --> http://java.sun.com/jsp_utils/PrintPage.jsp?url=http%3A%2F%2Fjava.sun.com%2Fd...

Ни одного бенчмарка не нашел -- читать не буду. Переходим к следующей...

>>>Если ты дашь ссылки на бенчмарки, то обязательно прочту.

>>На, читай http://www.linux.org.ru/view-message.jsp?msgid=1813576 --> http://java.sun.com/jsp_utils/PrintPage.jsp?url=http%3A%2F%2Fjava.sun.com%2Fd.. .

>Ни одного бенчмарка не нашел -- читать не буду. Переходим к следующей...

Вот это номер.. тут написано совсем не то же самое, что в статье на java.sun.com...