-
Notifications
You must be signed in to change notification settings - Fork 208
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
Implement ByteArrayClassLoader::getResourceAsStream #170
base: master
Are you sure you want to change the base?
Conversation
@aunkrig is this PR acceptable? |
I adopted your PR, but slightly changed the implementation: Resources are kept in a separate map, because resource names are structured differently than class names, and should thus not be mixed. Does this work for you? |
@aunkrig Thank you. Unfortunately this does not. We are looking for the actual class data (compiled class) and not resources per se. for a jdk based classloader we can currently do:
this allow us write the class to a new jar. this is used by a system to generate jar + classes on the fly. hope this make sense? |
@aunkrig Any feedback? |
I understand. So why don't you just ask the
I recommend that you use the |
@aunkrig We use ISimpleCompiler and cache the compiled class. The jar is optionally build only much later (minutes or even hours). We will need to store the map from ICookable::getBytecodes to get access to it. Using the ClassLoader instance is more elegant as we are also using a similar mechanism for jdk based classes, which simplifies the jar building as we can query the class for the ClassLoader instance. ByteArrayClassLoader only provides getResourceAsStream as a way to get to the class data. If there is no other way we will have to deal with it on our end. |
bytebuddy seems to use the same mechanism, ie using getResourceAsStream: |
Honestly, this very tricky use of a |
@aunkrig Thank you for your patience, that it totally understandable. |
Why not overwrite Original public InputStream getResourceAsStream(String name) {
Objects.requireNonNull(name);
URL url = getResource(name);
try {
return url != null ? url.openStream() : null;
} catch (IOException e) {
return null;
}
} |
Let's not kid ourselves: The frequency in which getResource will be called directly is reduced compared to getResourceAsStream. The main disadvantage implementing getResource has over getResourceAsStream is that you'd have a lot more work regarding creating your own URL instance with the right URL protocol handler and all overhead associated with it. It's not impossible - but certainly not as easy as other methods (and DEFINITELY out of scope for janino). I would thus only do so if necessary. |
This PR adds getResourceAsStream to ByteArrayClassLoader. In our use case we need to load / access the generated byte code to add to a jar. This can optionally take place at a much later stage, ie long after compilation.