HH
Мне нравится этот коммент в их issues
https://github.com/google/gson/issues/1477#issuecomment-467862508
Типа это не баг, это фича)
https://github.com/google/gson/issues/1477#issuecomment-467862508
Типа это не баг, это фича)
Size: a a a
2021 February 19
HH
Видимо вариантов кроме как писать свой TypeAdapter - нет
AG
Добрый день
Возможно ли с помощью jackson-dataformat-xml из xml файла генерить Java POJO или другой библиотекой?
Возможно ли с помощью jackson-dataformat-xml из xml файла генерить Java POJO или другой библиотекой?
AG
или придется руками самому писать этот Java class?
AG
Никто не сталкивался с такой проблемой?
AG
http://www.mojohaus.org/jaxb2-maven-plugin/Documentation/v2.4/ вот такая штука есть для генерации классов. Только нужен не xml, а xsd
AG
http://www.mojohaus.org/jaxb2-maven-plugin/Documentation/v2.4/ вот такая штука есть для генерации классов. Только нужен не xml, а xsd
Увы ее нет
AG
Но все равно спасибо
AG
jackson, насколько я знаю, не умеет. И вообще у него достаточно базовая поддержка xml, лучше его не использовать, потому что будет косячить на сложных случаях.
e
Привет, сча тупой вопрос о JDK будет.
Подскажите, почему equals of String не использует хешкод (если он уже вычислен на момент обращения, так то он lazy), чтобы убрать посимвольное сравнение, когда хэши не равны. Вот как выглядит String.equals в JDK15:
Подскажите, почему equals of String не использует хешкод (если он уже вычислен на момент обращения, так то он lazy), чтобы убрать посимвольное сравнение, когда хэши не равны. Вот как выглядит String.equals в JDK15:
public boolean equals(Object anObject) {
if (this == anObject) {
return true;
}
if (anObject instanceof String) {
String aString = (String)anObject;
if (!COMPACT_STRINGS || this.coder == aString.coder) {
return StringLatin1.equals(value, aString.value);
}
}
return false;
}AG
Увы ее нет
В IDEA есть generate XSD from file. Можно разово сгенерировать, а потом уже руками дописывать
AG
В IDEA есть generate XSD from file. Можно разово сгенерировать, а потом уже руками дописывать
Ок, спасибо
T
Привет, сча тупой вопрос о JDK будет.
Подскажите, почему equals of String не использует хешкод (если он уже вычислен на момент обращения, так то он lazy), чтобы убрать посимвольное сравнение, когда хэши не равны. Вот как выглядит String.equals в JDK15:
Подскажите, почему equals of String не использует хешкод (если он уже вычислен на момент обращения, так то он lazy), чтобы убрать посимвольное сравнение, когда хэши не равны. Вот как выглядит String.equals в JDK15:
public boolean equals(Object anObject) {
if (this == anObject) {
return true;
}
if (anObject instanceof String) {
String aString = (String)anObject;
if (!COMPACT_STRINGS || this.coder == aString.coder) {
return StringLatin1.equals(value, aString.value);
}
}
return false;
}Во-первых, этот метод интринсифицирован. Реально работает не эта реализация
T
Ну и в большинстве случаев сравнение в случае неравенства отсекается быстро и так: либо не совпадёт длина, либо не совпадёт один из первых символов. Не такой частый случай, чтобы совпадала длина и большой префикс. С учётом того, что придётся переписывать интринсики для c1/c2/graal, это кажется кучей работы ради очень сомнительной выгоды
DC
Понятно, что сравнение длинных строк векторизовано, там не посимвольно сравнивается.
интересно, бывают ли нагрузки и форматы (паттерны, скорее даже) входных данных, на которых выгодно реализовывать своё сравнение строк