Спасибо Вам за то что Вы делаете!
Есть пожелание: сфокусироваться на покрытии. К сожалению, пока Yota не ловится у меня дома, я не могу рассматривать ее как альтернативу проводному интернету.
Работаю в крупной компании. Все что Вы перечислили в ней есть, только помноженное на 10, если не на 100 :). Кроме того есть еще множество других плюсов. У нас, если ты хорош, реально получить свою команду программистов уже в 21 год (не про меня, но есть прецеденты), у нас нереально комфортно и хорошо, много ресурсов, даже социальный аспект чего стоит (надо что-то продать — пиши в корпоративную почту и это купят за полчаса). И никакой бюрократии, все по-человечески. Возможно, мне просто повезло и это исключение.
Что характерно, если ответить на секретный вопрос какую-то фигню, то через 2 года уже ее ни за что не вспомнишь, поэтому так делать нельзя.
А еще нельзя пользоваться стандартными секретными вопросами, думаю в этом основная беда (пресловутая «девичья фамилия матери», которая пробивается по базам).
Я указываю кастомный вопрос, причем нетривиальный и составной, но который я смогу через много лет так же легко вспомнить. Надо спрашивать что-то типа:
«Через подчеркивание прописными русскими буквами: имя первой девушки, что крикнул Вася когда навернулся с велосипеда в Крыму, священное число над которым все шутили в школе». Тогда шансы вспомнить через много лет будут велики, а то что кто-то подберет — ничтожны.
Я бы сказал так: все в порядке, но поведение компилятора в этой ситуации могло бы быть более умным. Ошибка не вполне соответствует проблеме, хотя почему она такая — теперь понятно.
Я понял подвох собственного вопроса. Если код наследника старый, то и метод не будет параметризован, а тогда все в порядке.
И все же, получается, если я обрезаю параметризацию у класса, то автоматом обрезается и параметризация внутри его методов? Это как-то неправильно, хотя и документированно.
Правильно я понимаю, что Вы имеете в виду: если наследоваться без параметров, то компилятор «забывает» любую параметризацию внутри класса BaseClass, поэтому он считает что я пытаюсь реализовать метод test с типизированными параметрами, тогда как надо реализовывать просто test(Class clazz)?
Если так, то ситуация понятна, но это не нормальное поведение, т.к. нарушается обратная совместимость. Допустим у меня есть Collection<E> и MyArrayList<E> и внутри MyArrayList есть параметризованный абстрактный метод. А мой клиент отнаследовался от MyArrayList когда в нем еще ничего не было параметризовано. Получается в новой версии код клиента сломается, т.е. в механизме type erasure есть проблемы с обратной совместимостью… Или я что-то упускаю?
Опять забыл что угловые скобки съедаются как html, пардон.
Правильно читать: «в изначальном примере было Collection<String>» и «напр. MyClass extends BaseClass<String>»
>параметризованный наиболее общим типом Object
Не совсем понял, причем тут именно Object. В данном примере можно заменить Class на любой другой параметризованный класс, а Object на любой объект. У меня в изначальном примере было Collection, но я хотел вырезать импорты чтобы сделать пост покороче, поэтому взял все классы из java.lang :).
Насчет рантайма согласен, но: как связана параметризация метода test и параметризация класса BaseClass?
Достоверно известно, что пример будет работать, если:
1. Добавить параметризацию при наследовании (напр. MyClass extends BaseClass)
2. Убрать параметризацию BaseClass.
3. Убрать дженерики из параметров метода test (т.е. оставить test(Class clazz)).
Мне непонятно почему параметризация BaseClass приводит к ошибке.
Пример вымышленный. В реальном коде наследник будет параметризованным. Но здесь параметризация опущена умышленно, чтобы раскрыть проблему.
В целом, не параметризовать наследника — это не ошибка.
Дженерики в Java создавались с учетом обратной совместимости. Раньше был просто Collection, потом создали generics и появился Collection. Но те, у кого старый код, вполне могли создать своего наследника MyCollection extends SomeCollection (где SomeCollection параметризован ). Т.к. у нас есть обратная совместимость, то старый код не свалится, просто параметризация Collection будет для него проигнорирована.
Есть пожелание: сфокусироваться на покрытии. К сожалению, пока Yota не ловится у меня дома, я не могу рассматривать ее как альтернативу проводному интернету.
А еще нельзя пользоваться стандартными секретными вопросами, думаю в этом основная беда (пресловутая «девичья фамилия матери», которая пробивается по базам).
Я указываю кастомный вопрос, причем нетривиальный и составной, но который я смогу через много лет так же легко вспомнить. Надо спрашивать что-то типа:
«Через подчеркивание прописными русскими буквами: имя первой девушки, что крикнул Вася когда навернулся с велосипеда в Крыму, священное число над которым все шутили в школе». Тогда шансы вспомнить через много лет будут велики, а то что кто-то подберет — ничтожны.
И спасибо за разъяснения.
И все же, получается, если я обрезаю параметризацию у класса, то автоматом обрезается и параметризация внутри его методов? Это как-то неправильно, хотя и документированно.
Если так, то ситуация понятна, но это не нормальное поведение, т.к. нарушается обратная совместимость. Допустим у меня есть Collection<E> и MyArrayList<E> и внутри MyArrayList есть параметризованный абстрактный метод. А мой клиент отнаследовался от MyArrayList когда в нем еще ничего не было параметризовано. Получается в новой версии код клиента сломается, т.е. в механизме type erasure есть проблемы с обратной совместимостью… Или я что-то упускаю?
Правильно читать: «в изначальном примере было Collection<String>» и «напр. MyClass extends BaseClass<String>»
«Раньше был просто Collection, потом создали generics и появился Collection<E>»
Приняли за html =)
Не совсем понял, причем тут именно Object. В данном примере можно заменить Class на любой другой параметризованный класс, а Object на любой объект. У меня в изначальном примере было Collection, но я хотел вырезать импорты чтобы сделать пост покороче, поэтому взял все классы из java.lang :).
Насчет рантайма согласен, но: как связана параметризация метода test и параметризация класса BaseClass?
Достоверно известно, что пример будет работать, если:
1. Добавить параметризацию при наследовании (напр. MyClass extends BaseClass)
2. Убрать параметризацию BaseClass.
3. Убрать дженерики из параметров метода test (т.е. оставить test(Class clazz)).
Мне непонятно почему параметризация BaseClass приводит к ошибке.
В целом, не параметризовать наследника — это не ошибка.
Дженерики в Java создавались с учетом обратной совместимости. Раньше был просто Collection, потом создали generics и появился Collection. Но те, у кого старый код, вполне могли создать своего наследника MyCollection extends SomeCollection (где SomeCollection параметризован ). Т.к. у нас есть обратная совместимость, то старый код не свалится, просто параметризация Collection будет для него проигнорирована.