I am using netbeans 7.2. the IDE is applying a line-through to a class name, what does it means and how can I resolve it?
Date cookiedate = new Date(timeStamp);
see the shot how its looking
I suspect it means it's deprecated. See here for more info.
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.
I would suggest using Joda-Time instead (with respect to the suggestions made by other posters here), since the Date/Calendar stuff that isn't deprecated is such a pain to use (non-untuitive api, mutable, thread-unsafe)
new Date(timeStamp);
You are using parameterized constructor of Date class which is deprecated, so you see that line cross. In fact most of the methods of Date class is now deprecated.
See documentation of Date class which clearly marks the parameterized constructor as Deprecated.
Date(String s)
Deprecated.
As of JDK version 1.1, replaced by
DateFormat.parse(String s).
I would rather suggest to use Joda Time API if you want to make your life easier while working with Dates.
It means the API you are invoking is deprecated, you should use Calendar API for example or if you are looking for a more sophisticated API I suggest to use Joda
Linethrough means it is deprecated. There is some other class/method available in place of that class/method. And also Netbeans shows somewhere around that deprecated class/method what you can use use instead of it if you have javadoc set up in it
Related
I am doing an OCR project. getInstance() in tess4j is deprecated. I can't use Tesseract.Tesseract() even which gives an error. How can I solve this?
Code with Tesseract.getInstance()
Code with Tesseract.Tesseract()
[![Code with Tesseract.Tesseract()][2]][2]
This is what is displayed when I compiled the program after I inserted
Tesseract tess = new Tesseract() ;
enter image description here
Deprecated methods can still be used. The #Deprecated annotation just means that the library developer plans to stop supporting this method (or remove it from the library) in a future release.
More precisely, from the #Deprecated documentation,
A program element annotated #Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists.
You may want to check these out:
What does it mean for a method to be deprecated?
The constructor Date(...) is deprecated. What does it mean? (Java)
Is it wrong to use Deprecated methods or classes in Java?
How and When To Deprecate APIs (Oracle official documentation)
What does the deprecated API warning mean?
It is not a good practice, however, to use deprecated methods and classes, as they may lead to future bugs and compilation problems in your system if the methods or classes are removed and you update the library versions.
However, in your case, Tesseract() is a class constructor. You are making the wrong call, as the correct one would be
Tesseract instance = new Tesseract();
Have a look at the Tess4j documentation to learn more about the Tesseract class.
Tesseract() is a constructor, so you need to use new Tesseract() to get one.
We have an existing product that is very time sensitive. For example, statistics are published on a 5 min, 1 hour, 24 hour basis. This means testing is very slow in real world conditions (we actually don't test the 1 hour and 24 hour statistics because of this).
What I want is to speed up the JVM clock.... I know I could create a dummy time class as I've seen others do. But the code base is huge so this would be a lot of retrofit work + third party libs would still use the normal Date Class/System.getCurrentTimeInMillis...
What I'm really looking for is a way to override the Java time behavior (monkey patching in the ruby world). I'm guessing it should be possible to use byte code manipulation to do this. But I'm not sure where to start.... I can't find any libraries that do this or anyone who has solved this problem via byte code manipulation.
question 1: is it possible to override the Date behavior?
question 2: how would one do this? Perhaps an example of overriding another core java class?
thanks for any thoughts
Modify the system time (disable ntpd if in use), Java time will reflect accordingly.
There are two main approaches. Modify the Date class itself, or modify all references to it.
The Date class is part of the standard library, so it's given a privileged status. The only way I can think of to modify it is to actually modify the system jar. You can either put your modified jar in the normal location or tell the JVM to look elsewhere. Note that this is not officially supported by Oracle and is only really feasible for personal use.
The other approach is to modify all your classes to reference a mocked version of the class. Even in a large codebase, you can do this with a simple script. If you only care about normal references you can do this either statically or dynamically (as classes are loaded).
If you're worried about accessing Date via reflection, doing it dynamically is the only option. Typically you would use a custom class loader with ASM to do bytecode rewriting. In order to capture reflection, you would have to mock out all the reflection classes and replace references to those too. This gets pretty tricky, especially when you consider the possibility of using reflection to access reflection to access Date, but it's possible.
Also, note that bytecode rewriting won't let you mess with the system classes because they use the hardcoded system classloader. So if another system class references Date, it will use the unmodified version.
I believe Java Agents can also be used to do bytecode rewriting without the need for a custom classloader, but I don't have experience with this.
Java 8
Java 8 includes a new java.time.* package, defined by JSR 310, inspired by Joda-Time (but re-architected).
These new classes supplant the notoriously troublesome classes of java.util.Date, java.util.Calendar, and java.text.SimpleDateFormat.
Mock Clock
Amongst the new classes is the abstract class, Clock.
The designers had exactly your need in mind, a pluggable replacement for the system clock to create fake "mock" date-time values to facilitate testing. The Clock class is meant to be extended by you (or others) for whatever unnatural behavior you desire. Pass an instance of that altered clock to the other java.time.* classes. Those other classes will use your Clock as a source of date-time data rather than the computer/JVM's real clock.
Joda-Time
Looks like Joda-Time may have something similar. Read this discussion about a "MillisProvider". Apparently referring to DateTimeUtils.MillisProvider.
C#'s extension methods are great for adding syntactic sugar. Java extension methods are great for allowing library developers to add methods to their interfaces.
I am a non-library Java developer and know I will reap a lot of benefits from getting new functionality from libraries, but I would still like to have the syntactic sugar capabilities of C# extension methods.
Is this, or will this be possible in future versions of Java?
eg: I would like to add methods to the String class...
String data = StringUtils.capitalize("abcd"); // instead of this
String data = "abcd".capitalize() // I would like to do this
Please don't focus on this particular example, I am only showing the class of functionality I want to be able to achieve.
Java does not have this feature, nor is it likely to have it anytime soon.
Groovy however does have a very similar feature, and it also runs on the JVM. Perhaps that's an option.
I suspect you're thinking of a planned addition to Java 8 that will allow you to add methods, with default implementations, to an interface -- so that you can add new methods without breaking all existing code. This is only of use to you if you control the interface type -- so it would not be of use for String, because String is not an interface.
Documentation for the constructor new Boolean(boolean value) in Java states:
Note: It is rarely appropriate to use this constructor. Unless a new instance is required, the static factory valueOf(boolean) is generally a better choice. It is likely to yield significantly better space and time performance.
If so, why is this constructor public and not deprecated? Is there ever a good reason to use this constructor instead of Boolean.valueOf()?
valueOf() only got added in Java 1.4, so it would appear that the constructors exist for backwards compatibility.
This ticket explains the reasons for not deprecating the constructors:
Due to the disruption deprecating an API can have, currently an API
has to be "actively hazardous" to be deprecated, like Thread.stop.
While the use this constructor is certainly ill-advised, it doesn't
rise (or sink) to the standard of hazardousness to be deprecated in
the JDK. In the future we may add a "denigration" facility to mark
API elements that aren't quite so bad that they should be deprecated,
but shouldn't be used in most cases. This constructor would be a good
candidate for denigration.
I can't think of a realistic scenario where using Boolean constructors would be the best way to do something useful.
Usually, you will want to use valueOf(boolean) or even the Boolean.TRUE / Boolean.FALSE constants directly.
But think of a scenario where you want to use a private Boolean variable as a monitor for synchronizing threads. There you will need to make sure you use your own instance and have full control of it.
Another, not necessarily good reason would probably be to simply keep it consistent with the other native wrappers.
As of Java 9, the Boolean(boolean) constructor has been deprecated; see javadoc.
For those who care about the history, there was a longstanding bug that called for the deprecation of the constructor. It was formally proposed in JEP 277 along with a number of other deprecations.
The reason it hasn't been deprecated is that Java maintains backwards compatibility to version 1.0
I can't think of a good reason to use the constructor.
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.