Planning V2 rc1

[markjschreiber]

After a recent flurry of updates and valuable contributions from the community things seems to have settled down/ stabilized so I am thinking of cutting a v2 release starting with a release candidate v1. Probably making a v2.0 release in the new year.

Does anyone plan on making major breaking changes any time soon. If so, please let us know because once v2.0 is official there won't be breaking changes until v3.

[sigpwned]

Hello! I have been an excited user of this library for a while, but for a recent serverless application with space restrictions, I found that it was too big for my needs. To that end, I built sigpwned/aws-java-nio-spi-for-s3-lite. Where this library requires somewhere between 25-50MB of uncompressed JAR space, the "lite" library only requires about 1MB.

To be clear, my "lite" library is NOT a full replacement for this library! In particular, it does not support asynchronous access, or seekable access in general. However, it does support most of the "core" operations of this library on a synchronous basis.

Do the maintainers have any interest in looking at the library to see if there's anything worth pulling in? Unfortunately, it's a rewrite as opposed to a fork, so merging would not be as simple as a PR. Also, adopting features might involve breaking changes, which is why I bring it up here.

Of course, the library is open source under a permissive license, so there is no time pressure. You can pull now, a year from now, or never at all, as you wish!

I'm very happy to discuss more if this looks at all interesting to the team. And thanks again for maintaining this (outstanding) library!

[markjschreiber]

It could be that our shaded jar contains cruft it doesn't need. That would be interesting to look into. I do think we should use asynchronous operations because of the need for network operations.

For a serverless application are you using AWS lambda? If so, Java might not be the best choice for performance due to the startup overhead of the JVM. If you do go with Java and you are reading from S3 is there a need to use an nio SPI? Are you expecting to need to be able to interpret local and S3 uris?

[sigpwned]

It turns out that aws-java-nio-spi-for-s3's size is largely the result of its dependencies software.amazon.awssdk:s3 and software.amazon.awssdk.crt:aws-crt. An über JAR containing only those dependencies has the following sizes:

• software.amazon.awssdk:s3:2.21.30 -- 12MB compressed / 31.0MB uncompressed
• software.amazon.awssdk.crt:aws-crt:0.28.12 -- 17MB / 44.3MB

So anything that depends on those artifacts is going to be of a size. If I'm really aggressive with exclusions, then I can get aws-java-nio-spi-for-s3 down to 14MB / 36MB:

<!-- S3 client, minus optional clients -->
<dependency>
  <groupId>software.amazon.awssdk</groupId>
  <artifactId>s3</artifactId>
  <version>2.21.42</version>
  <exclusions>
    <exclusion>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>apache-client</artifactId>
    </exclusion>
    <exclusion>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>netty-nio-client</artifactId>
    </exclusion>
  </exclusions>
</dependency>

<!-- AWS CRT client, for linux-x86_64 platform only -->
<dependency>
  <groupId>software.amazon.awssdk.crt</groupId>
  <artifactId>aws-crt</artifactId>
  <version>0.28.12</version>
  <classifier>linux-x86_64</classifier>
</dependency>

<!-- aws-java-nio-spi-for-s3 excluding above dependencies -->
<dependency>
  <groupId>software.amazon.nio.s3</groupId>
  <artifactId>aws-java-nio-spi-for-s3</artifactId>
  <version>1.2.4</version>
  <exclusions>
    <exclusion>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>apache-client</artifactId>
    </exclusion>
    <exclusion>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>netty-nio-client</artifactId>
    </exclusion>
    <exclusion>
      <groupId>software.amazon.awssdk.crt</groupId>
      <artifactId>aws-crt</artifactId>
    </exclusion>
  </exclusions>
</dependency>

I do think we should use asynchronous operations because of the need for network operations.

I totally get it. I think Java 21's virtual threads system will go a long way towards closing the performance gap between synchronous and asynchronous I/O, but it's still very new, and it probably won't eliminate the difference completely. I don't need async I/O for my use case, which is why I was comfortable getting rid of it in my implementation.

FWIW, The only way I was able to get my library under 1MB was by implementing a lightweight S3 client at sigpwned/aws-java-sdk-lite uses the JVM's baked-in XML parser and HTTP client. There are definitely trade-offs.

In principle, I could also have implemented an async client for it using the Java 11 client to support asynchronous operations as well, but again, I don't need it for my use case, so I didn't bother.

It could be that our shaded jar contains cruft it doesn't need. That would be interesting to look into.

I do think there are a couple of small opportunities to reduce size.

The JAR should include a logging interface JAR, but not an implementation, since the implementation should be up to the user to choose. To my eye, the dependency on org.slf4j:slf4j-api should be kept, but the dependencies on ch.qos.logback:logback-classic and ch.qos.logback:logback-core should be removed. However, it's always possible I'm missing something!

If you were really looking to be aggressive on dependencies, then you might also be able to get rid of com.github.ben-manes.caffeine:caffeine. It doesn't have much use in the library, but its use in S3ReadAheadByteChannel does look pretty ingrained. I suspect you've already thought through this.

In any case, I don't think that either of these would provide substantial reductions in size.

Some Day, hopefully AWS will implement an async client using the Java 11 HttpClient, at which point replacing the CRT client becomes an option. That would reduce the size quite a bit. But alas, that day is not today.

For a serverless application are you using AWS lambda?

I am!

If so, Java might not be the best choice for performance due to the startup overhead of the JVM.

Surprisingly, it turns out that Java is the only platform that will work for my use case!

I'm hosting complex algorithms that take a long time to initialize -- like 30s -- so Java with SnapStart is my only (Lambda) option. Moving away from Fargate for this application will increase my flexibility and scalability while reducing cost substantially. Neat!

If you do go with Java and you are reading from S3 is there a need to use an nio SPI?
Are you expecting to need to be able to interpret local and S3 uris?

Strictly speaking, no, but I like the transparency. Being able to treat both local files and S3 objects as the same the simplifies a lot of infrastructure and testing logic.

Please don't interpret anything I'm saying here to mean that this library is bad or not useful. It's great, and extremely useful, and I suspect I'll continue using it for applications where space isn't at such a premium. But since you were soliciting feedback, I thought I'd share my related work in case there was something you liked and wanted to incorporate.

[markjschreiber]

Glad you like the lib, even if it's a bit chonky for a Lambda function :)

I think we might be able to move the logback packages to the examples package. I don't think they are required for the main package anymore.

We do use caffeine for caching blocks of bytes during read ahead. This is to allow a ByteChannel to eagerly seek/ read ahead bytes under the assumption that many uses of the library will want to read entire objects from S3 sequentially. Originally this was added because reads from S3 can have higher latency than reads from disk so eager fetching can mitigate this. It might be worth re-examining now that S3 has express one zone which can deliver single millisecond latency.

[markjschreiber]

issue #338 track the idea of removing logback from the core library.