Merge upstream master

ACKNOWLEDGMENTS

@@ -207,7 +207,7 @@ In no particular order they are:
     lifebarier (GitHub: lifebarier)                 C, 2024-03-06
     Adrian Ross (GitHub: R077A6r1an)                C, 2024-04-09
     John Hubbard (GitHub: jhubbardbnso)             C, 2024-06-06
-
+    Werner Fouché (GitHub: wfouche)                 C, 2025-05-27
 
 Since about 2012 we have been asking contributors to sign the Python
 Contributor Agreement. The part following names above records evidence

NEWS

@@ -29,10 +29,11 @@ New Features
       deprecated for removal in Java 26. See https://github.com/jnr/jffi/issues/165
 
 Jython 2.7.5a1 Bugs fixed
+    - [ GH-404 ] Windows code page 65001 (UTF-8) not supported by Jython
+    - [ GH-384 ] Console encoding inferred incorrectly on Java 21
     - [ GH-382 ] Java EE Servlet Namespace Has Been Changed From javax.servlet to jakarta.servlet
     - [ GH-84 ] PyServlet Will Need To Use The jakarta.servlet Namespace #84
 
-
 ==============================================================================
 Jython 2.7.4
 ==============================================================================

ProcessDocs/README.md

@@ -0,0 +1,35 @@
+# Jython Project Processes
+
+This is an incomplete guide for Jython developers and contributors,
+to processes we apply during development.
+
+We aspire to processes and principles from
+the [Python Developer Guide](https://devguide.python.org/)
+where they are generic enough to apply to us.
+That guide, in its processes and cheat-sheets,
+is oriented strongly towards the C implementation of Python.
+Here we aim to provide versions of those things specific to Jython,
+our repositories, and a Java implementation[^1].
+
+It will not, to begin with,
+contain sections for everything that could be translated to Java.
+Where it falls short,
+readers should make an intelligent interpretation of the (C)Python Dev Guide
+for a Java context,
+and consider contributing that here.
+
+
+## Contents
+
+1. Setup and building (adapt from CPython and Jython Wiki)
+1. Git bootcamp (adapt from CPython)
+1. [Contributor agreement](contributor_agreement.md)
+1. [Coding standard](coding_standard.md)
+1. Lifecycle of a change (adapt from CPython)
+1. [Releasing a version](releasing.md)
+
+
+[^1]: We have several times tried to maintain a complete Jython Developer Guide
+based on the [Python Developer Guide](https://devguide.python.org/),
+and incorporating material from it.
+Keeping common material in sync proved too difficult.

ProcessDocs/coding_standard.md

@@ -0,0 +1,124 @@
+# Coding Standard
+
+When contributing code or patches to Jython,
+please try to follow these guidelines.
+
+This guidance is quite old (Java 6 or earlier)
+so will not answer all questions.
+It applies to Jython 2.
+It has been rescued from the Jython Wiki.
+
+Parts of the Jython code base do not conform very well to this guide.
+(They may be even older than the rules.)
+Avoid the temptation to reformat them when working on a contribution,
+as it makes it difficult for a reviewer to see
+the code change being contributed.
+
+
+## Python Code
+
+In general, follow PEP 8.
+
+When importing Java code, always use fully qualified class names,
+not package names i.e. `from java.lang import String`
+instead of `from java import lang`.
+
+## Java Code
+
+In general, have in mind that code is read more times than it is written,
+and that contributors not familiar with your thinking
+will seek to maintain or extend it.
+Code that cannot be followed by others is likely to be replaced
+when it is found (or suspected) to be the source of a bug or limitation,
+and then the value of your excellent work is lost.
+
+1.  Javadoc on any publicly exposed method or field.
+2.  4 spaces for indentation, no tabs.
+3.  No nested ternary statements (no ternary statements inside other ternaries).
+4.  A luxurious 100 characters per line.
+5.  No copy and pasted, repeated code:
+    if you're doing the same thing twice, make a method.
+6.  Braces on all loops and `if-else` statements
+7.  A space between an if and its parenthesis i.e. `if (` instead of `if(`.
+8.  Spaces between annotation element-value pairs,
+    i.e. `@ExposedType(name = "unicode", base = PyBaseString.class)`
+    instead of `@ExposedType(name="unicode",base=PyBaseString.class)`.
+9.  Methods longer than 10 lines should have whitespace and comments breaking them up into coherent operations.
+10. Descriptive names for fields and methods. 
+11. No @author tags in code. 
+12. Any field on an object that isn't modified after construction should be final.
+13. Fields at the top of the class. 
+14. Don't declare fields with their default values ie `private Object blah;`
+    instead of private `Object blah = null;`
+    and `int i;` instead of `int i = 0;`
+15. Comments begin with a space unless they're commented out code: 
+    Poor:
+    ```
+    //TODO: Not implemented yet 
+    // bar.bar()
+    ```
+    Better:
+    ```
+    // TODO: Not implemented yet 
+    //bar.bar()
+    ```
+
+Beyond these rules, follow the Sun Java standards.
+
+> [!NOTE]
+> We should provide a set of formatting definitions that can be imported into
+> the Eclipse IDE to get it to follow the standards.
+> The Java formatter in VSCode will read the rules Eclipse exports.
+> In 2025 this was incomplete and provided no way to edit the rules,
+> buthings may have moved on,
+> see https://code.visualstudio.com/docs/java/java-linting.
+
+
+### Example (adapted from Sun document)
+
+```java
+package org.jython.blah;
+import org.jython.blah.BlahBlah;
+/**
+ * Class description goes here.
+ */
+public class Blah extends SomeClass {
+    /* A class implementation comment can go here. */
+    /** classVar1 documentation comment */
+    public static int classVar1;
+    /**
+     * classVar2 documentation comment that happens to be
+     * more than one line long
+     */
+    private static Object classVar2;
+    /** instanceVar1 documentation comment */
+    public Object instanceVar1;
+    /** instanceVar2 documentation comment */
+    protected int instanceVar2;
+    /** instanceVar3 documentation comment */
+    private Object[] instanceVar3;
+
+    /**
+     * ...constructor Blah documentation comment...
+     */
+    public Blah() {
+        // ...implementation goes here...
+    }
+
+    /**
+     * ...method doSomething documentation comment...
+     */
+    public void doSomething() {
+        // ...implementation goes here...
+    }
+
+    /**
+     * ...method doSomethingElse documentation comment...
+     * @param someParam description
+     */
+    public void doSomethingElse(Object someParam) {
+        // ...implementation goes here...
+    }
+}
+```
+

ProcessDocs/contributor_agreement.md

@@ -0,0 +1,28 @@
+# Contributor Agreement
+
+Jython is a Python Software Foundation project,
+and therefore we use the same process to ensure that
+code submitted by you is actually free for us to use,
+which is this
+[Contributor Agreement](https://www.python.org/psf/contrib/contrib-form/).
+
+Up sides:
+* If you are a contributor to CPython, or its documentation, PEPs etc.,
+  there's nothing else to do.
+* When you have signed up, you're all set to contribute to CPython too. 
+
+Down side:
+* The nice automation of the process built for CPython does not work here
+  (because Jython is not part of the Python GitHub organisation[^1]).
+  So only the manual process works.
+
+When you've signed up,
+add yourself to the ACKNOWLEDGMENTS file in the form
+```
+Real Name (GitHub: githubname)             C, YYYY-MM-DD
+```
+where the date is the current date (date of your sign up).
+
+[^1]: Jython moved to GitHub as its own organisation
+before CPython made the leap.
+