Operating systems don't always let a user control thread priority in the way that a programmer would like, and certainly not without extra privileges.
General-purpose operating systems have multiple classes of task priority. For example, you may find (in decreasing order of "priority"):
- A few very high priority levels only accessible by the operating system itself (e.g. for kernel tasks or device drivers).
- User-space real-time fixed-priority tasks.
- User-space timeshared variable-priority tasks.
- User-space low-priority tasks.
- Idle tasks, which should only run when absolutely nothing else needs to run.
As well as priority (i.e. what should run), another thing that may be class-dependent is preemption. A system task would typically be non-preemptable, but a real-time task might be able to choose for itself whether or not it can be preempted.
A task would typically need permission to run in a higher-priority class. This is a security matter; if any task can decide itself to be non-preemptable, then any buggy or malicious task could take over the system and prevent, say, user interaction. You can imagine how malware might make use of this.
So this may be part of the answer to your question: Your task may not have permission to elevate its priority quite that far.
(Just to complicate things further, in microkernel and hybrid operating systems, some scheduling may occur outside the microkernel, and so a task might have different kinds of priority depending on who is doing it. This is the case in macOS, for example, and it's why a task has two separate priorities: the "Mach priority" and the "BSD priority". But I digress.)
A typical example of variable-priority timesharing scheduling is the Unix timesharing system, which might reserve 100 or so priority levels for user-space threads, and a thread's priority is determined by what it's doing. A thread which relinquishes the CPU because it is waiting for I/O, for example, will get a higher priority than one which exhausts its quantum.
The theory is that threads that wait tend to be more "interactive", so the system as a whole would feel more responsive if they got priority.
Within these constraints, a task can tell the operating system that it is more or less important/urgent, but that would typically be implemented as an adjustment on top of the timesharing scheduling system.
Exactly how the Java runtime implements thread priorities on top of the operating system is OS-dependent. Windows, for example, only has seven user priority levels, which is fewer than the Java API, and so the mapping will inevitably map some distinct Java priorities onto the same OS priority.
But even if there are a lot of priority levels available, the OS is free to interpret a thread priority however it wants. So this is possibly the other answer to your question: Even if your task has permission to elevate its priority to be real-time, the JDK may not provide a way to do it.