We Keep Coding

In what order are Java constraints being executed

I have a Java method in which the method itself is annotated with a constraint (cross-parameter) and the arguments are also annotated with constraints (#NotNull, #NotEmpty etc).
Is the method constraint validated after method argument validation or is the order of validation not specified?

Annotations don't inherently do anything. They just mark things. javac itself knows what #Deprecated and #Override and #FunctionalInterface mean, but the effects are always to either do nothing, or to generate a compiler error: These annotations do not cause the compiler to generate any code.
Aside from Project Lombok this is a general principle of annotations, and even Project Lombok is an annotation processor: You have to put lombok on your classpath during a compilation, or nothing happens.
In other words, it is not possible for the #NonNull annotation in your code to generate any null check all on its own. The constraints are applied elsewhere, or by a code generating annotation processor that you explicitly include by putting it on the classpath or passing it along as annotation processor. For example, it IS possible for code you invoke to introspect your method and notice things. Thus, you could for example have:
class Example {
#NotEmpty String name;
}
and then you can do:
new Example("");
and this won't cause an exception. But you could do:
Validator validator = SomeHypotheticalValidationLibrary.newValidator();
validator.validate(new Example(""));
and then this validator would produce an error stating that the instance you provided fails verification. This is an example of annotations being introspected.
And now to answer your question:
The order in which such constraints are validated depends entirely on the validation library you use to do the validation; out of the box, the annotation itself does not and cannot produce any validation code. You'd have to check the documentation of your validation library, and provide the context within which you are validating.
If you're talking specifically about lombok's #NonNull - lombok scans your code for null checks (either of the form if (x == null) throw new Something(); or of the form Objects.nullCheck or guava's nullcheck). If it finds a nullcheck for an #NonNull annotated parameter, lombok does nothing. If it doesn't, it generates a nullcheck after all your explicit null checks. Lombok stops scanning for nullchecks once it hits a line that is NOT a nullcheck (so, neither an if (x == null) nor a methodInvocation(x, "optional text");). #NonNull is currently the only annotation that causes lombok to generate validation code (there is no #lombok.NotEmpty).
We may be able to give more insights if you explain which annotation processors / validation frameworks you are using.

in java what does the # symbol mean?

I know what it means in a comment for documentation purposes, but outside of that what does it mean? (I would normally just google this but every non letter symbol shows up in results)

The # symbol denotes a Java Annotation. What a Java annotation does, is that it adds a special attribute to the variable, method, class, interface, or other language elements. (This can be configured when you declare the annotation) When you add an annotation to something, other parts of the program can check whether something has an annotation or not. It then can use this information to do whatever stuff they need.
Let me give you some examples:
The #Override annotation
public class SuperClass {
public void someInterestingMethod() {
System.out.println("Superclass!");
}
}
public class DerivedClass extends SuperClass {
public void someInterestngMethod() {
System.out.println("Derived class!");
}
}
And when you do this:
SuperClass sc = new DerivedClass();
sc.someInterestingMethod();
The someInterestingMethod() call should be dynamically dispatched, and print "Derived class!", right? Well the derived class' method was actually misspelled, so DerivedClass got its own separate method called someInterestngMethod(), totally unrelated to the superclass' someInterestingMethod(). As such, someInterestingMethod() is no longer overridden, and the superclass' implementation is invoked.
The #Override keyword is intended to help with this. It signals your intent to the compiler, that you would like the annotated method to be an overload of one of the ancestor class' methods. If it's not (such as in this typo case, or if the SuperClass API changed and renamed the method), the will fail your compilation, to alert your attention to the broken override.
The #SuppressWarnings Annotation
Here is a method:
public void someMethod() {
int i;
}
There will be a compiler warning saying that i is never used. So you can add the #SuppressWarnings to the method to suppress the warning:
#SuppressWarnings("unused")
public void someMethod() {
int i;
}
Note that there is a parameter to the #SuppressWarnings annotation. Some annotations have parameters and you can look for the them in the javadoc. But for those that don't have parameters you don't need to add () like a method.
You can also declare your own annotations and use reflection to check for them. The above 2 annotations will be checked by the compiler.

The # sign is used to specify Java Annotation.
https://en.wikipedia.org/wiki/Java_annotation
There are built-in Java Annotation and user defined Custom Annotation.
Annotations are used in various ways, such as suppress warning, associate method to URI (Servlet), associate variables to resource (JNDI) etc

The # symbol is used for annotations. In my experience, the most common annotation is #Override, which indicates that a method is declared in a superclass. Other common annotations are #Deprecated, indicating that a method should no longer be used but still exists for backwards compatibility, and #SupressWarnings, to prevent warnings from showing up in the compiler.
Note that it's actually possible to get annotations which are not included in the core Java libraries and to declare your own annotations.

The # symbol denotes Annotations. They provide information about a class, its field or method (above which they appear). They cannot perform operations. The compilers or special annotation processors use this information to make writing code less verbose.
In Java Persistence API you use them to map a Java class with database tables.
For example
#Table()
Used to map the particular Java class to the date base table.
#Entity
Represents that the class is an entity class.
Similarly you can use many annotations to map individual columns, generate ids, generate version, relationships etc.

As some other suggests, it is Java's annotation. It helps the compiler to validate your code and to notify the programmer as well.
Very simple code example:
public class SomeClass {
#Override
public String toString() {
return "SomeClass";
}
#Deprecated
public void doSomeOperation() {
// some operation...
}
}
The annotation from SomeClass#toString which is #Override helps the compiler to determine that it is an overridden function from the implicit inheritance to the class Object.
While the annotation from SomeClass#doSomeOperation will warn the programmer that the function itself is deprecated already and should be avoided to use.

The annotations are for the reader or compiler, not executable code.

Missing #Override in Java Libraries

It is considered to be a good practice to
use #Override annotation on methods which are being overriden in
subclass.
But why is same not applied to the classes that come with Java Library. For e.g. String Class. It overrides methods of Object class but does not use #Override annotation on these methods.
Is this so to maintain backward compatibility with previous releases of Java such as 1.4 etc.
Thanks

Within an API, it does not offer much to the user (of that API). However when you implement a method, and you 'intend' do override that of a super class, it is easy to miss out on the method signature, which is supposed to match.
In this case the #Override comes to the rescue as at compile time, it will fail or give a warning when the override does not happen. Also many IDE's recognize the #Override and give you enough support to flag and correct those situations before you even compile.
So the #Override in essence declares your intention that this method overrides something. The user of the API would care less what your intent is, as long as it works.
Actually, probably the true reason is this: The Retention of the #Override annotation is set to SOURCE. Which means the #Override flag is discarded when compiled into a class file.
#Target(value=METHOD)
#Retention(value=SOURCE)
public #interface Override

That is not much more of a cosmetic annotation, it's useful when generating documentation, to give hints through your Java IDE and to explicitly state when a method is overriden.
From the runtime/standard library implementors point of view, it was not worth the effort to modify all existing classes just to add something cosmetic.
Furthermore, regarding backward compatibility of annotations in general, considering that annotations are an optional and extended attribute present in .class file (when their retention policy is either CLASS or RUNTIME and available for Class and Method as Runtime(In)VisibleAnnotations and for Parameter as Runtime(In)VisibleParameterAnnotations) previous releases of the JVM would simply ignore that attribute during the .class file parsing performed the first time that Class is needed.
But actually, that 1.4 JVM class parser will not even reach the point where those Annotation .class attribute are located inside the structure because the parsing will end abruptly when the JVM will notice that the .class version is greater than the supported one.

#override annotation is used to provide some extra information, mainly while generating documentations and also for informing the developer that the code intends to override a method from the superclass.
This is mentioned in oracle documentation.
#Override #Override annotation informs the compiler that the element
is meant to override an element declared in a superclass. Overriding
methods will be discussed in Interfaces and Inheritance.
// mark method as a superclass method // that has been
overridden #Override int overriddenMethod() { }
While it is not required to use this annotation when overriding a
method, it helps to prevent errors. If a method marked with #Override
fails to correctly override a method in one of its superclasses, the
compiler generates an error.
Refer to this discussion in SO itself.

Spring #Transactional class vs method precedence rules

Spring says abuot #Transactional
The most derived location takes precedence when evaluating the transactional settings for a method.
Does this mean the annotation on method completely overrides annotation from class or does the omitted attributes (so defaults) does not count?
E.g.
#Transactional(isolation=Isolation.SERIALIZABLE)
public class MyService {
#Transactional(readOnly=true)
public void method() {
...
}
}
So what is the isolation settings of the method? Is this Isolation.DEFAULT because this is the default so it implicitly overrides Isolation.SERIALIZABLE or is it Isolation.SERIALIZABLE because none was explicitly specified on method annotation?

The annotation at the method level completely overrides the annotation at the type-level. Any kind of hierarchy is not quite possible here. Let me explain a little more. There is no way to find out if a value was specified by the user for a specific attribute, or if a default value is being returned when you read the attributes of an annotation. So, Spring, or anybody else, cannot determine whether a specific attribute was overridden, or if a default value is being used. So, there is no way to make a decision based on the presence or absence of an attribute. For that reason, whenever you override any annotation (that is, specify it with finer granularity), you need to specify all the required attributes. So, in your case, the Isolation.DEFAULT will be the isolation applied.
However, as a aside, suppose you have your own custom annotation that specifies an empty-string as the default value for some attribute. In that case, if your class-level annotation specifies a non-empty string for that attribute, and your method-level annotation doesn't specify any value (thus using the default value: the empty-string), you could infer that the attribute-value from the class-level annotation should be used. That is, not allowing the default-value in the method-level annotation to override the user-specified value at the class-level. In any such scenario, you have to be sure that the default-value doesn't represent a valid attribute-value. In the case of the #Transactional annotations, Isolation.DEFAULT does represent a valid value and it may have been explicitly be specified by the user.

Java Annotation Processing Tool #NoNull

I want to create an annotation that restricts a developer from specifying null as a parameter, which has been annotated with #NoNull
For example, if I create this method:
public void printLine(#NoNull String line) {
System.out.println(line);
}
On a method call, I want an error to appear if the user specifies null for line: printLine(null);
I have been using APT for only a little bit of time, and am wondering how to do this (if possible)?
This is the annotation I have created so far:
#Target(ElementType.PARAMETER)
#Retention(RetentionPolicy.SOURCE)
public #interface NoNull {}

Compile time will be tough to check, since you're really dealing with runtime values. If you want to create annotations to automatically add code to check this stuff, you should look at project lombok:
http://projectlombok.org/
It uses an annotation processor to add code to your beans to do various things.
For example:
#Getter #Setter
private int id;
The annotation processor would automatically add get/set methods to your bean.
I don't think it has null checks, but you should be able to add this in and contribute it.
Another option is to use the validation jsr, though this requires you to explicitly validate at runtime, but you could accomplish this with proxies or AOP.
#NotNull #Min(1)
public void setId(Integer id)

The point isn't to use the annotation only for readability, but to enforce the annotation at compile-time with APT
Considering that null is a runtime artifact, I don't see how you will enforce a null check at "compile time."
Instead, you'll have to modify your classes, and apt is not the tool to do this, at least not by itself. It exists to extract information about annotated elements from source files. But to enforce your #Null restriction, you need to modify the running class.
One thing that you could do is use apt to extract information about annotated parameters, then use a tool like aspectj to modify those classes at runtime to check the parameter value.
But that's a topic that's way too broad for a single SO question.

#Nullable, #Nonnull are locating in package: javax.annotation
Checkout guava, its got some nice things are type safety:
http://code.google.com/p/guava-libraries/wiki/GuavaExplained