I'd like to produce Partials from Strings, but can't find anything in the API that supports that. Obviously, I can write my own parser outside of the Joda-Time framework and create the Partials, but I can't imagine that the API doesn't already have the ability to do this.
Use of threeten (JSR-310) would be an acceptable solution, but it doesn't seem to support Partials. I don't know whether that is due to its alpha status, or whether the Partial concept is handled in a different manner, which I haven't discovered.
What is the best way to convert a String (2011, 02/11, etc) into a Partial?
I've extended DateTimeParserBucket. My extended class intercepts calls to the saveField() methods, and stores the field type and value before delegating to super. I've also implemented a method that uses those stored field values to create a Partial.
I'm able to pass my bucket instance to DateTimeParser.parseInto(), and then ask it to create the Partial.
It works, but I can't say I'm impressed with Joda-Time - given that it doesn't support parsing Partials out of the box. The lack of DateTimeFormatter.parsePartial(String) is a glaring omission.
You have to start by defining the valid format for Partials which you will be accepting. There is no class which will just take text and infer the best possible match for a Partial. It's way too subjective based on locale, user preference, etc. So there's no way of getting around making a list of all of the valid formats for input. It will be very difficult to make these all mutually exclusive for each other, so there should be priorities. For example, you might want mm/dd and mm/yy to both be valid formats. If I give you the string 02/11, which one should have priority?
Once you've determined exactly the valid formats, you should use DateTimeFormat.forPattern to create a DateTimeFormatter for each one. Then you can use each formatter to try to parseInto a MutableDateTime. Then, go through each field in the MutableDateTime and transfer the value into a Partial.
Unfortunately, there is no better way to handle this in the Joda library.
The ISODateTimeFormat class allows partial printing. As you say, there is no parsing method on DateTimeFormatter (although you can parse to a LocalDate and interpret that).
ThreeTen/JSR-310 has the DateTimeFields class which replaces Partial. Parsing of partials into a CalendricalMerger is supported, however that may not be convertable back into a DateTimeFields yet.
Related
The documentation for BreakIterator.getWordInstance() has options to use it with the Locale parameter, presumably because different locales' end results may vary for methods like (WordInstance, LineInstance, SentenceInstance, CharacterInstance)
But, when I do not use this parameter, I still get the same results as I get when calling it with any Locale in getAvailableLocales().
Is there some pattern, String, or Locale which actually causes these methods to give different results?
I believe all "western" languages have the same rules.
Cursory scan shows that locale th (Thai) has it's own rules, given in file /sun/text/resources/th/WordBreakIteratorData_th inside .../jre/lib/ext/localedata.jar.
It's a binary file, so I don't know what it says, and even if I could understand the file, not knowing Thai, I still wouldn't understand it.
I am writing some app in which I use integer to represent different types of semantics. For example, I use int to represent both month and year, and I want to avoid accidentally using variables with one semantic in the context requiring the other. I want to use annotation to annotate variables representing month with #Month and ones representing year with #Year, and would like compiler to warn me if unexpected assignment or method call. How do I implement that?
BTW: I don't want to introduce additional classes Month and Year because it is not as efficient and kind of verbose in syntax, e.g. I need to call month.get() to use it where an int is expected, and new Month(m) to create.
I tried to search online but don't find enough document. Any ideas?
I was frustrated recently in this question where OP wanted to change the format of the output depending on a feature of the number being formatted.
The natural mechanism would be to construct the format dynamically but because PrintStream.format takes a String instead of a CharSequence the construction must end in the construction of a String.
It would have been so much more natural and efficient to build a class that implemented CharSequence that provided the dynamic format on the fly without having to create yet another String.
This seems to be a common theme in the Java libraries where the default seems to be to require a String even though immutability is not a requirement. I am aware that keys in Maps and Sets should generally be immutable for obvious reasons but as far as I can see String is used far too often where a CharSequence would suffice.
There are a few reasons.
In a lot of cases, immutability is a functional requirement. For example, you've identified that a lot of collections / collection types will "break" if an element or key is mutated.
In a lot of cases, immutability is a security requirement. For instance, in an environment where you are running untrusted code in a sandbox, any case where untrusted code could pass a StringBuilder instead of a String to trusted code is a potential security problem1.
In a lot of cases, the reason is backwards compatibility. The CharSequence interface was introduced in Java 1.4. Java APIs that predate Java 1.4 do not use it. Furthermore, changing an preexisting method that uses String to use CharSequence risks binary compatibility issues; i.e. it could prevent old Java code from running on a newer JVM.
In the remainder it could simply be - "too much work, too little time". Making changes to existing standard APIs involves a lot of effort to make sure that the change is going to be acceptable to everyone (e.g. checking for the above), and convincing everyone that it will all be OK. Work has to be prioritized.
So while you find this frustrating, it is unavoidable.
1 - This would leave the Java API designer with an awkward choice. Does he/she write the API to make (expensive) defensive copies whenever it is passed a mutable "string", and possibly change the semantics of the API (from the user's perspective!). Or does he/she label the API as "unsafe for untrusted code" ... and hope that developers notice / understand?
Of course, when you are designing your own APIs for your own reasons, you can make the call that security is not an issue. The Java API designers are not in that position. They need to design APIs that work for everyone. Using String is the simplest / least risky solution.
See http://docs.oracle.com/javase/6/docs/api/java/lang/CharSequence.html
Do you notice the part that explains that it has been around since 1.4? Previously all the API methods used String (which has been around since 1.0)
I'm looking for some info on the best approach serialize a graph of object based on the following (Java):
Two objects of the same class must be binary equal (bit by bit) compared to true if their state is equal. (Must not depend on JVM field ordering).
Collections are only modeled with arrays (nothing Collections).
All instances are immutable
Serialization format should be in byte[] format instead of text based.
I am in control of all the classes in the graph.
I don't want to put an empty constructor in the classes just to support serialization.
I have looked at implementing a solution based my own traversal an on Objenisis but my problem does not seem that unique. Better checking for any existing/complete solution first.
Updated details:
First, thanks for your help!
Objects must serialize to exactly the same bit order based on the objects state. This is important since the binary content will be digitally signed. Reconstruction of the serialized format will be based on the state of the object and not that the original bits are stored.
Interoperability between different technologies is important. I do see the software running on ex. .Net in the future. No Java flavour in the serialized format.
Note on comments of immutability: The values of the arrays are copied from the argument to the inner fields in the constructor. Less important.
Best regards,
Niclas Lindberg
You could write the data yourself, using reflections or hand coded methods. I use methods which are look hand code, except they are generated. (The performance of hand coded, and the convience of not having to rewrite the code when it changes)
Often developers talk about the builtin java serialization, but you can have a custom serialization to do whatever you want, any way you want.
To give you are more detailed answer, it would depend on what you want to do exactly.
BTW: You can serialize your data into byte[] and still make it human readable/text like/editable in a text editor. All you have to do is use a binary format which looks like text. ;)
Maybe you want to familiarize yourself with the serialization frameworks available for Java. A good starting point for that is the thift-protobuf-compare project, whose name is misleading: It compares the performance of more than 10 ways of serializing data using Java.
It seems that the hardest constraint you have is Interoperability between different technologies. I know that Googles Protobuffers and Thrift deliver here. Avro might also fit.
The important thing to know about serialization is that it is not guaranteed to be consistent across multiple versions of Java. It's not meant as a way to store data on a disk or anywhere permanent.
It's used internally to send classes from one JVM to another during RMI or some other network protocol. These are the types of applications that you should use Serialization for. If this describes your problem - short term communication between two different JVM's - then you should try to get Serialization going.
If you're looking for a way to store the data more permanently or you will need the data to survive in forward versions of Java, then you should find your own solution. Given your requirements, you should create some sort of method of converting each object into a byte stream yourself and reading it back into objects. You will then be responsible for making sure the format is forward compatible with future objects and features.
I highly recommend Chapter 11 of Effective Java by Joshua Bloch.
Is the Externalizable interface what you're looking for ? You fully control the way your objects are persisted and you do that the OO-style, with methods that are inherited and all (unlike the private read-/write-Object methods used with Serializable). But still, you cannot get rid of the no-arg accessible constructor requirement.
The only way you would get this is:
A/ USE UTF8 text, I.E. XML or JSON, binary turned to base64(http/xml safe variety).
B/ Enforce UTF8 binary ordering of all data.
C/ Pack the contents except all unescaped white space.
D/ Hash the content and provide that hash in a positionally standard location in the file.
What is really meant when using Java Date utilities and something has been deprecated. Does this mean that it is discouraged to use, or does it imply that it is forbidden?
I am guessing it is bad practice to use deprecated methods, but am not sure and wanted to find out.
For example, I am trying to use code such as the following
String date = request.getParameter("date");
model.setDate(new Date(date));
Of course...this is a high level example, but in this situation, my model uses type Date and I need to pull the date off the request as a String and create a date with it.
It works fine how I have it, but it is using a deprecated method.
EDIT - I have gone back and used
SimpleDateFormat formatter = new SimpleDateFormat();
model.setDate(formatter.parse(request.getParameter("date");
The date is in the format MM/DD/YYY like 07/23/2010 but I am getting a ParseException
What could this be from?
You're right that this is bad practice. In almost all cases, deprecated methods tell you what to use instead, and this is no exception (see the Javadocs).
You're trying to create a Date out of a String. But what format is the String in? How should it be parsed? Is it UK or US date format?
The "proper" way to do this is to create an instance of SimpleDateFormat, and call its parse() method passing in your text string. This is guaranteed to work in future, and will be more robust now.
A lot of people have mentioned what Deprecated means, but I don't see any explanation of why these methods are deprecated:
Sun (before they were part of Oracle) deprecated a number of methods in Date to get people to use the Calendar/GregorianCalendar classes for date manipulation instead.
Deprecated objects or methods merely means that if you want to use it in current project, rather use what is recommended. The reason why they still have it is for legacy codes who have used the deprecated method before it was deprecated. Typical example is StringTokenizer vs String.split() method.
For your Date example use SimpleDateFormat to do conversion from String to Date. This allows you to create a date format from which your string date can be parsed to create a Date object.
For your EDIT do this
SimpleDateFormat formatter = new SimpleDateFormat("MM/dd/yyyy");
model.setDate(formatter.parse(request.getParameter("date")));
ParseException is caused since you didn't provide a date format structure so the SimpleDateFormat didn't know how your date was structured.
What "Deprecated" Means
You may have heard the term,
"self-deprecating humor," or humor
that minimizes the speaker's
importance. A deprecated class or
method is like that. It is no longer
important. It is so unimportant, in
fact, that you should no longer use
it, since it has been superseded and
may cease to exist in the future.
Java provides a way to express
deprecation because, as a class
evolves, its API (application
programming interface) inevitably
changes: methods are renamed for
consistency, new and better methods
are added, and fields change. But such
changes introduce a problem. You need
to keep the old API around until
developers make the transition to the
new one, but you don't want them to
continue programming to the old API.
The ability to deprecate a class,
method, or member field solves the
problem. Java supports two mechanisms
for deprecation: and an annotation,
(supported starting with J2SE 5.0) and
a Javadoc tag (supported since 1.1).
Existing calls to the old API continue
to work, but the annotation causes the
compiler to issue a warning when it
finds references to deprecated program
elements. The Javadoc tag and
associated comments warn users against
using the deprecated item and tell
them what to use instead.them what to use instead.
http://download-llnw.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html
You are right, Its discouraged to use deprecated methods.
This is because these methods may have issues in some situation or have been replaced with more optimistic solutions And also future versions may not support these.
Deprecated means it is planned for removal, because it is buggy or some other bad reason.
It is better to use SimpleDateFormat.parse(); to parse your strings.
In general, when Sun (Oracle, whatever) declares a Java method deprecated, it means that they changed their minds about including it, they discourage you from using it, and they may remove it in some future version. Of course it's likely to be a long time before it gets removed as who knows how much existing code there is out there using it, and what's the point of breaking existing programs just because the inventors of Java think they now have a better idea about how to do something?
Presumably they had a good reason for deprecating something, so you should investigate WHY they say that some newer function is better.
In the case of deprecated Date methods, usually this means that they suggest you now use the Calendar or SimpleDateFormat classes. In your case, probably the latter.
deprecated: something that exists in the current version of Java, but will be removed from future versions at some point.
For your edit, you need to properly initialize the SimpleDateFormat, so it knows what format is coming in. For 07/22/1978 format:
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy");
As other said, the java.util.Date methods were deprecated because the Java team believed they had a better solution in the java.util.Calendar.
Unfortunately that class also proved to be confusing, troublesome, and poorly designed.
So, yes, you should avoid deprecated methods in deference to their replacements. But now those replacements (.Calendar) have a replacement (java.time).
java.time
All the old date-time classes have been supplanted by the java.time framework built into Java 8. The new classes are inspired by the highly successful Joda-Time framework, intended as its successor, similar in concept but re-architected. Defined by JSR 310. Extended by the ThreeTen-Extra project. See the Tutorial.
Use the java.time.format package for parsing and generating String representations of date-time values.
String input = "07/23/2010";
DateTimeFormatter formatter = DateTimeFormatter.ofPattern( "MM/dd/yyyy" );
The new classes include LocalDate for representing a date-only value without time-of-day.
LocalDate localDate = LocalDate.parse( input , formatter );
If you call toString on a LocalDate you get a String representation of the date value in the standard ISO 8601 format, YYYY-MM-DD. To generate a String in other formats, define another formatter. Or call the 'localize' methods to let java.time do the heavy lifting in determining a particular localized format.
Nothing will break if you use them...yet.
But they may well be removed in future versions.