feedback-to-code/mozzarella huggingface dataset:
Repository: netty/netty
Issue: `io.netty:netty-all:4.1.75.Final` declares an empty automatic module name

### Expected behavior

If the `Automatic-Module-Name` manifest property is present, it should be set to a meaningful value. This attribute is defined in the manifest for `io.netty:netty-all:4.1.75.Final`

### Actual behavior

In `io.netty:netty-all:4.1.75.Final` (and earlier versions), this is declared but not set. This causes any toolchain that attempts to use java modules to get upset.

### Steps to reproduce

```shell
jar xvf ~/Downloads/netty-all-4.1.75.Final.jar META-INF/MANIFEST.MF
head META-INF/MANIFEST.MF
```

The output is:

```
Manifest-Version: 1.0
Implementation-Title: Netty/All-in-One
Bundle-Description: Netty is an asynchronous event-driven network appl
 ication framework for    rapid development of maintainable high perfo
 rmance protocol servers and    clients.
Automatic-Module-Name: 
Bundle-License: https://www.apache.org/licenses/LICENSE-2.0
Bundle-SymbolicName: io.netty.all
Implementation-Version: 4.1.75.Final
Built-By: norman
```

The problematic thing is that `Automatic-Module-Name` is declared but not set.

### Netty version

4.1.75.Final

### JVM version (e.g. `java -version`)

9+


Issue comments:
The simple solution of just slapping in some random name (`io.netty.all`) is that this will cause the packages within this jar to be exported from more than one Java Module, and that will also cause problems.

The other fix is to remove the attribute from the manifest entirely.
Netty-all is a pom-only dependency now, so it doesn't have any packages in the jar file. Still, it _probably_ shouldn't try to declare any automatic module name.

Pull request review comments:
wouldn't it be better to not define a module at all if it not ships any classes ? 

/cc @shs96c
As long as this jar doesn't contain any classes, it'll be fine. The problems with the module system start when the same class is present in two or more jars: split packages (and therefore duplicate classes) are strictly forbidden.
ok then it is fine.. Thanks!
> wouldn't it be better to not define a module at all if it not ships any classes ?

Like I said above, I tried to make that happen, couldn't get it to work.

Patch that resolved the issue:
diff --git a/all/pom.xml b/all/pom.xml
index 7dcd227bd84..1265fe3d3de 100644
--- a/all/pom.xml
+++ b/all/pom.xml
@@ -29,6 +29,7 @@
   <name>Netty/All-in-One</name>
 
   <properties>
+    <javaModuleName>io.netty.all</javaModuleName>
     <generatedSourceDir>${project.build.directory}/src</generatedSourceDir>
     <dependencyVersionsDir>${project.build.directory}/versions</dependencyVersionsDir>
     <japicmp.skip>true</japicmp.skip>


Test patch:
Repository: netty/netty
Issue: FlowControlHandler breaks auto-reading

_FlowControlHandler_ breaks auto-reading (i.e. the channel does not auto-read even though its config has auto-read set to true). This happens when auto-read is turned on when the queue is not empty. The reason is that _FlowControlHandler.read()_ does not pass the call to the _ChannelHandlerContext_ if at least one message has been dequeued. This is a problem when _FlowControlHandler.read()_ has been called as a result of auto-read having been turned on (_DefaultChannelConfig.setAutoRead()_ calling read() in case of _autoRead && !oldAutoRead_).
Taking _ctx.read();_ out of the body of the if statement fixes the bug and I also did not notice any unwanted side effects. I.e.:
```
public void read(ChannelHandlerContext ctx) throws Exception {
    if (dequeue(ctx, 1) == 0) {
        shouldConsume = true;
    }
    ctx.read();
}

``` 
### Expected behavior
Auto-reading.

### Actual behavior
Reading the messages that are already in the queue and then no auto-reading.

### Steps to reproduce
On a channel with a FlowControlHandler in its pipeline, turn auto-read off while a message is in the process of being added to the handler's queue.  When the message is already in the queue, turn auto-read back on.

### Minimal yet complete reproducer code (or URL to code)
It is a bit hard to reproduce with simple code so I hope that you understand the issue from my description.

### Netty version
any

### JVM version (e.g. `java -version`)
any

### OS version (e.g. `uname -a`)
any


Issue comments:
Do you want to make a PR?

Pull request review comments:

Patch that resolved the issue:
diff --git a/handler/src/main/java/io/netty/handler/flow/FlowControlHandler.java b/handler/src/main/java/io/netty/handler/flow/FlowControlHandler.java
index 1f7926fdf2f..f316907a7e5 100644
--- a/handler/src/main/java/io/netty/handler/flow/FlowControlHandler.java
+++ b/handler/src/main/java/io/netty/handler/flow/FlowControlHandler.java
@@ -141,8 +141,8 @@ public void read(ChannelHandlerContext ctx) throws Exception {
             // messages from upstream and once one arrives it need to be
             // relayed to downstream to keep the flow going.
             shouldConsume = true;
-            ctx.read();
         }
+        ctx.read();
     }
 
     @Override


Test patch:
Repository: netty/netty
Issue: ReferenceCountUtil.release(cast) could shade the exception of encode at function write of MessageToMessageEncoder

### Expected behavior
![image](https://user-images.githubusercontent.com/10280338/174937458-9bceea3c-4099-43e7-81c0-0022969f29dc.png)
Function `encode` at line 89 is declared to throw exceptions, and then if `ReferenceCountUtil.release(cast)` at line 91 throws an exception too, the exception threw by `encode` will be shown before the exception threw by `ReferenceCountUtil.release(cast)`.

### Actual behavior
The excpetion threw by `encode` will be shaded by the exception threw by `ReferenceCountUtil.release(cast)`.
### Steps to reproduce

### Minimal yet complete reproducer code (or URL to code)

### Netty version
on branch 4.1
### JVM version (e.g. `java -version`)
openjdk version "1.8.0_201"
### OS version (e.g. `uname -a`)


Issue comments:

Pull request review comments:
actually I think this will not work in netty 4.1 due our java version requirement and so you need to handle this kind of stuff differently.
The rethrowing Throwable? Then we can use `PlatformDependent.throwException` instead.
Yep... Only works on java8+

Patch that resolved the issue:
diff --git a/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java b/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java
index eb29eb87fca..4973c9bb0b7 100644
--- a/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java
+++ b/codec/src/main/java/io/netty/handler/codec/MessageToMessageEncoder.java
@@ -23,6 +23,7 @@
 import io.netty.util.ReferenceCountUtil;
 import io.netty.util.ReferenceCounted;
 import io.netty.util.concurrent.PromiseCombiner;
+import io.netty.util.internal.PlatformDependent;
 import io.netty.util.internal.StringUtil;
 import io.netty.util.internal.TypeParameterMatcher;
 
@@ -87,9 +88,11 @@ public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise)
                 I cast = (I) msg;
                 try {
                     encode(ctx, cast, out);
-                } finally {
-                    ReferenceCountUtil.release(cast);
+                } catch (Throwable th) {
+                    ReferenceCountUtil.safeRelease(cast);
+                    PlatformDependent.throwException(th);
                 }
+                ReferenceCountUtil.release(cast);
 
                 if (out.isEmpty()) {
                     throw new EncoderException(


Test patch:
Repository: netty/netty
Issue: [netty 5] ByteToMessageDecoder tries to allocate from a closed allocator

### Expected behavior
ByteToMessageDecoder shouldn't try to allocate a buffer from a closed allocator.

### Actual behavior
ByteToMessageDecoder tries to call decode when a channel becomes inactive which tries to allocate a buffer from a closed buffer allocator: https://gist.github.com/derklaro/38899e5d645adc058785e2197da0cdc6

Not sure if I am using something wrong (wrong call order?)... This seems to only sometimes happen during shutdown 🤔 

### Netty version
5.0.0.Alpha4

### JVM version (e.g. `java -version`)
```
openjdk version "20-ea" 2023-03-21
OpenJDK Runtime Environment (build 20-ea+9-505)
OpenJDK 64-Bit Server VM (build 20-ea+9-505, mixed mode, sharing)
```

### OS version (e.g. `uname -a`)
`Linux testing 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux`

Issue comments:
@chrisvest PTAL
> Caused by: java.lang.IllegalStateException: This allocator has been **closed**.
>  	at io.netty5.buffer.api.internal.Statics.allocatorClosedException(Statics.java:268)
>  	at io.netty5.buffer.api.pool.PooledBufferAllocator.allocate(PooledBufferAllocator.java:316)
>  	at io.netty5.buffer.api.DefaultBufferAllocators$**UncloseableBufferAllocator**.allocate(DefaultBufferAllocators.java:129)

Quite the mystery, here… 🤔 

I'll take a look.

Pull request review comments:

Patch that resolved the issue:
diff --git a/buffer/src/main/java/io/netty5/buffer/api/DefaultBufferAllocators.java b/buffer/src/main/java/io/netty5/buffer/api/DefaultBufferAllocators.java
index 10329926727..44b7a4fa611 100644
--- a/buffer/src/main/java/io/netty5/buffer/api/DefaultBufferAllocators.java
+++ b/buffer/src/main/java/io/netty5/buffer/api/DefaultBufferAllocators.java
@@ -61,12 +61,6 @@ public final class DefaultBufferAllocators {
             offHeap = BufferAllocator.offHeapPooled();
             logger.debug("-Dio.netty5.allocator.type: pooled (unknown: {})", allocType);
         }
-        getRuntime().addShutdownHook(new Thread(() -> {
-            //noinspection EmptyTryBlock
-            try (onHeap; offHeap) {
-                // Left blank.
-            }
-        }));
         UncloseableBufferAllocator onHeapUnclosable = new UncloseableBufferAllocator(onHeap);
         UncloseableBufferAllocator offHeapUnclosable = new UncloseableBufferAllocator(offHeap);
         DEFAULT_PREFERRED_ALLOCATOR = directBufferPreferred? offHeapUnclosable : onHeapUnclosable;


Test patch:
Repository: netty/netty
Issue: Release Handler-Ssl-Ocsp

Netty [Handler-Ssl-Ocsp](https://github.com/netty/netty/commit/09ac33766f6c30d445dcdfb4285f589aedf5d7fe) was merged but the module is not present in bom.xml. Hence, snapshots are not being deployed.


Issue comments:
@normanmaurer PTAL

Pull request review comments:
I think this is not correct... this should still be optional otherwise we have it as non optional dependency for handler as well. 

Same its true for the other change in here. 

Patch that resolved the issue:
diff --git a/all/pom.xml b/all/pom.xml
index 9f22ed3b174..d19dd9e52d4 100644
--- a/all/pom.xml
+++ b/all/pom.xml
@@ -298,6 +298,11 @@
       <artifactId>netty-handler-proxy</artifactId>
       <scope>compile</scope>
     </dependency>
+    <dependency>
+      <groupId>io.netty</groupId>
+      <artifactId>netty-handler-ssl-ocsp</artifactId>
+      <scope>compile</scope>
+    </dependency>
     <dependency>
       <groupId>${project.groupId}</groupId>
       <artifactId>netty-resolver</artifactId>
diff --git a/bom/pom.xml b/bom/pom.xml
index 5787d21e042..e0e89be4f7b 100644
--- a/bom/pom.xml
+++ b/bom/pom.xml
@@ -165,6 +165,11 @@
         <artifactId>netty-handler-proxy</artifactId>
         <version>${project.version}</version>
       </dependency>
+      <dependency>
+        <groupId>io.netty</groupId>
+        <artifactId>netty-handler-ssl-ocsp</artifactId>
+        <version>${project.version}</version>
+      </dependency>
       <dependency>
         <groupId>io.netty</groupId>
         <artifactId>netty-resolver</artifactId>
diff --git a/handler-ssl-ocsp/pom.xml b/handler-ssl-ocsp/pom.xml
index 9012d02a849..971749e026a 100644
--- a/handler-ssl-ocsp/pom.xml
+++ b/handler-ssl-ocsp/pom.xml
@@ -21,7 +21,7 @@
   <parent>
     <groupId>io.netty</groupId>
     <artifactId>netty-parent</artifactId>
-    <version>4.1.85.Final-SNAPSHOT</version>
+    <version>4.1.86.Final-SNAPSHOT</version>
   </parent>
 
   <artifactId>netty-handler-ssl-ocsp</artifactId>
@@ -37,6 +37,7 @@
     <dependency>
       <groupId>org.bouncycastle</groupId>
       <artifactId>bcpkix-jdk15on</artifactId>
+      <scope>provided</scope>
     </dependency>
     <dependency>
       <groupId>io.netty</groupId>


Test patch:
Repository: netty/netty
Issue: Possible issues with SelectedSelectionKeySet in non-linux operating systems

`SelectedSelectionKeySet` doesn't implement `contains()` method. Or at least it returns always false. This may create issues in non-linux operating systems.

To give you more context, in my work, like you do, we try to not produce garbage by replacing `HashSet` with something similar to `SelectedSelectionKeySet`. Actually this trick is something we learned from netty.

So while investigating a recent bug, I realized lack of correct implementation of `contains()` method creates problems in macos (and very possibly windows as well). I tried to summarize my finding in here: https://github.com/hazelcast/hazelcast/pull/24267

I do think this issue effects netty as well.

Issue comments:
Good find, we'll take a look.

Pull request review comments:
should we use `array[i].equals(o)` ?
imho this would be "safer". 
Changed it to `Objects.equals` in line with the API spec recommendation – it handles `null` values correctly.
Oh no, that's not available in the older Java versions. Fine.

Patch that resolved the issue:
diff --git a/transport/src/main/java/io/netty/channel/nio/SelectedSelectionKeySet.java b/transport/src/main/java/io/netty/channel/nio/SelectedSelectionKeySet.java
index 7117b06029e..b9c72b635cd 100644
--- a/transport/src/main/java/io/netty/channel/nio/SelectedSelectionKeySet.java
+++ b/transport/src/main/java/io/netty/channel/nio/SelectedSelectionKeySet.java
@@ -20,6 +20,7 @@
 import java.util.Arrays;
 import java.util.Iterator;
 import java.util.NoSuchElementException;
+import java.util.Objects;
 
 final class SelectedSelectionKeySet extends AbstractSet<SelectionKey> {
 
@@ -51,6 +52,13 @@ public boolean remove(Object o) {
 
     @Override
     public boolean contains(Object o) {
+        SelectionKey[] array = keys;
+        for (int i = 0, s = size; i < s; i++) {
+            SelectionKey k = array[i];
+            if (k.equals(o)) {
+                return true;
+            }
+        }
         return false;
     }
 


Test patch:
diff --git a/transport/src/test/java/io/netty/channel/nio/SelectedSelectionKeySetTest.java b/transport/src/test/java/io/netty/channel/nio/SelectedSelectionKeySetTest.java
index 46dde8b575d..9f5bb2c23db 100644
--- a/transport/src/test/java/io/netty/channel/nio/SelectedSelectionKeySetTest.java
+++ b/transport/src/test/java/io/netty/channel/nio/SelectedSelectionKeySetTest.java
@@ -102,8 +102,8 @@ public void contains() {
         SelectedSelectionKeySet set = new SelectedSelectionKeySet();
         assertTrue(set.add(mockKey));
         assertTrue(set.add(mockKey2));
-        assertFalse(set.contains(mockKey));
-        assertFalse(set.contains(mockKey2));
+        assertTrue(set.contains(mockKey));
+        assertTrue(set.contains(mockKey2));
         assertFalse(set.contains(mockKey3));
     }