It seems that the new java.time API offers everything from java.util.Date and much more.
Is there any reason to use java.util.Date when the newer java.time API is there since Java 8?
Should java.util.Date and java.util.Calendar be avoided completely?
Short answer: The new API java.time is way better than the old world with java.util.Date and java.util.Calendar. So yes, the new API should be preferred in new code.
For a quick overview: Once I had written a comparison of features in table form for various date-time-libraries. There is almost no feature which java.time is missing but exists in the old world:
configurable gregorian/julian cutover
printing based on the class FieldPosition (used in Swing-component FormattedTextField)
About deprecation: Although most parts of java.util.Date are deprecated since Java 1.1, the class itself (and java.util.Calendar, too) are not officially deprecated, just declared as de facto legacy. The support of the old classes is still important for the goal of backwards compatibility with legacy code. So Oracle will probably not stop the support at any time in the future. But maybe Oracle will apply more sophisticated deprecation strategies.
Future development: It is interesting that the release of Java-8 has not only incorporated a completely new date/time-API (java.time) but also seen some few enhancements to java.util.Calendar, for example Calendar.Builder or SHORT_STANDALONE etc. Well, I can only speculate but this also seems to indicate that Oracle is not willing to stop the support of the old API in the near future.
Related
Can anybody explain me the differences of implementations from IBM and Oracle of java BigDecimal, in java 8?
I know that the IBM implementation of BigDecimal (com.ibm.math.BigDecimal) is deprecated and I want to move to the Oracle implementation (java.math.BigDecimal), but I'd like to know the main differences between the 2 versions (starting at version java 8).
Thanks.
IBM donated their code to Java 5.
The BigDecimal implementation in OpenJDK is a continuation and evolution of that original IBM implementation. Notice the IBM copyright notice in the source code of OpenJDK. Perhaps the change history on that file might interest you.
Since their donation, I know some serious improvements were made, though I cannot remember the details. There were talks given at JavaOne conferences addressing these improvements, bug fixes, and math-related issues.
To migrate is utterly simple:
Change your import statements.
Know that any serialized objects cannot be read between the two implementations (being identified as coming from two different classes).
To quote IBM:
Enhanced BigDecimal
From Java™ 5.0, the IBM® BigDecimal class has been adopted by Oracle as java.math.BigDecimal. The com.ibm.math.BigDecimal class is reserved for possible future use by IBM and is currently deprecated. Migrate existing Java code to use java.math.BigDecimal.
The new java.math.BigDecimal uses the same methods as both the previous java.math.BigDecimal and com.ibm.math.BigDecimal. Existing code using java.math.BigDecimal continues to work correctly. The two classes do not serialize.
To migrate existing Java code to use the java.math.BigDecimal class, change the import statement at the start of your .java file from: import com.ibm.math.; to import java.math.;.
Does liferay 6.2 allow using new Java 8 date classes such as LocalDate to be used as a datatype for entity column fields,in order to utilise more features on the same.We need to use
<column name="createDate" type="LocalDate" />
instead of<column name="createDate" type="Date" />
Is there some other means to achieve this?Does tweaking hibernate version,allow usage on the same,if so,is that valid?
Liferay 6.2 started with Java 7 compatibility and only got compatible with Java 8 later, mostly due to limitations of the supported application servers - this is a good indicator that there's nothing foreseen with regards to Java 8 classes. While they might work, you might run into untested territory. I'm neither saying it does nor it doesn't - although I suspect that you have tried already and ran into problems when you ask the question here.
As Guivani Grifante said, upgrading Hibernate within Liferay most likely will result in a huge mess, and if you are ready to do that, I'd rather ask to upgrade to Liferay 7 (though I didn't double-check its Hibernate version).
Another means to get to such an adoption is to use the old Date type and just add a converting getLocalDate() and setLocalDate() to the YourModelImpl and just implement the conversion yourself. Yes, a bit weird, but might be the quickest fix, without a lot of immediate upgrade hassle. However, if you use 6.2 CE, note that there won't be any more updates and you should move on to 7 sooner rather than later. If you're on EE, you'll have a while of support left.
This isn't the only problem if you deploy a portlet with Java 8 into Liferay. If your code was compiled with Java 8 and contains remote services generated by service builder, you will get an error while deploy such portlet. This is caused because Liferay uses a Jodd api to analyze bytecode and get the parameters names to show in /api/jsonws
Hibernate 5.x has support to new date api, however, there is little chance of upgrade without break Liferay 6.2.
Spring Data Neo4j (SDN) 4.0 did away with #RelationshipType and #Labels, among other tools that could be used to implement dynamic typing or runtime polymorphism. In SDN 4.0 all polymorphic possibilities (labels and relationship types) must be modeled explicitly, statically, in Java prior to build time. Given those limitations, I am unable to migrate my SDN 3.x code, which took advantage of those features, forward.
I would appreciate any insight, work arounds, alternative tools, etc. anyone has to offer. The only alternative right now that I see is to unplug SDN and write directly to Neo4j.
Thanks
We're very aware that the lack of runtime polymorphism is currently frustrating some SDN 3 users who want to migrate to SDN 4. And while there may be workarounds in many cases, we also accept that having to refactor application code is not ideal.
We do want to address this, however to enable runtime polymorphism will require both architectural and implementation changes, so its not something we can expect to accomplish in just a few days. Unfortunately, right now we can't commit to when we will be in a position to start that work, because the product road map is still being discussed with the development team and the product owner, Neo Technology.
If you can stay with SDN 3 that might be the best option right now until this feature is available in SDN 4.
I'm evaluating to migrate my project from the usage of Joda-Time to the java.time package in Java 8. In Joda-Time, I heavily used the Interval class. I could not find anything like this in java.time.
Is there a comparable class?
Sorry for you, there is no equivalent in JSR-310 to JodaTime-Interval-class. I have doubts if this will ever come, but project lead Stephen Colebourne considers at least to support it in the scope of his external library Threeten-Extra, see this issue.
If you are happy with JodaTime you should keep it. Not everything in JodaTime is ported to Java 8 (Interval is not the only issue).
Update from 2014-12-13:
The situation in Java-8 has not changed, but you might also consider other external libraries beyond Joda-Time. Either Threeten-Extra which now includes a very simple interval class since v0.9 (see the other answer of S. Colebourne here) or my library Time4J which offers the range package since v2.0.
JDK 8 JSR-310 does not have an Interval class. The concept of intervals was descoped to ensure that the rest of the library could be completed.
The ThreeTen-Extra project hosts additional non-JDK date-time classes, and v0.9 includes Interval.
Note: Answer updated 2014-12-10 to include presence of Interval in ThreeTen-Extra.
Use Range class from Guava.
See https://stackoverflow.com/a/23485533/1214902 for more details.
Class java.time.Duration may give you similar functionality. In general java 8 time package is very comprehensive and flexible
I am very new to Spring JDBC and working on a given task, looking at the codes we already have my teammates have used RowMapper, but I was doing some Googling and saw some tutorials are using ParameterizedRowMapper , so I was wondering if there is any benefit or good practice in using one rather than the other one and your technical thoughts behind that...
thanks.
Right from the javadoc of ParameterizedRowMapper:
Extension of the RowMapper interface, adding type parameterization. As
of Spring 3.0, this is equivalent to using the RowMapper interface
directly.
Prior to Spring 3.0, most APIs did not use generics because Java 1.5 wasn't a requirement. As a result, there was a RowMapper, that didn't support generics and ParameterizedRowMapper that did support generics by extending RowMapper and adding the generic parameter. As of Spring 3.0, most APIs were updated to support generics. If you actually look at the current (3.0 or greater) definition of ParameterizedRowMapper, it just simply extends RowMapper and adds nothing to the definition to allow for backward compatibility. Therefore, you can pretty much use RowMapper either parameterized or not and no need to use ParameterizedRowMapper.