Date date = new Date();
int lastMonth = date.getMonth();
int lastYear = 1900 + date.getYear();
I have this code in my GWT project but a lot of method of java.util.Date is deprecated, 22/33 methods.
So I want to use Calendar/GregorianCalendar : it does not work. It said there is a missing package.
What is the best practice to replace these line of code with a not deprecated code ?
Don't.
java.util.Calendar is almost impossible to emulate, and has a way too high overhead. java.util.Date, while far from ideal, is the closest to JavaScript's Date, so it's the one you should use in GWT world.
JSR 310 is promising (don't know how well it could be emulated though, and with how much overhead compared to java.util.Date) but isn't there yet.
There's also Joda Time (from the same author as JSR 310, JSR 310 aims at bringing Joda Time to the JDK along with fixing some of its early design mistakes), but most GWT ports have long been abandonned.
In the end: use java.util.Date.
And if you find the deprecation warnings annoying, then suppress them: #SuppressWarnings("deprecated").
java.util.Date is not deprecated! Admittedly many methods of it are (like getMonth and getYear) which I try to avoid using. In the case of GWT you can use something like DateTimeFormat to do date formatting and parsing.
Related
Is there any way to get the current date in Scala without using Java class import java.text.SimpleDateFormat and import java.util.Date?
java.time
You should not be importing java.text.SimpleDateFormat or java.util.Date. Those troublesome old classes are now legacy, supplanted by the java.time classes.
While I do not know Scala syntax, here is Java syntax.
java.time.Instant.now() // Current moment in UTC, with a resolution of nanoseconds.
…and…
java.time.ZonedDateTime.now( ZoneId.of( "Africa/Tunis" ) ) // Current moment adjusted to the wall-clock time as used by the people in a particular region (time zone).
…and…
java.time.LocalDate.now( ZoneId.of( "Pacific/Auckland" ) ) // Current date (date-only, no time-of-day nor zone) of the people in a particular region (time zone).
http://pavkin.ru/cross-platform-polymorphic-datetime-values-in-scala-with-type-classes/
The Goal
There’s no solution without a goal. Precise goal will also provide correct context for reasonings in this article. So let me state it.
My primary goal is to be able to write cross-platform code that operates on date/time values with full time zone support.
This also means that I will need implementation(s) that behave consistently across JVM and browser. We’re Scala programmers, so let’s choose JVM behaviour semantics as our second goal.
Options explored in the article are
https://github.com/scala-js/scala-js-java-time
This library is the future of cross-platform date/time code. It’s effectively Java 8 time, written from scratch for ScalaJS.
At the time of writing this post, scala-js-java-time already provides LocalTime, LocalDate, Duration , and a handful of other really useful java.time.* classes (full list here).
https://github.com/soc/scala-java-time
Scala Java-Time is a fork of ThreeTen backport project. So it’s main purpose is to provide java.time.* -like functionality on Java 6 & 7.
It is also compiled to ScalaJS, which means we can write cross-platform code with it. And we can even use (to some extent) LocalDateTime!
https://github.com/mdedetrich/soda-time
Soda time is a port of Joda to ScalaJS.
It’s in early development stages and also doesn’t have time zones in ScalaJS, but I still added it to the list, because developers took an interesting approach: they are converting original Joda code with ScalaGen.
The author then goes to recommend that at the time of writing the article, (Published 11.11.2016)
There’s no cross-platform library with full time zone support. And for JavaScript runtime there’s only MomentJS, that really fits our requirements.
So unless one of those have evolved, or you only need a subset of datetime functions, or another solution has raised it's head, you are probably stuck implementing some sort of interface over the behavior needed, and swapping it out based on whether you are on java or scalajs.
Well, it's unclear - beside the hint about newer classes mentioned by Basil - why you would do this, need this.
On unix-like systems you can use the System date, probably on Windows systems too, but with the same syntax? You probably loose system independency:
scala> import sys.process._
import sys.process._
scala> "date".!
Mi 31. Jan 07:09:04 CET 2018
res150: Int = 0
If you have a database, these often provide the date/time too.
Then you could try to get the date via TCP/IP.
All this solutions are in allmost all cases inferior to using the newer Java classes and even the older ones.
There is this new-n-cool Date API in Java 8, the java.time package. I understand that it is better designed, less ambiguous and more thread-safe than the old classes. Still, I am not sure how to go about using it:
Should I use it exclusively instead of the old classes?
Should I replace existing usages of old classes whereever I spot them because the new stuff is so much better?
Should I refrain from using java.util.Calendar, java.util.Date, java.sql.Date and java.text.DateFormat in favor of the new API all together OR are there use cases where the old classes are still preferable?
Has the Joda Time API become obsolete thanks to the new Date API similarly to the substitution of Guava FluentIterable by Java 8 stream API?
I know these are a lot of questions, but they feel somewhat related to each other. If somebody can answer the whole bunch, that would be awesome, but good partial answers are also appreciated.
Should I use it exclusively instead of the old classes?
No, no need to exclude old classes. The old java.util.Date/.Calendar work the same, unchanged. The have not been deprecated.
You can mix and match all three frameworks (old classes, Joda-Time, and java.time). Just be careful of some identical or similar class names -- watch your import statements!
See The Tutorial, Legacy Date-Time Code.
Also, the ThreeTen-Extra project extends java.time with additional features. The "ThreeTen" refers to JSR 310 that defines java.time.
Should I replace existing usages of old classes whereever I spot them because the new stuff is so much better?
If the old code is working as intended, then no need to change now.
If you were concerned about that old code possibly not handling time zones properly or have been wanting to do more localization, the you might want to rework them using java.time. Even then, remember that you can easily convert between j.u.Date and Instant. So you could leave your business logic as-is with j.u.Date/.Calendar and change only the user-presentation code to use java.time.
Should I refrain from using java.util.Calendar, java.util.Date, java.sql.Date and java.text.DateFormat in favor of the new API all together OR are there use cases where the old classes are still preferable?
You will need the old classes for interoperation with old code and libraries that expect the old types. Again, the old classes are not deprecated and are not going away. They will probably never go away given their extensive usage and the Java team’s top priority being preservation of backward-compatibility.
The new java.time classes are far superior, that's why they were added. And they are more logical and easier to use. So yes, it would be beneficial and pleasant to learn how to use them. But not urgent. In a crunch, write code the old way you are used to. When you can afford the time to learn (Tutorial) and to perform extra testing, start to use the new classes.
A newbie programmer should certainly focus their learning on java.time.
Has the Joda Time API become obsolete thanks to the new Date API similarly to the substitution of Guava FluentIterable by Java 8 stream API?
Joda-Time was the inspiration for java.time. The same folks invented both. They intend for java.time to be their "2.0" re-invention of Joda-Time, what they would have done then if they knew what they know now. They have said Joda-Time users should transition over to java.time.
That said, Joda-Time is not going away. It is still worked on, still updated with bug fixes and fresh tz time zone data. And it is very important to the large Android community who have no other decent date-time library (that I know of). So you can continue to rely on Joda-Time, no urgent need to rip out old code, but expect no new features or enhancements.
Joda-Time is well-worn and proven while java.time has had a few minor bugs and kinks to work out. Joda-Time and java.time each have features the other lacks. So personally, I mix-and-match to best fit. I rely on Joda-Time while dabbling with java.time.
Plan an eventual transition to java.time but no rush, no panic.
Date has many deprecated methods, i.e, getTime, getMounth, etc. Should I avoid using it?
Also, what is the difference between: Date, Calendarand DataPicker?
Date was deprecated in the JDK v1.1; in other words relatively early during the (ongoing) development of the environment. It was deprecated because of incompatibility with international time standards; while it was intended to reflect coordinated universal time (UTC) it was found that on machines that use the GMT time standard or those that do not reflect a "leap second" (an extra second once every year or two) that the Date class might not be exactly accurate.
For this reason, it is recommended that you use Calendar.get(...) instead of Date's respective methods! Also, Java8 has a UI component, DatePicker, which use's the new LocalDate class (which is a localized replacement for the deprecated Date class).
In my (non-public) applications, I like for my users to be able to enter the date/time in whatever format and then use strtotime() along with date() to translate it to YYYY-MM-DD for DB storage. I know this has a couple of drawbacks (such as how 1/1/13 vs. 1-1-13 might be handled based on locale and such), but over the years these have never been an issue given my user base.
However, there is one issue that I may have to resolve, and that's with handling dates prior to 1970 in one particular application. For obvious reasons, strtotime() doesn't work so well. I know I could use a date-picker, but was wonder if there is a more proper way of handling this that would allow me to do what I've been doing but to handle a wider range of dates.
After posting this, I did some additional testing, and it seems on the system I'm working on right now (Ubuntu 12.04 64-bit), there are no issues with early.. perhaps this is a 64-bit thing?
print date( "Y-m-d", strtotime( "May 5, 1820" ));
Prints 1820-05-05 as I wanted but not as I expected. I'm not sure if this is related to the version of Linux I'm running, the version of PHP I'm running, or what else. But since it hasn't worked this way for me in the past, I don't necessarily feel comfortable dealing with dates like this.
I did find the DateTime object, so I think I'm going to use that approach, especially since it is supposed to handle a much wider range of dates:
$date = new DateTime( "May 5, 1820" );
print $oop->format( "Y-m-d" );
I'll leave my answer unaccepted for a bit in case someone else has a better or more correct solution to this.
Does anyone here try to adopt xtext2 and migrate from xtext1.x to xtext2.0?
It seems xtext2 brings many new atractive features. Such as A Reusable Expression Language and Xtend: A Code Generation Language . Many performance enhancement is made to the Xtext workbench and rename capability. So any one tell you experence about xtext2? Probably this is a bit early question. But I just wait and see.
xtext2 homepage
I updated an existing, not too complex language from Xtext 1 to Xtext 2, and tried to develop a new one using Xtext2 and XBase. I had to re-run the code generation step, and also had to modify the hand-written validators, because the error and warnings locations are to be specified using literals instead of integers. E.g.
error("File does not exist with path: " + path, fileReference, ViatraTestDslPackage.FILE__PATH);
is to be replaced with
error("File does not exist with path: " + path, ViatraTestDslPackage.Literals.FILE__PATH);
Similarly, the workflow has to be changed as well to incorporate some new features: the outline API uses different fragments (outline.OutlineTreeProviderFragment and outline.QuickOutlineFragment), for rename and compare support new fragments are to be added (refactoring.RefactorElementNameFragment and compare.CompareFragment).
With my experiments of XBase it seems, that adding that to a language that already supported some kind of expressions can be labour-intensive, because either old expressions has to be replaced with XBase expressions (or at least altered in a way to make them available in XBase expressions), otherwise you have to maintain two kind of expression support in your code generator or interpreter.
To conclude my answer, I believe, if you have a simple Xtext 1.0 editor, where you mostly relied on the automatically generated features, migrating to Xtext 2.0 seems easy and recommended; however, if you customized a lot of things in manually written code, be careful, because the migration might not be straight-forward, and I have found no real migration guide.
http://www.eclipse.org/Xtext/documentation/2_0_0/213-migrating-from-1.0.php#migrating_from_1_0_x_5_4
I just find this useful link.
Also I do meet some problem especially in serialization module. Luckily in mwe2 file, it leaves a version 1.0 serialization, i use that and fix the problem when using version 2.0 serialization module. Not knowing why..
Another problem is there is a strange bug in the xtext validation. It always complain about ClassCastException. cast from String to QualifiedName error.
It is still early considering the recent release date:
The team have just presented/demo'ed XTend2 in democamps during last month (June 2011).