What’s the difference between JPA and HIBERNATE

When you use Hibernate with JPA you are actually using the Hibernate JPA implementation. The benefit of this is that you can swap out Hibernate’s implementation of JPA for another implementation of the JPA specification. When you use straight Hibernate you are locking into the implementation because other ORMs may use different methods/configurations and annotations, therefore you cannot just switch over to another ORM.

http://stackoverflow.com/questions/9881611/whats-the-difference-between-jpa-and-hibernate

Best Way to Inject Hibernate Session by Spring 3

The Spring Reference suggests this usage:
http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/orm.html#orm-hibernate-straight

http://docs.spring.io/spring/docs/4.3.x/spring-framework-reference/html/orm.html#orm-hibernate-straight

public class ProductDaoImpl implements ProductDao {

private SessionFactory sessionFactory;

public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
}

public Collection loadProductsByCategory(String category) {
return this.sessionFactory.getCurrentSession()
.createQuery(
«from test.Product product where product.category=?»)
.setParameter(0, category)
.list();
}
}
That way your classes don’t have any dependencies to Spring, you just use plain Hibernate.

H2db Spring console

http://shengwangi.blogspot.com/2016/02/how-to-use-h2-embeded-database-in-spring.html


<bean id="h2WebServer" class="org.h2.tools.Server" factory-method="createWebServer"
init-method="start" destroy-method="stop">
<constructor-arg value="-web,-webAllowOthers,-webDaemon,-webPort,8082" />
</bean>
In java-styled spring configuration, it looks like below.


@Configuration
@ComponentScan
public class JavaConfiguration {
//... other beans

@Bean(initMethod=»start»,destroyMethod=»stop»)
public org.h2.tools.Server h2WebConsonleServer () throws SQLException {
return org.h2.tools.Server.createWebServer(«-web»,»-webAllowOthers»,»-webDaemon»,»-webPort», «8082»);
}
}

http://stackoverflow.com/questions/17803718/view-content-of-embedded-h2-database-started-by-spring

java AZ

info.javarush.ru/page/learning_plan :

План обучения:
Знакомство с Java: вывод на экран, типы String и int
Знакомство с Java: переменные, методы, классы
Первая программа: ввод с клавиатуры, работа в IDE
Знакомство с ветвлениями и циклами
Знакомство с классами: написание своих классов, конструкторы
Знакомство с объектами: написание своих объектов, время жизни, статические переменные
Массивы и списки: Array, ArrayList, знакомство с Generics
Коллекции: LinkedList, HashSet, HashMap. Date — дата.
Знакомство с исключениями: try, catch, throws, multy-catch.
Приведение примитивных типов: расширение и сужение.
Основы ООП: основные принципы, наследование, инкапсуляция.
Основы ООП: перегрузка, полиморфизм, абстракция, интерфейсы.
Интерфейсы: сравнение с абстрактным классом, множественное наследование.
Приведение типов, instanceof. Большая задача на интерфейсы.
Перегрузка методов, особенность вызова конструкторов
Знакомство с нитями: Thread, Runnable, start, join, interrupt, sleep
Знакомство с нитями: synchronized, volatile, yield
Знакомство с потоками: InputStream/OutputStream, FileInputStream, FileOutputStream
Знакомство с потоками: Reader/Writer, FileReader/FileWriter
Сериализация
Устройство объекта Object: equals, hashCode, clone, wait, notify, toString(),…
String: mutable, immutable, format, StringTokenizer, StringBuilder, StringBuffer
Внутренние классы, примеры: Map.Entry
Внутренние классы, особенности реализации
Создание и остановка нитей: start, interrupt, sleep, yield.
Совместный доступ к монопольным данным: synchronized, volatile
DeadLock. Wait, notify, notifyAll
ThreadGroup, ThreadLocal, Executor, ExecutorService, Callable. Опыт работы с Jsoup
Autoboxing, особенности реализации
Операторы: числовые, логические и бинарные. Опыт работы с Swing
Работа с файлами и архивами
RMI и динамический прокси. Опыт работы с Swing
JSON, JavaScript. Опыт работы с Guava, Apache Commons Collections, JUnit
Рекурсия. Сборка мусора и типы ссылок в Java. Логгирование
Системы контроля версий: Git и SVN. Generics
Основные паттерны для создания веб приложений. Углубленное изучение коллекций
Паттерны проектирования. Утилитные классы Arrays. Collections
Методологии разработки. Аннотации в Java. Иерархия исключений
Создаем первое веб приложение. Работа с Tomcat и Idea
URI, URL. REST сервисы. Создаем свое клиент-серверное приложение.

Виды памяти в Java.

https://autofei.wordpress.com/2012/04/12/diagram-for-java-memory-structure-and-garbage-collection/

Вся память для JVM:
— Heap Mem(КУЧА) — хранилище для Джава объектов
— НЕ-Heap-memory(НЕКУЧА) — использ-ся Джавой для хранения загруженных классов
и других мета-данных. Строковый пул, или множество строк в куче?*, etc
— Сам код JVM, внутр структуры JVM, загруженный код агента, данные etc

 

gc_s

в КУЧЕ — две части:New generation и Old generation память.
В New generation: Eden для new Object, два Survivor пространства(from и  to) одного и того же размера- там хранятся выжившие объекты после GC.
в Old generation: тут долгоживущие объекты

 

*???располагается в области памяти, именуемой Java Heap – куча, в которой хранятся все переменные, созданные программно вашим приложением.???

Without configuration, a client JVM uses this calculation for the spaces:

Heap = Tenured + Young
Tenured = 2 x Young
Young = Survivor x 2 + Eden

Итак, память процесса различается на heap (куча) и non-heap (стек) память, и состоит из 5 областей (memory pools, memory spaces):
1• Eden Space (heap) – в этой области выделятся память под все создаваемые из программы объекты. Большая часть объектов живет недолго (итераторы, временные объекты, используемые внутри методов и т.п.), и удаляются при выполнении сборок мусора это области памяти, не перемещаются в другие области памяти. Когда данная область заполняется (т.е. количество выделенной памяти в этой области превышает некоторый заданный процент), GC выполняет быструю (minor collection) сборку мусора. По сравнению с полной сборкой мусора она занимает мало времени, и затрагивает только эту область памяти — очищает от устаревших объектов Eden Space и перемещает выжившие объекты в следующую область.
2• Survivor Space (heap) – сюда перемещаются объекты из предыдущей, после того, как они пережили хотя бы одну сборку мусора. Время от времени долгоживущие объекты из этой области перемещаются в Tenured Space.
3• Tenured (Old) Generation (heap) — Здесь скапливаются долгоживущие объекты (крупные высокоуровневые объекты, синглтоны, менеджеры ресурсов и проч.). Когда заполняется эта область, выполняется полная сборка мусора (full, major collection), которая обрабатывает все созданные JVM объекты.
4• Permanent Generation (non-heap) – Здесь хранится метаинформация, используемая JVM (используемые классы, методы и т.п.). В частноси
5• Code Cache (non-heap) — эта область используется JVM, когда включена JIT-компиляция, в ней кешируется скомпилированный платформенно — зависимый код.
2016-07-10-052407_1198x647_scrotvisual-gc

Виртуальная и резидентная память

VIRT Virtual Image

Виртуальный размер процесса(VSZ — Virtual Set siZe). Показывает общее количество памяти, которое способна адресовать программа в данный момент времени. VIRT = DATA + CODE + SWAP + SHR Также включает в себя страницы, которые были выделены системой, но не использованы.

RES — Resident memory size или RSS — Resident Set Size.

Показывает сколько физической памяти использует процесс. (Соответствует колонке %MEM.) Это значение, будет меньше значения VIRT

SHR — Shared Memory size

Количество разделяемой памяти, которое используется процессом. Отображает количество памяти, которая потенциально может быть разделена с другими процессами.

SWAP — Swapped size

Память, которая не является резидентной, но доступна в текущем процессе.

DATA -Data + Stack size

Количество виртуальной памяти, отведенное под код, который не является исполняемым.

CODE — Code size

Количество виртуальной памяти, отведенное под исполняемый код.

— Что бы там ни было, многие утилиты просто сообщают, сколько памяти
процесс использует, независимо от того, разделена ли та память с
другими процессами или нет. Поэтому две программы могут использовать
большую разделяемую библиотеку и ее размер в памяти будет считаться
два раза, что может вводить в заблуждение, если Вы не знаете что
происходит.

— Просматривая листинг Вы найдете строки с наибольшей занимаемой
памятью,- это сегменты кода включающие разделяемые библиотеки (их
названия начинаются с lib). Все они могут использоваться и другими
процессами. В этом случае смотрите итоговую строку
«writeable/private».

— Таким образом, затраты на запуск одной копии KEdit в случае, если все
разделяемые библиотеки уже подгружены в память, составляют около 2 Мб.
Сравните это с теми 14 или 25 Мб о которых сообщает ps.

— Мораль всей этой истории в том, что использование процессами памяти в
Linux является сложным вопросом. Вы не можете выполнить только ps и
знать, что происходит. Это особенно истинно, когда Вы имеете дело с
программами типа Apache, которые создают много идентичных дочерних
процессов.

java Generics

https://advancedweb.hu/2016/05/03/java_variance/

 

Lacking imagination, I use the classic Pet example for subtyping in the code snippets for this post. Dog and Cat are subtypes of Pet, so when an expression of Pet type is required, a Dog or a Cat can be used as well. Variance refers to subtyping of complex types created from simple types, such as:

  • is an array of Dogs a subtype of an array of Pets?
  • what about Collections?
  • how do similar functions relate to each other, that, for example take a Cat and a Pet as an argument?

Arrays

Because early versions of Java did not include generics, for practical reasons arrays were made to be co-variant.

This means if we can substitute A for B then we can substitute A[] for B[] as well.

This is good, because we can pass various types of arrays to the same method, like passing an array of Dogs to a method that expect an array of Pets of any kind.

Dog[] dogs = { new Dog() };
Pet[] pets = dogs;

If we don’t add new elements to the pets array, there is no problem, but writing to it can be problematic in this case.

The code below compiles fine, but when executed it throws an ArrayStoreException because we are trying to add a Cat to an array of Dogs (in a line, where the type information says they are just Pets).

Dog[] dogs = { new Dog() };
Pet[] pets = dogs;
pets[0] = new Cat(); // ArrayStoreException

Throwing an Exception in this case is really good, compared to the other alternative, to let the problem show it’s ugly face when we would read the original dogs array, and expect all elements to be a Dog.

for (int i = 0; i < dogs.length; i++) {
	// This would be a problem, as dogs[0] is not a Dog, but a Cat.
	Dog dog = dogs[i];
	System.out.println(dog.bark());
}

To summarize, arrays are co-variant, so writing to them can cause problems, and the Java type system can’t prevent it from happening.

Generics

Generic types appeared in Java 5, and one of their most popular use-case is Generic Collections. Unlike simple arrays, the different parameterizations of generic types in Java are invariant by default. For example, a List<Pet> is a totally different thing than List<Dog>, they can not be substituted.

So, the code below does not compile:

List<Dog> dogs = new ArrayList<Dog>();
List<Pet> pet = dogs; // This line does not compile

The variance of the type parameter can be specified when using a generic type. (This is called use-site variance. Other languages, such as Scala support declaration-site variance that allows the creator of the generic type to specify the variance of it’s type arguments.)

Co-variance

With ’? extends’ the type parameter can be marked to be co-variant. This can make the substitution work for Lists just as it would with simple arrays.

List<Dog> dogs = new ArrayList<Dog>();
List<? extends Pet> covariantList = dogs;

The difference is that it’s co-variant nature is encoded in it’s type.

It indicates that like in the case with arrays, we can read Pets from the List without a problem, because we know for sure that what we get is at least a Pet.

Pet pet = covariantList.get(0); // OK

But we don’t know what other conditions must be fulfilled. The parameter indicates that the type of the List is unknown, and it’s upper bound is Pet. We can’t write any kind of Pet to this List to satisfy it’s static type constraints, as this unknown type might be Dog, Cat, but it could be something more exotic, that we might not even heard of. Octopus, Shark, or a HairySpider.

covariantList.add(new Pet()); // This does not compile.
covariantList.add(new Dog()); // This does not compile.

Compared to simple arrays, using this co-variant List turns the runtime error encountered before to a compile time one.

Contra-variance

Similarly to co-variance, with ’? super’ we can declare a contra-variance.

List<Pet> pets = new ArrayList<Pet>();
List<? super Pet> contravariantList = pets;

A contravariantList is a list of something that is a superclass of Pet. As with covariance, the question mark represents that the exact type of something is unknown, Pet is it’s lower bound is in this case. This means the type might be Pet, or any of it’s ancestor types like Creatures, but it simply can be Object as well. So while we can read elements from the list, but the typechecker can not guarantee anything about their types.

Pet pet = contravariantList.get(0); // This does not compile.

But we can write new Pet entries to it, because we know that the unknown type guaranteed to be substitutable with Pet.

contravariantList.add(new Pet()); // OK
contravariantList.add(new Dog()); // OK
contravariantList.add(new Cat()); // OK

To summarize, it is safe to read from a co-variant List, but we can’t write to it, while it is safe to write a contra-variant List, but reading items from it can be problematic.

The asymmetry is caused by the same type parameter (E) on the input and output types of the methods. It drives the minimum type requirements of the object to be passed into it as an argument, and the minimum guarantees about the object’s type it returns.

E get(int index); // I give you at least an E, but you can expect less.
boolean add(E e); // I need at least an E, but you can give more.

Java 8 lambdas and method references

Consider the following short example that illustrates co-variant types from the previous section:

static void example() {
	Consumer<Pet> petConsumer = pet -> System.out.println(pet);
	Consumer<Object> objectConsumer = System.out::println;

	breed(petConsumer); // OK
	breed(objectConsumer);  // Compile error
}

static void breed(Consumer<Pet> consumer) {
	consumer.accept(new Pet());
	consumer.accept(new Dog());
}

Of course, because of breed’s argument, Consumer is invariant with the supplied Consumer parameter, there is a compile error.

Because the System.out.println method takes an Object, and returns nothing, at first I thought that the type of the System.out::println expression is equivalent to Consumer.However, if we pass it directly to the breed method, it compiles fine.

breed(System.out::println); // OK

This is because Java threats the substitution of lambda expressions and method references differently from simple parameterized generic types. See chapters 15.13.2 Type of a Method Reference and 15.27.3 Type of a Lambda Expression from the The Java Language Specification Java SE 8 Edition, they have a lot in common.

For example, consider the snippet below:

public static EmailMessage transform (Message m) {return new EmailMessage();}

public static void methodReferenceExamples () {
	Function<Message, Message> a = CovarianceExample::transform;
	Function<Message, EmailMessage> b = CovarianceExample::transform;
	Function<EmailMessage, Message> c = CovarianceExample::transform;
	Function<EmailMessage, EmailMessage> d = CovarianceExample::transform;
}

Although for some of the assignments the referred method requires different types for the argument or the return type than the parameterization of corresponding Functional Interface indicate, all assignment compile fine. In every case the argument type parameter of the Functional Interface requires a Message, or a more specific EmailMessage, which is fine, because the transform method expect at least a Message. There is no harm giving something more specific to it.

The return types are aligned well too, the transform method provides an EmailMessage which is exactly what’s needed, or even more specific.

Of course, providing less, or requiring more would result in a compile error.

public static Message transform (EmailMessage m) {return new Message();}

public static void methodReferenceExamples () {
	Function<Message, EmailMessage> iAmTooDemanding = CovarianceExample::transform; // Compile error. 
	Function<Message, Message> iAmNotGivingYouEnough = CovarianceExample::transform; // Compile error.
}

Java 8 Lambda expressions have similar behaviour if we don’t specify the argument types, and let the compiler infer them for us.

breed(s -> System.out.println(s)); // OK

So, a method or a function defined by a lambda expression is co-variant in its return value and contra-variant in its arguments. This convenience aids functional programming in Java very well.

Similar rule applies for method overloading, but the argument types in that case must match exactly, possibly to aid method resolution.