Is OWASP Java Encoder Project enough to prevent reflected XSS?

I've been reading articles about reflected XSS prevention. From what I understand, output encoding is the primary way to deal with reflected XSS. Some tools available would be the OWASP Java Encoder project and OWASP ESAPI. I have a java/JSP web application. I'm not sure if input validation should be also performed on the .jsp file when there is already input validation in the corresponding .java file. So I have the following questions:

1. Is OWASP Java Encoder project sufficient to prevent reflected XSS?
2. Do I need to do input validation on the .jsp file?
3. If 2. is a yes, would creating my own input validation functions or using the ESAPI Validator class be better?
4. If I have to use ESAPI, it means that I need to add ESAPI.properties and validation.properties. Given my project is an Ant project, where do I add these files?

Thanks in advance.

I will address your individual questions in a moment, but first I want to suggest that you thoroughly read the OWASP Cross-Site Scripting Prevention Cheat Sheet. That will cover all the basics that you need to know, including discussions about defense-in-depth approaches. Now on to your specific questions.

1. Is OWASP Java Encoder project sufficient to prevent reflected XSS? Answer: If used correctly (that is you use the correct contextual encoder), for Java/JSPs, either the OWASP Java Encoder project or the ESAPI Encoder should be sufficient to prevent XSS in all but a few edge cases. Those edge cases are would including DOM-based XSS (so, technically, not 'reflected', I know) or cases where you have requirements that some HTML mark-up be allowed. (E.g., maybe in collecting user comments.) In those cases, you will want to also leverage HTML sanitizers such as the OWASP AntiSamy project or the OWASP Java HTML Sanitizer project.
2. Do I need to do input validation on the .jsp file? Answer: It is not absolutely necessary (assuming you use the output encoding correctly), but it wouldn't hurt. It is considered a part of the defense-in-depth strategy, especially in those tricky areas where mixed-encoding contexts are involved, such as rendering a URL in JavaScript. Along with input validation, Content-Security-Policy headers should are also strongly recommended, although CSPs are much easier to use in a green-field approach than in legacy applications.
3. If 2. is a yes, would creating my own input validation functions or using the ESAPI Validator class be better? Answer: In most cases you can probably do your own allow-list validation based on some simple regular expression matching. (Do not write the validation as block-lists though.) ESAPI Validation is probably more than you need and even as the ESAPI project co-lead, I personally wouldn't recommend it unless you are planning to use ESAPI for some other purpose (because it drags in a lot of transitive dependencies).
4. If I have to use ESAPI, it means that I need to add ESAPI.properties and validation.properties. Given my project is an Ant project, where do I add these files? Answer: You don''t have to use ESAPI, but if you do, where the ESAPI.properties and Validation.properties files go is not relevant to whether you use Ant or Maven or Gradle, etc. Look at class Javadoc for the ESAPI class org.owasp.esapi.reference.DefaultSecurityConfiguration for details of how the ESAPI.properties and Validation.properties files are located.

Hope that helps answer your questions.