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
@Annotations(@Annotation("shared")) is amazingly wasteful #2035
Comments
Early indications are this will make the dist |
Seems worthwhile to me. Sent from my iPhone
|
Sorry, I was completely wrong because I was looking at size of the wrong files. Whether we use an |
Doesn't surprise me, strings are only stored once if they're exactly the same. It just looks wasteful in the (fake) generated Java source. |
Well, why again didn't we remove the |
IIRC because the model loader can't use the |
Mmm, why not? We are able to use the metamodel defined in Ceylon in its Java implementation, though. |
Because in order to do annotation processing javac completes annotations very early on, before the model loader is involved in anything. |
Oh, so it's different for annotations? Well, we could still stop generating |
yes
No the problem is using stuff like |
I don't get it. If we're not compiling the language module, then |
Well it was probably about 12 months ago that I was looking at this, so I could be confused, but the problem is what ceylon/ceylon.language#408 is about. When we're compiling the natives in the language module javac tries to complete annotation types like |
Again, I can believe you when bootstrapping, but that should not be true for any other module. |
Yes, it's during bootstrapping. |
So we should be able to not generate these annotations when not bootstrapping then :) |
Well obviously I don't understand how the hell the bootstrapping stuff works, but if that's all it needs... let's have a try. |
Meaning we keep the code that knows how to read both types of annotations but we generate the older type only when compiling the language module, right? |
Yes, that would be a good start. |
Well, sure we could annotate all the native stuff with Or we could try to fix the real problem. |
Well, we could, but starting by removing |
On the other hand, if the net effect on output size is so little why bother? We could wait until we can do it properly and at least get rid of some code? |
Because it is ugly when I turn on logging to see the generated Java schema and have my eyes hurt like someone shoved a stick in them. That's reason enough. Sent from my iPhone
|
Go see an optician :) |
…nstead of nested @annotation for the modifier annotations. Omit documentation annotations completely.
…t now handles documentation annotations too.
… on the Value being loaded first. Doh!
… annotations with both styles of annotation: @annotations and @shared$annotation$
More fiddly than I would have liked, but hopefully Gavin's eyesight is safe for the time-being. |
Thanks! :) |
So we didn't remove the |
We need the |
Also, I think we're better off with the modifier masks somewhere in the language module's |
Well, only if the metamodel can't produce it out of thin-air when required. |
That's what ceylon/ceylon.language#408 is about, and it would involve a similar duplication of code paths in the metamodel. Plus duplicated testing. That's quite a lot more work than this was.
I can't really parse that sentence, but I don't have an opposition to putting the masks somewhere else if they need to be shared. Which they would if the metamodel was to read them at runtime. |
I meant that if we have to write native code: @Annotations(modifiers = CeylonModifier.SHARED | CeylonModifier.ABSTRACT) then it's better if the constants live in the language module's |
Or in addition to if we can't make it work. |
Yes, in addition to because the flags being defined in ceylon.language doesn't help because that's not on the classpath of the compiler. |
Check this out:
Duplicate information is stored in a very wasteful format for no apparent reason. I propose that:
@Annotations
, andmodifiers
integer.This could be done without breaking backwards compatibility.
The text was updated successfully, but these errors were encountered: