AB
компилятор проверяет это, чтобы не было проблем как в груви :) там ты можешь спокойно так написать, компилятор это скушает,а в рантайме ты упадешь, будет неприятно
spring.datasource.hikari.maximum-pool-sizeSize: a a a
2020 May 26
SK
https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html
Ок, разобрался. Свойство работает, конфига не та подгружалась
AB
на то в жаве и есть статическая типизация
D
У тебя список, если бы компилятор не делал проверок, то в рантайме ты бы начал сортировать список и упал бы :) потому что в списке лежал Object
хотя хороший пример, да сигнатуры те же
AB
теперь понятнее?)
D
понятнее почему так сделано, да. но я всё равно убеждён что в моём примере там спокойно могли быть инты
AB
но могли быть и Object
D
спасибо
AB
не за что)
D
но могли быть и Object
не, Object'а быть не могло потому что компаратор
а вот список этой же лямбде передаёт свои объекты, но чтение из него всегда отдаёт Object'ы:
https://stackoverflow.com/a/4343547/4012848
потому и компаратор должен уметь их сравнивать
a у которого мы вызываем .thenComparing принимает только Integer, который потом передаст этой злосчастной лямбдеа вот список этой же лямбде передаёт свои объекты, но чтение из него всегда отдаёт Object'ы:
https://stackoverflow.com/a/4343547/4012848
потому и компаратор должен уметь их сравнивать
AB
Мы же говорили о том, если бы компилятор не проверял тип, то мог быть обжект и ты бы узнал об этом в рантайме
AB
А так, да, ты ограничил компаратор только сравнением интов, при этом сигнатура умеет принимать Object
D
Мы же говорили о том, если бы компилятор не проверял тип, то мог быть обжект и ты бы узнал об этом в рантайме
но он же проверяет, так как тогда объект то залетит
D
как раз из-за PECS'а мы же и не можем передать туда объект, хотя в списке он может быть изначально
AB
ну и у тебя будет ошибка компиляции, т.к. ты компаратор научил только сравнивать инты
D
ну компиляции же, не рантайма
AB
привет, подскажите, то что я в этом коде не могу сравнивать
x и y во второй лямбде - это недочёт компилятора или справедливая защита?Comparator<? super Integer> a = (x, y) -> Integer.compare(x, y);
Comparator<? super Integer> b = a.thenComparing((x, y) -> Integer.compare(x, y));так, твой вопрос был про защиту) я тебе объяснил, что да, это защита и объяснил что было бы, если бы ее не было
D
так, твой вопрос был про защиту) я тебе объяснил, что да, это защита и объяснил что было бы, если бы ее не было
ну так не может туда объект попасть, значит мой пример прекрасно бы работал, если бы не защита компилятора, которая для моего примера ничего не делает
D
не может, иначе будет ошибка компиляции
D
вот так могу сказать