Prevent using some APIs of a depending package - java

We have some code wrapping API of a third-party package, and now we don't want our team members to mistakenly use the third-party package directly, is there any way to prevent it? (Such as add some kind of checking in UT). Example:
Code in a third-party package (so we cannot change it):
class OrigProvider {
public static String getSomething() { return sth;}
}
Code in my package (we need to third-party package):
class MyProvider {
public static String getSomething() {
sth = OrigProvider.getSomething;
process(sth);
return sth;
}
}
And in our code, if someone incorrectly use OrigProvider.getSomething, our program will be wrong silently, so how to guarantee no one use the OrigProvider.getSomething?
Thanks in advance!

Related

Java Application return super class when initialized

Nowadays we are on writing some core application that is all other application will be relying on. Without further due let me explain the logic with some codes,
We used to have a single java file that was 1000+ lines long and each application was having it as class inside, so when there was a change, each application had to edit the java file inside of it or simply fix one and copy to all. This is hard to implement as much as it is hard to maintain. Then we end-up with creating this as a separate application that is divided to smaller part, which is easy to maintain and also a core maybe a dependency to other application so we fix in one place and all other code applications are fixed too.
I've been thinking for a some great structure for this for a while want to use a builder patter for this as below
TheCore theCore = new TheCore().Builder()
.setSomething("params")
.setSomethingElse(true)
.build();
The problem arises now. Like so, I initialized the object but now I'm having access to that objects public class only. This application actually will have many small classes that has public functions that I don't want them to be static methods that can be called everytime. Instead I want those methods to be called only if TheCore class is initilized like;
// doSomething() will be from another class
theCore.doSomething()
There are some ideas I produced like
someOtherClass.doSomething(theCore)
which is injecting the main object as a parameter but still someOtherClass needs to be initialized or even a static method which doesn't make me feel comfortable and right way to that.
Actually I do not care if initializing TheCore would bring me a super object that includes all other classes inside initialized and ready to be accessed after I initialized TheCore. All I want in this structure to have a maintainable separate app and methods avaiable if only the main object which is TheCore is this circumstances is initialized.
What is to right way to achive it? I see that Java does not allow extending multiple classes even it if does, I'm not sure it that is right way...
Thanks.
After spending significant amount of time of thought I ended up that
// doSomething() will be from another class
theCore.doSomething()
is not suitable since many java classes could possibly have identical method names. So...
// doSomething() will be from another class
theCore.someOtherClass.doSomething()
would be a better approach.
To make it easier to understand I'll have to follow a complex path to explain it which is starting from the package classes first.
Think that I have a package named Tools and a class inside SomeFancyTool
main
└─java
└─com
└─<domainName>
├─Tools
| └─SomeFancyTool.java
└─TheCore.java
Now this SomeFancyTool.java must have a default access level which is actually package level access, because I don't want this classes to be accessed directly;
SomeFancyTool.java
package com.<domainName>.Tools
class SomeFancyTool{
public String someStringMethod(){
return "Some string!";
}
public int someIntMethod(){
return 123;
}
public boolean someBooleanMethod(){
return true;
}
}
So now we have the SomeFancyTool.java class but TheCore.java cannot access it since it is accesible through its Tools package only. At this point I think of an Initializer class that is gonna be in the same package, initialize these private classes and return them with a function when called. So initiliazer class would look like this;
ToolsInitializer.java
package com.<domainName>.Tools
public class ToolsInitializer{
private SomeFancyTool someFancyTool = new SomeFancyTool();
public SomeFancyTool getSomeFancyTool(){
return someFancyTool;
}
}
Since ToolsInitializer.java can initialize all functional private classes inside in Tools package and also can return them as objects to outside of the package scope, still we are not able to use these methods as we cannot import com.<domainName>.SomeFancyTool from TheCore.java because it is package wide accessible. I think here we can benefit from implementation of the java interface. A class that is not functional alone, so no problem even if it is accessed since it's methods will be nothing but declarations.
At this point I'll rename SomeFancyTool.java to SomeFancyToolImplementation.java which it will be implementing the interface and call SomeFancyTool.java to the interface itself.
SomeFancyTool.java (now as an interface)
package com.<domainName>.Tools
public interface SomeFancyTool{
public String someStringMethod();
public int someIntMethod();
public boolean someBooleanMethod();
}
and lets rename prior SomeFancyTool.java and implement the interface
SomeFancyToolImplementation.java (renamed)
package com.<domainName>.Tools
class SomeFancyToolImplementation implements SomeFancyTool{
#override
public String someStringMethod(){
return "Some string!";
}
#override
public int someIntMethod(){
return 123;
}
#override
public boolean someBooleanMethod(){
return true;
}
}
Now our structure has become like this with the final edits;
main
└─java
└─com
└─<domainName>
├─Tools
| ├─SomeFancyTool.java
| ├─SomeFancyToolImplementation.java
| └─ToolsInitializer.java
└─TheCore.java
Finally we can use our TheCore.java class to call all initializer classes with their methods to receive all these private classes inside as an object. This will allow external apps to call and initialize TheCore first to be able to access other methods.
TheCore.java
public class TheCore{
private SomeFancyToolImplementation someFancyTool;
public static class Builder{
private SomeFancyToolImplementation someFancyTool;
public Builder(){
ToolsInitializer toolsInitializer = new ToolsInitializer();
someFancyTool = toolsInitializer.getSomeFancyTool();
}
public Builder setSomeValues(){
//some values that is needed.
return this;
}
public Builder setSomeMoreValues(){
//some values that is needed.
return this;
}
public TheCore build(){
TheCore theCore = new TheCore();
theCore.someFancyTool = someFancyTool;
return theCore;
}
}
}
All Done and it is ready to use. Now the functional package classes and its methods that it relying on if TheCore is initialized or not, cannot be accessed with out TheCore. And simple usage of this Library from a 3rd Party app would simply be;
3rd Party App
TheCore theCore = new TheCore.Builder()
.setSomeValues("Some Values")
.setMoreSomeValues("Some More Values")
.build();
theCore.someFancyTool.someStringMethod();
Note: Note that a the ToolsInitializer.java is still accessible and could be used the get private method without first calling TheCore but we can always set a checker inside getSomeFancyTool() method to throw error if some prerequisites are not satisfied.
I do not still know if this is a functional structural pattern to use or its just some hard thoughts of mine. And don't know if some pattern is already exist that I just could not see yet but this is the solution I end up with.

How to append a method to existing class using annotation processing in java / kotlin?

I'm new to annotation processing and code generation. I want to find out how can I perform such operation like appending new method to existing class. Here is an example of what I want to do:
Assume that we have a class with with custom annotations like this one:
class SourceClass {
#CustomAnnotation
fun annotatedFun1(vararg argument: Any) {
//Do something
}
#CustomAnnotation
fun annotatedFun2(vararg argument: Any) {
//Do something
}
fun someOtherFun() {
//Do something
}
}
And the result I want to get - extended copy of that class:
class ResultClass {
fun hasFunWithName(name: String): Boolean {
return (name in arrayOf("annotatedFun1", "annotatedFun2"))
}
fun callFunByName(name: String, vararg arguments: Any) {
when (name) {
"annotatedFun1" -> annotatedFun1(*arguments)
"annotatedFun2" -> annotatedFun2(*arguments)
}
}
fun annotatedFun1(vararg argument: Any) {
//Do something
}
fun annotatedFun2(vararg argument: Any) {
//Do something
}
fun someOtherFun() {
//Do something
}
}
I've already found out how to create annotation processor. I'm looking for a method to save all existing fields, properties and methods in source class and to append a few more methods to it.
If it is possible to modify class without creating new one - it would be perfect, but in all tutorials only new classes are created and I didn't find any example where all contents of source class are being copied to another one.
Please, do not advise to use reflection. I need this for android and so reflection is not the option cause of resources cost. I'm looking for compile-time solution.
It is required for custom script language implemented in app and should be used to simplify wrapper classes structure. When this job is done directly in code - it looks awful when such method count exceeds 20 per class.
Here is a good example of Java Annotation Processing I recently worked with.
It's an implementation of #Immutable annotation.
Check out ByteBuddy or Kotlin Poet to understand how additional code generation works.
For Kotlin you do almost the same, check this manual for Kotlin-specific steps.
With Kotlin, you can use extension functions and that is the recommended way of adding new functionality to existing classes that you don't control. https://kotlinlang.org/docs/reference/extensions.html
You may be abel to follow the pattern used by Project Lombok. See How does lombok work? or the source code for details.
Another option would be to write a new class that extends your source class:
class ResultClass : SourceClass {
fun hasFunWithName(name: String): Boolean {
return (name in arrayOf("annotatedFun1", "annotatedFun2"))
}
fun callFunByName(name: String, vararg arguments: Any) {
when (name) {
"annotatedFun1" -> annotatedFun1(*arguments)
"annotatedFun2" -> annotatedFun2(*arguments)
}
}
}
Or perhaps use composition instead and implemnent cover methods for all the public methods in SourceClass.
If you are not tied to doing this using annotation processing, you could use a separate piece of custom code to process the source code files before compiling. Maybe use a regular expression like /#CustomAnnotation\s+.*fun (\w+)\s*\(([^)]*)\)/gm (Test on Regex101) to find the annotated methods.
If I understood the requirement correctly, the goal is to implement something like described below.
You have a source file C.java that defines the class C like this:
public final class C
{
#Getter
#Setter
private int m_IntValue;
#Getter
#Constructor
private final String m_Text;
}
And now you want to know how to write an annotation processor that jumps in during compilation and modifies the source from C.java that the compiler sees to something like this:
public final class C
{
private int m_IntValue;
public final int getIntValue() { return m_IntValue; }
public final void setIntValue( final int intValue ) { m_IntValue = intValue; }
private final String m_Text;
public final String getText() { return m_Text; }
public C( final String text ) { m_Text = text; }
}
The bad news is, that this is not possible … not with an annotation processor, not for Java 15.
For Java 8 there was a way, using some internal classes with reflection to convince the AP to manipulate the already loaded source code in some way and let the compiler compile it a second time. Unfortunately, it failed more often than it worked …
Currently, an annotation processor can only create a new (in the sense of additional) source file. So one solution could be to extend the class (of course, that would not work for the sample class C above, because the class itself is final and all the attributes are private …
So writing a pre-processor would be another solution; you do not have a file C.java on your hard drive, but one named C.myjava that will be used by that preprocessor to generate C.java, and that in turn is used by the compiler. But that is not done by an annotation processor, but it may be possible to abuse it in that way.
You can also play around with the byte code that was generated by the compiler and add the missing (or additional) functionality there. But that would be really far away from annotation processing …
As a summary: today (as of Java 15), an annotation processor does not allow the manipulation of existing source code (you cannot even exclude some source from being compiled); you can only generate additional source files with an annotation processor.

Creating Custom Java Compiler Errors Without Using Annotations

Is there a way to add processors to the compiler without making annotations?
Basically, I would like for the build to fail if a user did not implement an interface correctly (ie. postconditions are not fulfilled). At compile time, I would like to check if a class implements an interface, and if it does, run some code to check if the implementation is correct.
For example, I would like to ensure that classes that implement getErrorMoniker() return a string in camelCase.
public interface MyError {
public String getErrorMoniker();
}
public class MyErrorImplemented1 {
#Override
public String getErrorMoniker() { return "goodErrorMoniker"; }
}
public class MyErrorImplemented2 {
#Override
public String getErrorMoniker() {
return "BADERRORMONIKER"; // I would like a compile error here
}
}
Any suggestions would be appreciated.
A processor annotated with #SupportedAnnotationTypes("*") should in theory be able to processs all source files as it also applies to an empty set of annotations. From the documentation:
If there are no annotation types present, annotation processing still occurs but only universal processors which support processing "*" can claim the (empty) set of annotation types.
Although you goal to check for return values probably won't work, since this happens compile time, not runtime.

adding functions to main class from a different class using bean configuration if possible

I'm writing a red5 application in Java. it just means that I have a bean that points to my main class app class that's called Application.
I have several classes that I want to add and remove like modules to my application.
example:
I have two classes called 'A' and 'B', each one of them contains the public function testme().
I want somehow to configure that my main Application class will call the constructor of these two classes and that somehow my main Application class will contains the functions Atestme() and Btestme() that will call the appropriate testme() function in the appropriate class. is there a way to achieve such a thing without me manually creating these functions and calling the appropriate function within one of the classes?
Is there a way to use bean configuration to achieve such a goal ? (I want to be
able to configure adding and removing 'modules' using bean configuration if possible)
I started reading about reflections, and it says that adds performance overhead and I should avoid for production environments that are time and cpu sensitive.
is there a way to catch when aDoTest() or bDoTest() is called in my main class and to catch it in order to call the appropriate functions ?
How about this:
public class Application {
public static void aDoTest() {
doTest(new A());
}
public static void bDoTest() {
doTest(new B());
}
private static doTest(Testable t) {
t.testMe();
}
public static void main(String[] args) {
aDoTest();
bDoTest();
}
}
public interface Testable {
public void testMe();
}
public class A implements Testable {
public void testMe() {
// ...
}
}
If this does not help, you need to clarify your question.
Perhaps you are wanting to catch calls to non-existent (i.e. undeclared or unimplemented) methods and turn them into calls to real methods. If so, you can give up on that idea. Java won't let you do it.
The closest that you can come is to generate a new class at runtime with implementations for this methods:
You can dynamically generate source code, compile it and load it.
You can use something like BCEL to create ".class" files and load them.
Use the Proxy class to create a dynamic proxy implementation of some interface.
But these approaches are all complicated and expensive. (Probably a lot more expensive that using reflection, unless the generation cost can be amortized over a huge number of calls.)
In Java you have methods, not functions.
Write an interface Testable.
public interface Testable {
public void testme();
}
class A and B must implement interface Testable.
Then in your class Application you have a method
private static doTest(Testable t) {
t.testme();
}
and then you have main() method
public static void main(String[] args) {
doTest(new A());
doTest(new B());
}

java, is there a way we can import a class under another name

is there a way we can import a class under another name?
Like if i have a class called javax.C and another class called java.C i can import javax.C under the name C1 and import java.C under the name C2.
We can do something like this in C#:
using Sys=System;
or Vb:
Imports Sys=System
No, there is nothing like that in Java. You can only import classes under their original name, and have to use the fully qualified name for all that you don't import (except those in java.lang and the current class's package).
To be short, no, this isn't possible in Java.
No. I think Java deliberately ditched typedef. The good news is, if you see a type, you know what it is. It can't be an alias to something else; or an alias to an alias to ...
If a new concept really deserves a new name, it most likely deserves a new type also.
The usage example of Sys=System will be frowned upon by most Java devs.
Java doesn't support static renaming. One idea is to subclass object in question with a new classname (but may not be a good idea because of certain side-effects / limitations, e.g. your target class may have the final modifier. Where permitted the code may behave differently if explicit type checking is used getClass() or instanceof ClassToRename, etc. (example below adapted from a different answer)
class MyApp {
public static void main(String[] args) {
ClassToRename parent_obj = new ClassToRename("Original class");
MyRenamedClass extended_obj_class_renamed = new MyRenamedClass("lol, the class was renamed");
// these two calls may be treated as the same
// * under certain conditions only *
parent_obj.originalFoo();
extended_obj_class_renamed.originalFoo();
}
private static class ClassToRename {
public ClassToRename(String strvar) {/*...*/}
public void originalFoo() {/*...*/}
}
private static class MyRenamedClass extends ClassToRename {
public MyRenamedClass(String strvar) {super(strvar);}
}
}

Categories

Resources