Looking for something else? Check the categories of JVM:
Akka Class loading Garbage Collection Google Guava Hibernate Java Java 8 Java bytecode Java collections Java concurrency Java I/O Java Instrumentation Java memory model JPA JUnit Maven Monitoring Off-heap Play Framework Scala async Scala collections Scala core Scala functional Scala OOP Scala syntax Scala tests Scala types Spring Data JPA Spring framework Spring Integration Spring security Spring Web MVC Tomcat
If not, below you can find all articles belonging to JVM.
Google Guava as a set of libraries used in Google projects couldn't not contain some worries about concurrency.
One of most "speaking" objects in Java is String. However, to achieve some operations we need to implement own methods. With Google Guava String support, operations on chain of characters are easier.
In the previous articles we were working with Hibernate's specific elements as Session or SessionFactory. But they are not the only possible choices. We can too opt for working with Hibernate's implementation of JPA specification.
When multiple operations must be processed at once, it's better to do it automatically. This type of operations is called batch (do not confuse with bash which is a command language).
Classes synchronization in Java multi-threading environment can be done thanks to many classes from java.util.concurrent package. But it can also be achieved thanks to some traditional methods, as monitors.
In multi-threading languages as Java, a memory model is mandatory to be able to determine correctly code behavior on concurrent tasks execution.
If you're following well the article about authentication and authorization in Play Framework, you could see that @Authorize annotation is accompanied by another annotation, @With. Thanks to it, the @Authorized is evaluated with the class specified inside @With annotation.
We've already discovered the bean post processor factory in Spring. However, they left one similar concept to explain, bean post processors.
Spring allows us to make a lot of operations with beans. We can decide if they should be unique instance on container (singleton) or not (prototype). We can also make some of operations "in the fly", thanks to bean factory post processors.
Dependency injection in Spring facilitates development. You can simply put @Autowired annotation, followed by visibility tag and object, to can use every object managed by Spring context. But beware, all of these objects are a kind of Spring-managed singleton.
Like we already know, application context is the container where Spring-managed beans live. But the question that we didn't ask, is how this context is created ? We'll reply to this question in this article.
Previously we've told that Spring beans were living in application context. In this article we'll develop this idea and present application context more in detail.
Previously we discovered the basics of integration testing in Spring. So now it's a great time to deepen this subject.
Making the code testable is one of the crucial points of maintainable software. Without the tests, the code is exposed to surprising bugs on every change.
If you remember well our previous article, we introduced the concept of forms and validation. To illustrate it, we used the register form case. Now, when user can register, he also should be able to login.
Previous article presented forms and validation in Play Framework. But we didn't described how to display and format forms in the templates.
Spring's DispatcherServlet couldn't dispatch the requests without several elements. One of the most important of them is handler execution chain.
Concurrent programming isn't not only about executing several tasks in parallel threads. It's only about analyzing results of these process. In Java, we can analyze them thanks to the idea of futures.
Java 1.5 introduced a concept of executors, very useful for concurrent environments. Thanks to them we can easily create thread pools and even manipulate results generated by the threads. This article will cover this subject.
Tests driven developpement (TDD) has a lot of advantages. We can simply rewrite a class and be sure that the application will still work after thanks to appropriated test cases. It's pretty simple to write them in single threading environment. But what to do when a test must be executed in multi-threading environment ?
