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.
I have seen some references refer to a access modifier in Java called private protected (both words together):
private protected someMethod() {
}
One of the pages I found referring to this is here. My school lesson also referred to this access modifier (and said it exists). Using it, however, results in an error in the Java language.
I tried with both variables and methods and I'm pretty sure it doesn't exist, but I want an explanation of what happened. Was it considered, then rejected? Or did it get removed in a newer version of Java?
Edit: I am not looking for info about the protected keyword.
Removal of the access modifier
Java did originally have the private protected modifier, but it was removed in JDK 1.0.2 (the first stable version, the Java 1.0 we know today). A few tutorials regarding JDK 1.0.2 (here and here) say the following:
Note: The 1.0 release of the Java language supported five access levels: the four listed above plus private protected. The private protected access level is not supported in versions of Java higher than 1.0; you should no longer be using it in your Java programs.
Another answer on SoftwareEngineering.SE states:
Java originally had such a modifier. It was written private protected but removed in Java 1.0.
Now take a look at the Java Version History:
JDK 1.0
The first version was released on January 23, 1996 and called Oak. The first stable version, JDK 1.0.2, is called Java 1.
From this, we can conclude the tutorials regarding version 1.0.2 refer to the very first version, JDK 1.0, where the language was called Oak, but the one from SoftwareEngineering.SE refers to the first stable version, JDK 1.0.2 called Java 1.0, where it was removed.
Now if you try to search for it in the Java 1.0 documentation, you won't find it, because as mentioned earlier, it was removed in JDK 1.0.2, otherwise known as Java 1.0. This is proven again when you look at the "Last Modified" times for the link you posted. The link you posted was last modified in February of 1996. Java 1.0/JDK 1.0.2, when private protected was removed, was released after February of 1996, and according to the specification, August of 1996.
Reason for removal
Some sources also explain the reason for private protected, such as this one. To quote:
What was private protected?
Early on, the Java language allowed for certain combinations of modifiers, one of which was private protected. The meaning of private protected was to limit visibility strictly to subclasses (and remove package access). This was later deemed somewhat inconsistent and overly complex and is no longer supported.[5]
[5] The meaning of the protected modifier changed in the Beta2 release of Java, and the private protected combination appeared at the same time. They patched some potential security holes, but confused many people.
And the SoftwareEngineering.SE also supports this, by saying that it wasn't worth the inconsistencies and extra complexity, so it was removed early on.
Interpretation
My interpretation of all this is that maybe, back in the Oak days, both were allowed to coexist (hence the combination). Since protected's meaning had changed1, there may have been a need for allowing private and protected at the same time. The introduction became too complex and wasn't worth it, and was thus dropped in the end. By the time Java 1.0/JDK 1.0.2 rolled around, it had been dropped and thus cannot be found in the documentation.
1In the Oak Language Specification, Section 4.10, Access to Variables and Methods, it is noted that the default modifier was protected:
By default all variables and methods in a class are protected.
This is quite different from what we have today, the default package access. This may have paved the way for the need of private protected, because private was too restrictive and protected was too lenient.
There are confusing/unclear stories:
One, from the Princeton source you put, and also from MIT archives, states that:
Note: The 1.0 release of the Java language supported five access
levels: the four listed above plus private protected. The private
protected access level is not supported in versions of Java higher
than 1.0; you should no longer be using it in your Java programs.
But this feature is not specified on any official documentation for Java 1.0 here or here.
My guess is that this feature didn't make it to the official 1.0 version, since the official language specification is from August 1996 and Princeton source was last modified on February 1996.
PS: shame on Oracle for removing the archives for older versions.
As the link you provided in your question suggests private protected was used on an element/member of a class, when you want your subclass to be able access the element but keep it hidden from other classes in its package.
Java if compared to C++ has an extra concept of encapsulating elements - and that is a Package. One should also understand what is accessible within or outside a package in Java when it comes to these access-specifiers like private, public & protected.
Please note that I have explained why it was used. Not in current version of course
No, you can't use both private a protected together. Your tutorial is strange. What you do have is so called package private or in ot6 references package protected access. This is default access that is enabled when no acc6 qualifier is written explicitly.
Private scope is withing the existing class. Wherein Protected can be access within package and class extended by classes in other packages.
Seamlessly if you want your variable/methods to be access outside the package you need to define as protected/public otherwise private or some other access specifiers.
Protected methods are usually accessible from outside package and within sub-classes, i.e a class has to extend respective class to avail protected defined methods.
Private methods/variables have scope within the class.They cant be accessible outside the class.
Hence you can't define Private Protected at a same time!
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).
in lucene 4.3.1 there was an interface StandardTokenizerInterface and a number of classes implement this class, such as StandardTokenizerImpl and ..... this interface doesn't exist in solr 5.3.1... what is the replacement of this class in solr 5.3.1?
The interface was not replaced, it was removed entirely, as it was deemed to no longer serve a useful purpose, due to the changes in how backwards compatibility is handled (instead of passing in a version arg, you would just use StandardTokenizer40, for instance). Ticket here: LUCENE-6000
The calls specified in the interface are still used in pretty much the same way by the current StandardAnalyzerImpl though, as far as I can tell.
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.