Hibernate 5 and above supports Java8 DateTime Api through jar "hibernate-java8".But the MavenRepository shows a message Deprecated - use hibernate-core instead) alongside the title of the hibernate-java8 jar.Why is the hibernate-java8 jar called deprecated even though it is required to gain the hibernate support for java8?
You can see the Migration Guide for Hibernate. It specifies that
Hibernate 5.2 is built using Java 8 JDK and will require Java 8 JRE at
runtime (we are investigating whether Java 9 will also work). This has
a number of implications:
The hibernate-java8 module has been merged into hibernate-core and the
Java 8 date/time types are now natively supported.
(todo) support for Java 8 Optional
(todo) support for other Java 8 features?
The hibernate-java8 module has been removed; that functionality has been consolidated into hibernate-core.
For hibernate-java8 see this ticket for explanation,
As this relies on Java 8 and Hibernate still maintains compatibility
back to Java 6, a new module hibernate-java8 was added to isolate the
Java 8 compatibility to just these classes. We will fold the classes
from this module into hibernate-core once we baseline one Java 8.
Since hibernate no longer maintains the hibernate-java8 and you can see that hibernate-java8 is nothing more than an empty placeholder. Github & JIRA Detail.
So, As the functionality has been merged into hibernate-core; hibernate-java8 now is depreciated.
I hope this answer your queries.
Related
I have a RESTful web service application in java deployed on google app-engine which uses jersey 1.18.6.
I want to use postmark java client to send transactional emails from it.
When I integrated it, i was seeing the following exception:
javax.ws.rs.core.Response$Status$Family.familyOf(I)Ljavax/ws/rs/core/Response$Status$Family
From what I could find, I think this error was because of there were two different (and probably incompatible) version of jersey being used ,1.18.6 for jersey-server, jersey-guice and jersey-bundle and 2.25.1 for jersey-client (by postmark).
Then I tried to make the jersey version 1.18,6 throughout, so in the my main project pom, while including the dependency for postmark, I excluded the jersey-client (by added exclusions header) and separately added jersey-client dependency in my main project .
But then I got the following error:
java.lang.NoClassDefFoundError: javax/ws/rs/core/MultivaluedHashMap
This is I think the class MultivaluedHashMap is present only in jax-rs 2.x versions (which is compatible with jersey 2.x versions)
So my questions are:
Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
If no then what options do I have other than migrating my main project from jersey 1.x to jersey 2.x. I don't want to do that since we will have to migrate not just the jersey dependencies but I think some other things like guice, shiro etc. which would be time consuming. Also it doesn't really seem optimal to modify multiple existing dependencies just to include one additional module.
There isn't. The very first commit of the project's pom.xml already used Jersey 2.25.1
as Mureinik mentioned above, when we worked on the library, our plan at Postmark was to use newer library versions, since they are better options in long run.
On our Github page Rupert made good suggestions, from which I find separate ClassLoader a good choice. I will play a bit with the library code in next couple of days on compatibility, however we are always in favour of using newer libraries for our codebase.
please check out my latest comment on Github issues page for possible solution for using older Jersey version https://github.com/wildbit/postmark-java/issues/11
It should be pretty easy to port the library to Jersey 1.x by porting only the HttpClient class on your side.
I am getting started with ehcache(standalone server caching) and confused with different versions.
I have noticed that maven groupid for ehcache 2.x and 3.x is net.sf.ehcache and org.ehcache respectively, which suggests that ehcache versions 2.x and 3.x are for different purpose.
The change of major version coupled with the change of groupId is used to indicate that Ehcache 3.x is not compatible with Ehcache 2.x at the API level.
Both libraries are about caching, from small caches in-memory to distributed caches. Ehcache 3 is also fully compatible with the javax.cache API, the caching standard in Java.
Unless you have third party libraries that do not work yet with Ehcache 3, I recommend picking that version. It is the one under active development. Note that as of Ehcache 3.5, Java 8 is required.
You can of course look at features of each major version on http://ehcache.org.
Does SpringRoo generate code for Java 8 features: Streams, Lambda, Parallel Processing? If so, please point to example links.
The SpringRoo release notes mention that it supports Java 8, but has no more details.
Some time ago I was evaluating Spring Roo. There is the 1.x branch which afaik does not have any special support for Java 8 since it was released years ago, and it is a feature of the upcoming 2.x version to support Spring 4 according to a blog entry from early 2015. But there is still no final version available, so possibly this is not a high-priority project.
You might also have a look at Spring Boot. With Spring Boot you can create JPA entities, CRUD repositories and REST interfaces with very little boilerplate code. In my opinion, this reduces the need for a tool such as Spring Roo.
I am using the latest (by the time of writing) Spring-Boot-starter-data-jpa (version 1.2.6.RELEASE). I find it actually uses the Spring-data-jpa version 1.7.3.RELEASE, which is considerably behind the latest (1.9).
Is it a supported approach to upgrade individual dependencies such as the Spring-data-jpa? If I do this myself, for example, by declaring a direct dependency on the wanted newer version (may just override the version properties), any side effect you guys foresee?
The reason why I am doing this is that I need to use a special parameter in this annotation:#EnableJpaRepositories(repositoryBaseClass = JpaRepositoryWithI18n.class)
That is not available in the supplied 1.7.3 jpa library.
Any workaround would be appreciated too.
Thanks
EDIT:
I tested the following two ways: 1) declared a direct dependency to Spring-JPA-data 1.9.0 and excluded it from spring-boot-starter-data-jpa 2) upgrade Spring-boot-web-starter to 1.3.0m5
2) worked out well for me. This is also what dunni's answer suggested.
I have not tested Andi's answer as this is a new project, we could easily upgrade the entire spring boot and regression test it without worrying too much about side-effects.
But I can see Andi's answer is an easier approach than 1). More importantly, it shows how you can upgrade other dependencies independently -- just overide the versions in parent pom.
Thanks
Spring Data JPA 1.9 is part of the Spring Data Gosling release train. As described in the Gosling announcement you can use it with Spring Boot 1.2:
To upgrade to the new release train use the BOM we ship as described in our examples repository and configure its version to Gosling-RELEASE. If you’re using Spring Boot, upgrading to the release train is as easy as setting the Maven property spring-data-releasetrain.version to that version. Note, that to use Spring Data REST with Boot 1.2, you also need to upgrade to Spring HATEOAS 0.19.0.RELEASE (by setting the spring-hateoas.version property) and Jackson 2.5 or better (current 2.6.1 preferred, via the jackson.version property).
In short, add this to your pom:
<properties>
<spring-data-releasetrain.version>Gosling-RELEASE</spring-data-releasetrain.version>
</properties>
It's not supported in that matter, that the Spring Boot test cases don't include newer versions. So your application might work with the newer version, but there may be some errors. With minor releases it's more likely to work without problems than with major version upgrades. You can also upgrade Spring Boot to 1.3.0.M5 (you should note however, that this is a milestone version, not yet the release).
When compiled with java 7u79, spring 3.1 app is all good. When compiled on java 7u80, we're encountering some injection issues.
Searching a solution i found that Spring 3 is not compatible with java8, as explained here (due to asm).
We can see here that javac modifications were backported to java 7u80 and java 7u85.
So, am I rigth to think that it's same compatibility problem than for java 8, and that spring 3 app will not work if compiled on java7u80 ?
Sharing my experience - yes, some spring versions have problems with java 8. For example in my project we've had to change spring from 3.2.4 to 3.2.9 to use java 8. I won't put here any particular example because I don't have one but I would advice you to give spring 3.2.9 a chance. We're using it successfully with Java 8.