-
Notifications
You must be signed in to change notification settings - Fork 323
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove akka from runtime #8953
Remove akka from runtime #8953
Conversation
Are you aware of #8934? You can probably more or less revert the commit that introduced it. |
c59bffc
to
bd71fd9
Compare
Thanks for pointing that out. Let's first try to use only JDK. I think that the HttpClient provided by the JDK is more than capable of handling few requests. There is no need to add yet another dependency. |
Seems like some leftover.
public void noAkkaDependencies() { | ||
try { | ||
Class.forName("akka.actor.ActorSystem$"); | ||
fail("akka.actor.ActorSystem should not be on the classpath"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is a bit clumsy. If akka.actor.ActorSystem
is not on the class-path, it only means that runtime/test
does not have akka
dependency, it does not check that there are no akka classes in runtime.jar
. However, I still think that this test is useful. Moreover, I have manually checked that runtime.jar
does not contain any akka classes.
@@ -1,6 +1,6 @@ | |||
package org.enso.downloader.http | |||
|
|||
import akka.http.scaladsl.model.HttpRequest | |||
import java.net.http.HttpRequest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using class from JDK is a great step forward!
/** | ||
* This utility class adds support for {@code multipart/form-data} content-type as there is no such | ||
* support in {@code java.net.http} JDK. | ||
* | ||
* <p>Inspired by <a href="https://stackoverflow.com/a/56482187/4816269">SO</a>. | ||
*/ | ||
public class FilesMultipartBodyPublisher { | ||
public static HttpRequest.BodyPublisher ofMimeMultipartData( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like us implementing such utilities ourselves instead of using existing well-tested solutions.
This works nicely for simple cases, but how do we guarantee that it will work well in general? Should we try testing it as well as an existing solution would? That adds a lot of maintenance burden on us.
Example 1: the boundary.
I see it is generated as a UUID. I guess it is extremely unlikely that the same UUID would appear inside of the contents of one of the parts submitted as part of this form, but it is not 100% guaranteed.
I'm a bit nitpicky here as indeed it is going to be very unlikely to run into this kind of collision. But was this even considered when this code was written?
This is a seemingly simple operation but it may raise many uncertainities like the example above. IMO relying on an existing solution is better as it does not put the maintenance burden of ensuring this solution is bug free, on us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The downloader
project makes only a very specific kind of HTTP requests and expects a very specific and narrow set of HTTP responses. We are in a full control over these reqs and responses. This project is only used for library uploading and downloading, which is also covered by tests.
Implementing a very simple handling of multipart/form-data
is a minimal price we have to pay here. Please keep in mind that we are trying very hard, in general, to reduce the number of classes that will eventually get into runtime.jar
.
lib/scala/downloader/src/main/scala/org/enso/downloader/http/URIBuilder.scala
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
I'm a bit worried about rolling our own URI and Multipart body handling - these seem like they are simple, but there are traps hidden there.
But I don't want to be complaining too much - we should be fine with these for now and they are not heavily used anyway.
I'd appreciate if we put a comment for future maybe, so that once we start using these more, we could revisit and see if any 'reinforcements' are needed there.
@radeusgd Didn't you mention that at some point you moved from JDK to Apache because of some bug in the former? Is that fixed now? |
IIRC that was this bug https://bugs.openjdk.org/browse/JDK-8231449 it seems to indeed be fixed in Java 14 (we've been using Java 11 back then and I think it was never backported to versions <13). |
891587a
to
c5cc2dc
Compare
3e12343
to
ba0a69d
Compare
…oader # Conflicts: # tools/legal-review/engine/report-state # tools/legal-review/launcher/report-state # tools/legal-review/project-manager/report-state
Closes #8222
Pull Request Description
There are two projects transitively required by
runtime
, that have akka dependencies:downloader
connected-lock-manager
This PR replaces the
akka-http
dependency indownloader
by HttpClient from JDK, and splitsconnected-lock-manager
into two projects such that there are no akka classes inruntime.jar
.Important Notes
downloader
project - remove akka.downloader
project that uses ourhttp-test-helper
that is normally used for stdlib tests.connected-lock-manager
project into two projects - remove akka fromruntime
.native-image
is captured 743e167native-image
are passed via an argument file, not via command line - ba0a69dChecklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
./run ide build
.