From e25b7c40bec6f0caa58f9267a76ccb689b5fff96 Mon Sep 17 00:00:00 2001
From: Chapman Flack <chap@anastigmatix.net>
Date: Thu, 24 Aug 2023 18:32:00 -0400
Subject: [PATCH 1/2] Clean up a bogus javadoc comment

That was one I must have written on far too little coffee.
Hardly any of it bore any connection to reality.

Ah. In my defense, it had been more coherent once, but
did not get updated with c9f6a20.
---
 .../postgresql/pljava/internal/VarlenaWrapper.java    | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/pljava/src/main/java/org/postgresql/pljava/internal/VarlenaWrapper.java b/pljava/src/main/java/org/postgresql/pljava/internal/VarlenaWrapper.java
index 89594488e..44432000b 100644
--- a/pljava/src/main/java/org/postgresql/pljava/internal/VarlenaWrapper.java
+++ b/pljava/src/main/java/org/postgresql/pljava/internal/VarlenaWrapper.java
@@ -1182,12 +1182,11 @@ public Thread newThread(Runnable r)
 		 * wraps a {@code ByteBuffer} and the {@link Output.State Output.State}
 		 * that protects it.
 		 *<p>
-		 * {@code BufferWrapper} installs <em>itself</em> as the inherited
-		 * {@code m_state} field, so {@code ByteBufferInputStream}'s methods
-		 * synchronize on it rather than the {@code State} object, for no
-		 * interference with the writing thread. The {@code pin} and
-		 * {@code unpin} methods, of course, forward to those of the
-		 * native state object.
+		 * {@code BufferWrapper} installs <em>itself</em> as the
+		 * {@code ByteBufferInputStream}'s lock object, so its methods
+		 * synchronize on this rather than anything that would interfere with
+		 * the writing thread. The {@code pin} and {@code unpin} methods,
+		 * of course, forward to those of the native state object.
 		 */
 		static class BufferWrapper
 		extends ByteBufferInputStream

From 8353f6fe8eef1b55b9569200c0b3d19303afc346 Mon Sep 17 00:00:00 2001
From: Chapman Flack <chap@anastigmatix.net>
Date: Sat, 26 Aug 2023 14:33:05 -0400
Subject: [PATCH 2/2] Ax ancient Java version in PL/Java 1.6.x docs

As PL/Java 1.6.x requires Java >= 9, it makes little sense
for a lingering javadoc comment to say you need Java 1.6
for something.
---
 .../postgresql/pljava/annotation/package-info.java    | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/pljava-api/src/main/java/org/postgresql/pljava/annotation/package-info.java b/pljava-api/src/main/java/org/postgresql/pljava/annotation/package-info.java
index de7309e5b..ca5af21cf 100644
--- a/pljava-api/src/main/java/org/postgresql/pljava/annotation/package-info.java
+++ b/pljava-api/src/main/java/org/postgresql/pljava/annotation/package-info.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015-2016 Tada AB and other contributors, as listed below.
+ * Copyright (c) 2015-2023 Tada AB and other contributors, as listed below.
  *
  * All rights reserved. This program and the accompanying materials
  * are made available under the terms of the The BSD 3-Clause License
@@ -33,11 +33,10 @@
  * <p>
  * Automatic descriptor generation requires attention to a few things.
  * <ul>
- * <li>A Java 6 or later Java compiler is required, and at least the
- * <code>pljava-api</code> jar must be on its class path. (The full
- * <code>pljava.jar</code> would also work, but only <code>pljava-api</code>
- * is required.) The jar must be on the class path in any case in order to
- * compile PL/Java code.
+ * <li>The {@code pljava-api} jar must be on the Java compiler's class path.
+ * (All but the simplest PL/Java functions probably refer to some class in
+ * PL/Java's API anyway, in which case the jar would already have to be on
+ * the class path.)
  * <li>When recompiling after changing only a few sources, it is possible the
  * Java compiler will only process a subset of the source files containing
  * annotations. If so, it may generate an incomplete deployment descriptor,