Conditionally remove Java methods at compile time

I'm trying to implement something like a c# preprocessor I know that Java does not have the same preprocessor function, and we realize that there is a way to achieve similar results through design patterns such as factory However, I am still interested in finding a solution to this problem

At present, what I do is to create a class containing several static final Boolean attributes, such as the following example:

public class Preprocessor
{
  public static final boolean FULLACCESS = false;
}

Then I use it in the following ways:

public ClassName getClassName()
{
    if(Preprocessor.FULLACCESS)
    {
        return this;
    }
    else
    {
        return this.Deepcopy();
    }
}

So far so good, this solves my problem (the above example is trivial, but I use it in other cases) My question is, is there a way to place a condition for the entire method, so the method itself will not be available given the correct "preprocessor" variable? For example, I want to make a specific constructor only applicable to "full access" packages, as follows:

public ClassName()
{
    // do things
}

if(FULLACCESS)
{
public ClassName(ClassName thing)
{
    // copy contents from thing to the object being created
}
}

Again, I know the limitations (or design decisions) of Java as a language, and I know that this is unnecessary in most cases In fact, I've considered simply creating these "extra" methods, putting their entire code in a conditional content and throwing an exception if the condition is inactive, but this is a very rough solution that doesn't seem to help my programmers when I provide these libraries to them

Thank you very much for any help

Edit:

To supplement this problem, the reason I'm trying to do this is that by using exceptions as a solution, the IDE doesn't actually show methods as "available" However, again, this may just be my ignorance of Java

I want to do this mainly because I can have multiple public interfaces available. For example, the control in one restrictive method is more strict, and the other allows direct attribute changes However, I also hope to take the initiative Class, for example, in product line development methods where some variants are not available

EDIT2：

In addition, it is important to note that I will also generate documents conditionally Therefore, each compiled version of the package will have its own documentation, containing only the actual available documentation

Solution

This answer is partly based on your comments on the question and Mark's answer

I recommend that you implement it using java interfaces, which only expose the API you expect When you need a less restrictive API contract, extend the interface or create a separate implementation of the existing interface to get the required content

public interface A
{
    void f();
}

The above is your general API Now you want some special extra ways to test a or debug it or manipulate it or anything

public interface B extends A
{
    void specialAccess();
}

In addition, Java now supports the default method implementation of interfaces, which may be useful to you, depending on how the API is implemented They take the following forms

public interface A
{
    List getList();

    // this is still only an interface,but you have a default impl. here
    default void add(Object o)
    {
        getList().add(o);
    }
}

You can read more about the default method on Oracle's page about it here

In your API, your universal distribution may include a and B, and omit any implementation that provides special access rights; Then you can include B and special implementation for the special access version of the API you mentioned This will allow ordinary old Java objects, in addition to an additional interface, may also be an additional implementation, and the code is no different The customized part will only be in your library package If you want to give someone a "non special" low access version, please give them a jar without B, without any possible Bi implementation, possibly through a separate build script

I use NetBeans as my java work, and I like to let it use its automatically generated default build script So if I do this, what I do at NetBeans, I may create two projects, one for the basic API and one for the special access API. I will make the special access dependent on the basic project That will let me have two cans instead of one, but I will be fine; If two jars are enough trouble for me, I will go through the additional steps of the special access version of the build script mentioned above

Some examples directly from Java

Swing has examples of this pattern Note that the GUI component has a void paint (graphics g) Graphics give you certain functions Generally speaking, this G is actually a graphics2d, so you can treat it like this if you like

void paint(Graphics g)
{
    Graphics2d g2d = Graphics2d.class.cast(g);
}

Another example is using the swing component model If JList or JCombo@R_181_2419 @If you display a list of objects in the GUI, you may not use the default model if you want to change the list over time Instead, you create a new model with add functionality and inject it

JList list = new JList();
DefaultListModel model = new DefaultListModel();
list.setModel(model);

Now, your JList model has additional features that are usually not obvious, including the ability to easily add and delete items

Not only is additional functionality added in this way, but the original author of the listmodel does not even need to know that this functionality may exist