www.assembla.com/ — очень рекомендую. Есть SVN, тикеты, вики, место под файлы, почтовая рассылка, форум и чат. Для ведения не шибко крупных проектов — почти идеально.
Интересная идея. Основной минус — либо такой генератор будет довольно медленным (процессору придется обратиться к весьма небыстрому внешнему устройству), либо процессор должен заранее запасать данные со звуковой карты и постоянно держать их «на готове».
То что систему при переполнении стека «уже не спасти» — это и так понятно. Я говорил о том, что вполне возможно организовать какие-то действия, которые будут предприняты перед падением ядра (своего рода «завещание») — вывод сообщения, сохранение дампа памяти и т. д. То есть это всё вполне делается. Мой предыдущий комментарий — мое несогласие с тем, что якобы нельзя делать то, что выше предложил stolen.
Подсчитать сколько нам нужно памяти в стеке для того, чтобы вывести сообщение об ошибке и опустить планку допустимого размера стека на соответствующую величину (т.е. всегда оставлять небольшой запас для сообщения о том, что стек кончился).
Боюсь склонен согласиться с вашими знакомыми. C++ не то чтобы сложен — просто есть набор дополнительных (по сравнению с Java) нюансов, которые всё время нужно держать в голове. С другой стороны в Java есть эти самые отражения и несколько своих нюансов. Но их-то обычно как раз-таки не нужно учитывать.
Рефлекшн не нарушает инкапсуляция в том смысле, что они не нарушают сокрытие реализации. Автору не нравится то, что рефлекшн позволяет получить доступ к данным в private-поле. Но ведь и в том же C++ при желании можно через указатель на объект добраться до приватных полей объекта. Часто это учитывают? Да почти никогда, за исключением кода, предполагающего обфускацию (проверялки леценций, активации и т.п.).
Имхо, автор предлагает решение для несуществующей проблемы.
Reflection — очень полезный инструмент. Используется во многих библиотеках, связанных с обработкой метаданных (Hibernate например использует рефлекш по полной). Но важно понимать, что это всего лишь инструмент. Когда вы используете этот инструмент — вы должны представлять возможные последствия (вроде нарушения инкапсуляции). Сетовать на то, что инструмент де плох — так это уже проблема «плохого танцора»: вы с тем же успехом можете «выстрелить себе в ногу» и говорить, что пистолет вам дали плохой.
Что касается «защиты» с помощью SecurityManager — то это глупость. С одной стороны, масса библиотек просто перестанет работать, а с другой стороны, если кому-то надо будет залезть в каш класс, то он все равно залезеть, хотя бы путём подмены байткода, включающего SecurityManager.
Лучше бы поддержку SFTP и WebDAV сделали :(
То что систему при переполнении стека «уже не спасти» — это и так понятно. Я говорил о том, что вполне возможно организовать какие-то действия, которые будут предприняты перед падением ядра (своего рода «завещание») — вывод сообщения, сохранение дампа памяти и т. д. То есть это всё вполне делается. Мой предыдущий комментарий — мое несогласие с тем, что якобы нельзя делать то, что выше предложил stolen.
Или такое поведение не может быть реализовано?
Рефлекшн не нарушает инкапсуляция в том смысле, что они не нарушают сокрытие реализации. Автору не нравится то, что рефлекшн позволяет получить доступ к данным в private-поле. Но ведь и в том же C++ при желании можно через указатель на объект добраться до приватных полей объекта. Часто это учитывают? Да почти никогда, за исключением кода, предполагающего обфускацию (проверялки леценций, активации и т.п.).
Имхо, автор предлагает решение для несуществующей проблемы.
* все равно сможет залезть
Что касается «защиты» с помощью SecurityManager — то это глупость. С одной стороны, масса библиотек просто перестанет работать, а с другой стороны, если кому-то надо будет залезть в каш класс, то он все равно залезеть, хотя бы путём подмены байткода, включающего SecurityManager.