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.
Related
I reloaded on of my test application classes using Instrumentation#redefineClasses(ClassDefinition) method. When I tried adding a new method in the class file and call it from an existing method. It was not happy to for me to do so. But when I called some existing method and other Java Built-In Library methods, it was working fine.
My question is - Is this limitation known/acknowledged by Oracle or Open JDK implementations? I suspect even if you can redefine/retransform your classes using INstrumentation Manifest.MF file - there must be somre sort of limitations to how far you can go with it.
Does anyone have any experience in this thing?
From Instrumentation.html#redefineClasses:
The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions. The class file bytes are not checked, verified and installed until after the transformations have been applied, if the resultant bytes are in error this method will throw an exception.
So the answer would be no, it's not possible.
Recently we had to upgrade from itext version 5 to version 5.2 since the latter has support for Chinese languages. However one major change in the newer version is that it no longer supports the TextProvidingRenderListener class in the contsructor of PdfTextExtractor class. There was a class we had customized to utilize this feature :
public class CustomLocationAwarePdfRenderListener
implements TextProvidingRenderListener
{
public CustomLocationAwarePdfRenderListener( int lineAlignErrorAllowed)
{
this.lineAlignErrorAllowed = lineAlignErrorAllowed;
reset();
}
However as an outcome there is now no way to use this class and the attribute called lineAlignErrorAllowed which was part of the constructor of the CustomLocationAwarePdfRenderListener. The lineAlignErrorAllowed basically acts as a parameter of scanning the minimum no. of lines before the source is considered as too complex.
Any help on this topic would really be appreciated.
Managed to fix this issue after realizing that the LocationTextExtractionStrategy class in the latest itext version is a worthy replacement for the TextProvidingRenderListener. Although this time we had to extend the class. The only other change that was needed is to alter to code to use the now static PdfTextExtractor class by passing an instance of the LocationTextExtractionStrategy to the getTextFromPage. Had a bit of a struggle searching for the latest itext API reference doc, but got them here finally. (Somehow they show up with some different formatting than regular java API docs but one can live with that).
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
There are at the moment, two ways to mark code as depreacted in java.
Via JavaDoc
/**
* #deprecated
*/
Or as an annotation:
#Deprecated
This is my problem - I find it a bit too much to declare both, when marking a method as deprecated when using Eclipse. I really just want to use one of them.
However does using the annotation give the compiler actual useful additional information?
But only using the annotation, I cannot state why the method is deprecated - I can only do that with JavaDoc, and deprecating a method without specying why is bad.
So, can I only use one of them? Or should I really just learn to specify both?
You should use both. The Annotation allows the compiler to display a warning whenever a deprecated method is used, and the javadoc explains why. Both are important.
As per Oracle's Java Annotations tutorial:
When an element is deprecated, it should also be documented using the Javadoc #deprecated tag...
From the horse's mouth:
NOTE: The Java Language Specification
requires compilers to issue warnings
when classes, methods, or fields
marked with the #Deprecated annotation
are used. Compilers are not required
by the Java Language Specification to
issue warnings when classes, methods,
or fields marked with the #deprecated
Javadoc tag are accessed, although the
Sun compilers currently do so.
So basically, if you want a guarantee that there will be compiler warnings, you need to use the annotation. And because of some API designer's breathtaking incompetence, you need to specify the javadoc tag as well to give an explanation.
Personally, I'd say the annotation is useless and should be omitted until it's fixed, since any good compiler or IDE will display warnings with the javadoc tag as well.
You should write both.
The #Deprecated Anotation is for the Compiler and the #deprecated JavaDoc tag is for the Person who wants to know why this is deprecated.
An example can look like this:
/**
* #deprecated We dont need this Method because ...
*/
#Deprecated
public void doStuff(){..}
You should specify both.
The annotation lets the compiler know about it and trigger warnings when the method is used.
The JavaDoc attribute lets developers know about before they start using it.
These are two very different things!
This can be easily dealt with a good IDE.
Eclipse Neon, for eg. automatically adds #Deprecated annotation, when I create a javadoc #deprecated on a method or field.
So I simply write the javadoc with the appropriate explanation and let the IDE take care of adding the #Deprecated annotation, the minute I save the file.
I'm trying to find a way to check my classes for references of methods with a particular annotation (think "Deprecated").
As far as i see it, analysing byte code won't work because it doesn't contain any annotations.
Using APT doesn't really help because i need the references to the methods, not the annotated methods themselves.
So, what options do i have?
The best i can come up with is compiling a list of the annotated methods followed by a full code analysis, checking every method call against the list.
Is there a way to do that efficiently in an eclipse plug-in or an ant task?
Analysing bytecode will works!
ASM for an example is handling annotation very well.
In another question I asked for a Java parser of the Java language. For my analysis of code I use this one. Perhaps it's good for you, too.
Using the Reflections library, it's simple as:
Reflections reflections = new Reflections("my.package", new MethodAnnotationsScanner());
Set<Method> deprecated = reflections.getMethodsAnnotatedWith(Deprecated.class);