You can use

Integer integer = Integer.valueOf(i);

From the javadoc of the constructor:

Deprecated. It is rarely appropriate to use this constructor. The static factory valueOf(int) is generally a better choice, as it is likely to yield significantly better space and time performance. Constructs a newly allocated Integer object that represents the specified int value.

The main difference is that you won't always get a new instance with valueOf as small Integer instances are cached.

All of the primitive wrapper types (Boolean, Byte, Char, Short, Integer, Long, Float and Double) have adopted the same pattern. In general, replace:

    new <WrapperType>(<primitiveType>)

with

    <WrapperType>.valueOf(<primitiveType>)

(Note that the caching behavior mentioned above differs with the type and the Java platform, but the Java 9+ deprecation applies notwithstanding these differences.)

In the general case, you can use Long::valueOf. But in this case specifically, you should take the time to simplify the code in general. The code you have is more reminiscent of Java 1.4 (before generics) than of Java 8, even.

Here's your comparator, nicely formatted:

new Comparator() {
    public int compare(final Object o1,final Object o2) {
        return byAscendingDate
            ? new Long(((File)o1).lastModified()).compareTo(new Long(((File) o2).lastModified()))
            : new Long(((File)o2).lastModified()).compareTo(new Long(((File) o1).lastModified()));
        }
    });

First, use the generic form instead of a raw Comparator. This remove the need for casts:

new Comparator<File>() { // use generic instead of raw
    public int compare(final File o1, final File o2) { // File instead of Object
        return byAscendingDate
            ? new Long(o1.lastModified()).compareTo(new Long(o2.lastModified()))
            : new Long(o2.lastModified()).compareTo(new Long(o1.lastModified()));
        }
    });

Now, instead of new Long(...).compareTo or even Long.valueOf(...).compareTo, you can just use the static Long::compare(long, long) introduced in Java 7:

new Comparator<File>() { // use generic instead of raw
    public int compare(final File o1, final File o2) { // File instead of Object
        return byAscendingDate
            ? Long.compare(o1.lastModified(), o2.lastModified())
            : Long.compare(o2.lastModified(), o1.lastModified())
        }
    });

Then, you can use lambdas instead of an anonymous class:

(o1, o2) -> byAscendingDate
     ? Long.compare(o1.lastModified(), o2.lastModified())
     : Long.compare(o2.lastModified(), o1.lastModified())

Or, you can even just use the Comparator helpers introduced in Java 8. Combining Comparator::comparingLong and Comparator::reversed, you get:

Comparator<File> cmp = Comparator.comparingLong(File::lastModified);
if (!byAscendingDate) {
    cmp = cmp.reversed();
}
Arrays.sort(files, cmp);

I would encourage you to look around the Comparator and Long classes to see what new functions are around, and in general to keep an eye out for the various helpers that have been introduced over the years.

This problem is pretty well-known to be honest, and I can share some experience here.

First, there is no in-built way in java to specify the version of the software, in which the given API would be deleted. The parameter since is merely the version in which the API was marked for deprecation, quote from the doc:

The value of this element indicates the version in which the annotated program element was first deprecated.

I'm a community contributor to spring-data open source projects, and the API deprecation is a common thing. In case we deprecate some API, if we mark that forRemoval = true, it is simply removed in the next major release following the SemVer. I'm just letting you know how it is done by the hegemonies of the industry. As for this statement:

Also there is a since property, however, since we have multiple versions in parallel this doesn't seem intuitive. For example we might release a patch for version 4.3, 4.2 and 4.1 so technically on the 4.3 branch it would be marked deprecated since say 4.3.2 and on the 4.2 it would be since 4.2.5 and the 4.1 would be since 4.1.9. This means if you are on 4.3.1, 4.2.4, or 4.1.8 it won't be marked deprecated.

This is totally fine. This is one of the many reasons why the previous major versions are still supported - because some API that is deleted in the major version 2 is present in the major version 1, and some client is not ready yet to migrate. That is why we're backporting patches into previous major release minor version, as you described, thats fine. This practice is adopted by JDK, Kotlin, Spring projects etc.

Am I relegated to comments to make this work or is there some way I can do all this with the annotations so it is recognized by the developer's IDE?

There is no compatible way to do this. You cannot know what IDE the person is using and what plugins or inspections are enabled.

What we can and should do is:

1. Add Java tag @deprecated and provide the meaningful explanation why the API is deprecated and when it will be removed.
2. Add Java tag @see to guide the user to the potential replacement for the API
3. And of course, do not forget to package the sources along with the .jar that contains the bytecode in order for the two suggestions above to work on developer's IDE, at least IntelliJ can download and parse the source jars.

Caring about users is a great thing, you're doing the right thing. But you cannot solve everything, so, do the best with what you've got.

P.S: Oracle official guide on deprecation of the API, from their perspective.