Нет, два инстанца именно Boolean'а. Соответсвенно оверхеда на заголовок + возможные выравнивания для кратности 8 байтам нет. Согласен, есть оверхед на ссылку.
Потому что null это не «Not Set» и null это не Don't Know.
Всё зависит от того какое логическое поределение мы ему дадим. 2+2 != 4 в кольце вычетов по модулю 3, потому что так определено сложение. Также мы можем определить и использование Boolean'а в зависимости от задачи.
Мне так не кажется — зачем создавать дополнительные сущности, если имеющиеся идеально подходят? Тем более что при правильном использовании Boolean'а в системе находятся только два инстанца. Откуда в таком случае взяться проблемам с памятью?
// JaxbContextRegistry.java
@NotNull
public <T> T unmarshall(@NotNull String xml, @NotNull Class<T> objectClass, @NotNull Class<?>... seeClasses) {
T result = null;
// bla bla bla
return result;
}
Хотя у меня тоже самое написано. Странные вещи творятся в понедельник сутра.
Ой, только что нашёлся баг в хабраредакторе — при нажатии кнопки «Предпросмотр» — пропадают внутренние теги в исходном коде, в данном случае пропадает <T>.
О багах в компиляторе:
вот такой кусок кода компилируется у меня на машине, но не компилируется на компьютере соседа:
public static <T> T unmarshal(@NotNull String string, Class<?> objectClass) {
return JaxbContextRegistry.getInstance().unmarshall(string, objectClass);
}
// JaxbContextRegistry.java
@NotNull
public <T> T unmarshall(@NotNull String xml, @NotNull Class<?>... classes) {
T result = null;
// bla bla bla
return result;
}
У нас одинаковые версии java, отличие только в операционных системах. При этом статический анализатор кода Jetbrains IDEA проблем не видит. В качестве workaround'а мы явно приводим тип T:
public static <T> T unmarshal(@NotNull String string, Class<?> objectClass) {
//<T> is for java compiler bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6302954
return JaxbContextRegistry.getInstance().<T>unmarshall(string, objectClass);
}
при этом IDEA справедливо замечает, что такое приведение типов в данном случае не нужно.
Не понимаю о чём вы — выдержка из самого популярного ответа: I've had good success using Mockito.
When I tried learning about JMock and EasyMock, I found the learning curve to be a bit steep (though maybe that's just me).
I like Mockito because of its simple and clean syntax that I was able to grasp pretty quickly. The minimal syntax is designed to support the common cases very well, although the few times I needed to do something more complicated I found what I wanted was supported and easy to grasp.
1. На самом деле, хибернейт сам не реализует кеширование как таковое 2. Хибернейт не хранит сами объекты Ваших классов. Он хранит информацию в виде массивов строк, чисел и т. д. И идентификатор объекта выступает указателем на эту информацию. Концептуально это нечто вроде Map, в которой id объекта — ключ, а массивы данных — значение. Приблизительно можно представить себе это так:
1 -> { «Pupkin», 1, null, {1,2,5} }
Как первое вяжется со вторым? И если второе — истина, как hibernate восстанавливает объект, если, например, для этого требуются некие хитрые действия?
PS Насколько я помню проксирование объектов можно отключить.
Мы сделали проще (правда не с ант скриптом, но это не важно):
1. Есть конфигурационный файл (тот же ант скрипт) с переменными (хранится в СКВ)
2. Есть запускающий скрипт, в котором указаны все нужные параметры (хранится в СКВ, параметры не валидные, т.е., например, login=LOGIN и т.д. или хранят (как в вашем случае) дефолтные значения)
Пользователь выкачивает проект, копирует запускающий скрипт, модифицирует его (выставляет параметры для своей среды) и успешно работает. Всё довольно просто, ничего инклюдить не надо.
Но это на самом деле уже придирки — естественно работать можно и так =)
Просто из любопытства — вы слышали о Maven? Если нет, то советую глянуть; я бы сазал, что это следующий шаг после анта (кстати, из под maven'а можно выполнять любую антовскую задачу).
Потому что null это не «Not Set» и null это не Don't Know.
Всё зависит от того какое логическое поределение мы ему дадим. 2+2 != 4 в кольце вычетов по модулю 3, потому что так определено сложение. Также мы можем определить и использование Boolean'а в зависимости от задачи.
Здесь можно поспорить — Boolean хорошо использовать, когда нужно именно три состояния, например, True/False/Not Set и Yes/No/Don't Know.
Ой, только что нашёлся баг в хабраредакторе — при нажатии кнопки «Предпросмотр» — пропадают внутренние теги в исходном коде, в данном случае пропадает <T>.
вот такой кусок кода компилируется у меня на машине, но не компилируется на компьютере соседа:
У нас одинаковые версии java, отличие только в операционных системах. При этом статический анализатор кода Jetbrains IDEA проблем не видит. В качестве workaround'а мы явно приводим тип T:
при этом IDEA справедливо замечает, что такое приведение типов в данном случае не нужно.
I've had good success using Mockito.
When I tried learning about JMock and EasyMock, I found the learning curve to be a bit steep (though maybe that's just me).
I like Mockito because of its simple and clean syntax that I was able to grasp pretty quickly. The minimal syntax is designed to support the common cases very well, although the few times I needed to do something more complicated I found what I wanted was supported and easy to grasp.
PS При работе с Mockito появился термин: замОчить класс/метод =)
2. Хибернейт не хранит сами объекты Ваших классов. Он хранит информацию в виде массивов строк, чисел и т. д. И идентификатор объекта выступает указателем на эту информацию. Концептуально это нечто вроде Map, в которой id объекта — ключ, а массивы данных — значение. Приблизительно можно представить себе это так:
1 -> { «Pupkin», 1, null, {1,2,5} }
Как первое вяжется со вторым? И если второе — истина, как hibernate восстанавливает объект, если, например, для этого требуются некие хитрые действия?
PS Насколько я помню проксирование объектов можно отключить.
1. Есть конфигурационный файл (тот же ант скрипт) с переменными (хранится в СКВ)
2. Есть запускающий скрипт, в котором указаны все нужные параметры (хранится в СКВ, параметры не валидные, т.е., например, login=LOGIN и т.д. или хранят (как в вашем случае) дефолтные значения)
Пользователь выкачивает проект, копирует запускающий скрипт, модифицирует его (выставляет параметры для своей среды) и успешно работает. Всё довольно просто, ничего инклюдить не надо.
Но это на самом деле уже придирки — естественно работать можно и так =)
<property name="tomcat.user.name" value="login" /><property name="tomcat.user.password" value="password" />
Лучше: ${login}, ${password}, а вызывать ант скрипт с параметрами: -Dlogin=MY_LOGIN -Dpassword=STRONG_PASSWORD
Плюсы: конечным пользователям не придётся модифицировать код скрипта (который, скорее всего, под СКВ лежит)