Droidcon NYC 2015 – Reflection No Reflection – Bypassing Reflection API

hello yeah it’s hi welcome to the joke that’s named reflection or reflection most of what you will see today has been sponsored I mean we did the research during our office hours so I think it’s legitimate to have some advertising for Groupon and yes we’re recruiting so my name is stefan nicola you can follow me on github stackoverflow google+ if there are still some users i’m a senior android developer at groupon i got like something like 20 years of jet recording experience and on the open source side i’m one of the contributors of robots by through the juice box injects start a couple of projects like that so the talk today is going to be about reflection about annotation processing and optimizations related to this we will start by explaining the motivations behind this research and then we will go in depth in to reflection trying to find alternatives to reflection because there are some issues and Android as you might know and after that we will propose one solution which is named reflection or reflection like a bird no wing have been told it’s poetic no no and finally a conclusion on this research it’s yeah you should have some kind of background knowledge of dependency injection and bindings bye-bye things I mean stuff like Goten I’ve dart witteveen saber and annotation processing also i’m not going to go very deep into explaining that so i hope that you got some basic knowledge of that so the motivations at groupon we maintain a dependency injection framework let’s name robo juice Ruby juice is actually not only a funny library because it has a funny logo but it’s also a very feature-rich dependency injection framework because it’s made on juice juice as almost ten years of existence now and yeah it’s really feature-rich you can do a lot of stuff with juice very easily it’s very easy to configure and use and actually there is even in most cases in the simplest cases there is no need for configuration at all and one of the big advantages of juice compared to dagger to name it is that there is no manual graph definition so you don’t have to do it by yourself inside your own application you don’t have to care about the graph dependency the dependency graph because juice is going to handle that for you so juice and reproduce are great but actually it is slow why is it slow because it’s based on a reflection and in android um since the very beginning there has been some issue with reflection now the issues have been sold partially but there are still some some troubles and I I think even the art introduced new ones because of the compilation ahead of time just to go fast on that so with arch we can compile the code ahead of time when you install the application inside the device is going to be compiled a record you native code but you cannot do that with reflection because the name of the method or the field that you’re going to try to access may be a variable so it cannot be compiled ahead of time it need to be estimated at compile time that’s one of the things that can explain why reflection is a bit slower than normal code and on the android GV m so Robert ruse is slow okay so we tried our best to improve performances and with the release of robo juice three last year we could gain up to thirty five percent of improvements in speed which is actually very good I’m not going to go very deep into the details but you can find some slides on speaker deck and how we did that basically what we did is just churning robo juice which was purely based on juice and depending only on a reflection into some kind of hybrid library that uses also annotation processing to filter the usages of reflection so that we use reflection only when you we need it and the annotation processor is going to tell juice okay now you will need to use reflection for this field this field is method this method in this constructor no more so we try to target the usage of reflection not to use it for nothing basically so yeah we could gain like thirty-five percent speed improvement but how does it compare to other dependency frameworks so let’s say you got a Class A with a single dependency be very straightforward empty glasses so if you want to create and read instances of a with the dependency be if you use neway which is also going to trigger the creation of the dependency of and be then if you do that one thousand time it almost takes no time if you do it directly like new age will create a new

be at the same time and it’s super super fast nothing to stay here almost zero milliseconds if you use dagger one then you it will take like 10 milliseconds if you use reproduce to up to twenty seven milliseconds something like that robo juice three with thirty five percent improvement lowered it to like 16 17 milliseconds and with robo juice for which find a couple of new optimizations but still we are close to fifteen not close to ten so it improved but not enough really compared to dagger one though yeah you can also wonder if those numbers are really if they do really matter I think that’s an open question because one thousand injection it doesn’t happen very often but still it would be nice to be as fast so if I were understanding of the problem of juice is correct the problem of juice and robo juice is that reflection is slow yeah reflection is slow so the simple solution it’d be too I got a problem with Nia animations yeah so let’s try to kill reflection completely that was like our main motivation so first let’s try to understand what is reflection so I hope that most of you are familiar with this concept so let’s say you got some java source code the basic flow when you build an application is to take the java source code inside your IDE to send it to the compiler it will provide byte code that will be executed on the GBM and then you will get a running application reflection happens at that level here so it means that during its life when the application is going to be running the application can access to a description of itself in terms of classes methods field and and constructors so we can access to this description of itself and we can also change the application so it’s not only a read-only view of the application that we via reflection but also a right right able image of the application and we can change the values of fields we can invoke methods invoke constructors via reflection here is a simple example of a few usages of the reflection API so as you can see it’s very intuitive very close to the way humans or developers talk about object oriented programs so you’re going to manipulate classes which are represented by the jeddak last class you’re going to manipulate con structures you can invoke them you can access methods in the same way and invoke the M passing parameters you can also discover Department the parameters of a method or a constructor you can also access the fields by their name and you can get the value of a field for a given instance of an object and you can also set the value of this field for a given object so yeah reflection is slow but what exactly is slow inside reflection I think this question is quite important so let’s break down this into pieces as you can see on those graphs here when you try to access a field by reflection instead of accessing the field directly it’s like three times slower on a dalvik machine so all this at all of this has been benchmarked in milliseconds on genymotion which is a very good implementation of GV m very useful for testing so if you access a field 1 million time you can see that it takes around one milliseconds for direct access and by a reflection three milliseconds so a bit slower on the lower right side the graph is about methods in vocations so you can see that still it’s a bit slower very reflection and for constructor accesses this graph shows that there is a huge difference between reflection and direct access so if you create a class directly by using a new in your code it’s going to be very very fast and so slow using reflection so that should be something to try to target to bypass reflection at least for constructors but if we could also bypass reflection for accessing fields or invoking methods that would be nice too on the lower right you can also find a graph that represents the time that’s taken to do a few basic operations using reflection like class loading so using basically class that for a name and string so you load a new class into the memory into the gvm and as you can see this operation is pretty slow compared to like direct access of a method or constructor or whatever so it takes a lot of time to load a new class in term memory in the same way when you are scanning fields or scanning methods inside a given class for instance to look for annotated fields or annotated methods then it takes also some time less than loading a full class but still it’s a bit slow so yeah we want you to try to find a way to bypass that would completely avoid reflection so that juice maybe hopefully juice and even all other libraries based on reflection

could be faster on Android so let’s see what can we find as alternatives to reflection so if we take the same schema that with so earlier the reflection happens at runtime but there are some alternatives to prove to get a view of the program and to be able to manipulate it for instance we could use byte code weaving so Michael living is something that you can do at the bytecode level for sure and you can modify this byte code which is special binary you could change inside whatever you want you can for instance create a new field create a method whatever and so this is an alternative possibility to provide to get a view that is writable up the application another option could be to use abstract syntax trees so we will come into more details about what they are and how to use them and the third option that we studied is actually well-known and very trendy and enjoy it at least for like three years maybe it’s annotation processing so let’s go deeper and study all of these alternatives so the first one is bytecode weaving so you might know you may be aware that in Java there are two ways to do bytecode weaving the first one is to do bytecode weaving at runtime so basically what happens and many Java technologies rely on that so when you load a class into the gvm you can use what is called a user agent and this user agents will intercept the byte code that is being loaded into the memory into the gvm and at that very precise moment you can manipulate the bed code change it add methods and you could do whatever you want but on Android this is not possible because there is no agent on that we can art so the only option left to manipulate the byte code is static byte code weaving by this we mean to change the bytecode right after the compilation so javic is going to produce new byte code files that class files and we are going to open those files and manipulate them directly and ship em into the decks that’s going into your apk basically so here is an example of what we could achieve using by Col manipulations let’s take a single activity this very simple one and you just annotate it with at love life cycle so once this gets compiled we get we provide this bytecode to a transformer I think we call that and now we detected that you added this annotation and we can change the by code according to that and perform a certain number of actions for instance here we’re going to look at all the methods that are related to the life cycle of the activity and lock them so that in adb logcat you would get the time spent for each method call that is part of the life cycle you could also see which one is called and which one is not cold so it’s very easy to use you just use a simple annotation so we’ve been working on that for like 3-4 months we’ve created a full stack which was a bit complicated because we also also to be interoperable interoperable between Gradle maven then used a veces then provide like basic libraries to manipulate the bytecode do it at the Android level Exeter extra so we did a full stack and you can find it in github stefan nicola / injects and you will see we have a bunch of projects like the actual check views you inject resources all this just by byte code weaving so this approach is feasible but let’s evaluate it maybe more completely so it’s very simple to use as you can see just a single annotation and it can be very very powerful it’s as easy to you is as a Gradle plug-in there is no boilerplate required so you just add an annotation that’s it very powerful because you have access to the byte code so you can do whatever you want even things you don’t want to for instance you can very easily create a methods with to return statements at the bytecode level no one is going to prevent you to do so the Java compiler for sure is going to forbid that but when you are at the bytecode level there is no help Your Honor on your home basically so you can do whatever you want it’s extremely powerful and there is also kind of a standard in Java to manipulate byte code which is called Java assist and we could reuse that to perform manipulations of my code also for android on the dark side let’s say that what happens with Michael weaving it’s that it’s very complex so when you want to write a new library it’s very difficult you got your full stack of libraries to use it’s difficult to figure out exactly who is going who we’re going who is going to do what who are the responsibilities of the different layers inside the stack how to manipulate by code even by itself it’s a bit tricky a bit mysterious even some time and Java assists as some missing features also so yeah it’s difficult but we think that the main problems come from the fact that it’s not standard so it means that inside the huge big task graph that you got when you are building an application via cradle for instance I don’t know if some of you have already

seen the graph but actually it’s huge it has over 100 nodes so there are over 100 operations that are performed by Gradle when you build an application and inside this huge task graph there is no real place to do my Michael manipulation so as soon as the build process is going to change on Android you’re going to have to adapt the bytecode weaving libraries which is quite tricky and also very tricky to support two versions so indeed it requires a high level of maintenance to keep that stack going also one of the limitations is that chedda assists is issued from the Java world so it can manipulate very easily class files and jars but not backsies so it means that if some of the library is your your using our kameez coming in the form of a AR for instance you won’t be able to do an invite code manipulation inside Jews libraries for your own code it’s possible because you are going to manipulate the dot class file but not for some of the libraries if they don’t come as jars and an open question which is actually a very limiting factor is that Google has been announcing maybe like one year ago that they are going to change the whole tool chain because they want to provide a more incremental tool chain that would be more aware of incremental changes so that if you change some part of source code only this class file is going to be replaced only this part of the decks is going to be changed only these Delta is going to be submitted to the device and so that the whole to shine is going to be much faster so yeah it’s expected it’s even experimentally working you can activate that inside your Gradle build but up to now we don’t we don’t have any information about the format’s that is going to be used by Jack and Jill to perform this operation faster we know that there is a format called JS but no one has any detail on that and if you look at the implementations of the icon jelly inside the Gradle plug-in you can see that it changes very very very quickly much faster that the pace of change of the documentation risk is which is cahsee non-existent also a disadvantage of microwaving is that modifications are not visible so it can let’s say be a bit precarious for some developers what we are doing is that we manipulate the bytecode so inside your ID you won’t see any change you’ve typed something your program is the way you typed it but we’re going to manipulate the bytecode that is produced after the compiler is working and you won’t see this changing you won’t see the changes inside the IDE you can only see them if you like retro engineer by a java p your your class files so you’re not going to be aware of that my mind is not very big issue if the libraries are tested enough but it can be some kind of black point let’s say for this is technique one of the alternatives was a EST manipulation so i don’t know if most of you are aware of that abstract syntax trees are indeed a form in which all the compilers that compile java source code into classifieds are going to represent all the java statements so when you compile a class file at the source file it’s going to be first represented as an AST and abstract syntax tree and then this tree is going to be turned into a class file this works for all the compilers we will see that there are some subtle differences sometimes so here is an example again you just annotate a class that implements bar syllable and you can see that we just declare a field inside there is no need for creating the Creator the parcel creator or creating the describe content method all of this is going to be generated just by iest manipulation so this is very powerful in the Java world you got a very well-known project that is called lombok so long blocks you just annotate the field with a together etc and they will generate the setters and getters for you and for Android a guy I met last year mentioned that he’s been working on some kind of fork of lombourg and applying it to Android that’s one of these class of obvious examples so you can find also this project and get up if we evaluate iest manipulations it will more or less be the same as microwaving so it’s very simple to use no boilerplate that goal very easy to use because there is a greater plug-in even an IDE plug-in indeed case so you can see some of these changes let’s say it’s extremely powerful as powerful as biker weaving but when it comes to create a new library it’s actually even harder than biker living because you have to manipulate abstract syntax trees and there are nuts normalized by the Java Java JDK the Java specifications so there are indeed non-standard by non-standard I mean that there are two compilers in the Java well one is for eclipse eclipse compiler for java there’s a one from the GDK which is a jeddak jealousy and both of them do

transform source code into a STS and then a STS into that class files but they use different implementations of a STS so what Lumbergh has been doing is that it has been providing to intentions of all its features 14 ECJ the Eclipse compiler and one for the JDK again maybe on Android yeah that’s right we could also just maybe focus on Java Sea and drop Eclipse I think no one uses eclipse anymore hopefully and yeah so that could be possible so maybe it’s not such a disadvantage still the Jack and Jill problem is going to have to be the same as for bytecode weaving we don’t know exactly about Jace so we don’t know exactly if they are still going to be even some a sts or not maybe Jace is just going to be a st SE realized many people have wished that for a long time for jai by itself but we don’t know when we don’t know how a esta manipulation is going to evolve with the new tool chain and modifications are not really invisible but let’s say we don’t see much you can maybe see new getters and setters in the project structure if you inspect your class but you won’t be able to see the byte code that has been added so not the implementation of those methods the third option was annotation processing so here you got an example of annotation processing with butter knife we just bind a few fields lie for two to associate them to some fields inside your XML some tags inside your XML layout we do the same force your resources on clicks and so on and as you can see inside the oncreate method of your activity you will have to create this statement to write this statement button I’ve that bind this so this is pure boilerplate code it’s used to link your own code with the code that is going to be generated by annotation processing so yeah this is pure boilerplate you wouldn’t like to will have to write that but it’s still needed and actually it uses reflection which is interesting because some people think that when you use a notation processing you don’t use a reflection at all which is not exactly true so let’s evaluate what annotation processing gives us oh it’s you fast does it work yeah so yeah annotation processing is quite simple to use you just have to annotate a bunch of fears methods whatever it’s a Java standard which is a big plus so it’s part of the Java specification is not supposed to change its supposed to be implemented by all the GI compilers and it’s supposed to work in the same way for everyone which is good it’s related Lee powerful not as powerful as by code weaving or iest manipulations we will see one in a sec why in a second one of the drawbacks of irritation processing I don’t know if some of you have tried all ready to write annotation processors how many in this room have tried to do so did you find it easy so so actually I think the API is really difficult why is difficult because we are very familiar with them the way that reflection works because it’s very close to the way that we do understand a Java program but when it comes to annotation processing API the view you got up your program is much closer to the view that the compiler as update program and so it’s very difficult for us to understand what is an element type element primitive elements they are not exactly the same thing as reflection also one of the drawbacks of annotation processing is that it’s completely impossible to modified code this is done by design so there is no way you can actually modify existing source code with sanitation processing the only thing you can do is to generate new code yeah there are some X you can do to actually modify the behavior of your code but yeah that’s not very interesting but still you cannot modify your code that’s what we want you to try to do every what it means when we have to come to annotation processing instead of reflection it means that every library that is based on reflection that was supposed to be working like hell on Java working super well like Jackson Jackson won Jackson to Jason all those good libraries that are tested nature you have been used for years they all have to be rewritten completely to use annotation processing and that’s what happens now in the android wall we are like to write completely new libraries for doing everything for parsing Jackson for passing Jason for faxing XML maybe four RM or M discoveries or yeah even for dependency injection for sure so we have to write every new library again another thing that is not so interesting about the National annotation processing is that as you generate new code you can change the bytecode you canna change your existing source code so you will have to guide some kind of glue between

the generated code and your own code so you need boilerplate to invoke generated code which is something we would like to avoid so let’s get a deeper look at annotation processing try to understand better what we are using it for on Android so we take a Java source file we pass it to the annotation processor it’s going to generate new java source code and both the java source code generated and your code are going to be passed to the compiler and be compiled at the same time if you look at what the generated code looks like here you get a very simple activity about groupon it’s a groupon activity so the good activity and then you got some fields that are bound inside this activity when we pass it to butter knife it will generate this class which is about groupon so the same NSD activity but are signed or arsine view binder and inside this class that is completely generated by the getty annotation processor you will find some code that actually performs to the glue or assigns all the fields from XML to the fields of your activity so this is what is generated so basically we use generated code in all the libraries that use annotation processing to do three things the first one is to access fields so read fields or assigned field goal methods and call constructors all those members can be accessed at one condition there must be not in private because you cannot modify the source code of and you cannot modify existing source code an existing source code is the only one to have access to private member’s it’s not possible to access them via something that is generated so you have to remove the private modifier which is actually violating some of the very basic principle of the object oriented programming so yeah what we do if you look at that is doing exactly the same thing as reflection is doing so we came up with an idea to try to unify that and to get the best of both worlds with a new project that we called rnr reflection or reflection the objectives of rnr our first to make it easy to adapt reflection based libraries into Android so we don’t want you have to rewrite everything that has been performing well for years we would like to be able to reuse these technologies seconds we would like to get the best of both world so the ease of reflection that talks to us because it speaks the same language as we do and annotation processing because it provided a lot of speed and three generated code is not very interesting for no one so we would like to hide it completely so we came up with an idea that we can summarize in one sentence is that we would like rnr to generate reflection like code via annotation processing so I’d like to use annotation processing to generate something that you as a developer or you as a library maker maybe we’ll be able to use like reflection very easily that’s the basic idea now let me explain you the internals of rnr we got a picture go so in reflection or no reflection we’re going to perform three steps the first one is to define what we call rnr classes that are 100 person compatible with reflection API so we will have our own class that we present a class our own class that represent a method our own class represents a field and a constructor we want to get exactly the same API which is very easy to test automatically you can test the coverage and see that your API matches their true native reflection API and we are going to fill those glasses all the information required by reflection we are going to fill those classes with information that we can acquire during annotation processing so during the first step of annotation processing we build something that is roughly equivalent to reflection that’s the first step second step we are going to take those around our classes and generate code so that they can be also created at runtime so they will become available at runtime in the first step they will become available at annotation processing time in a second step we’re going to generate them so that even an application that is running can use them we will come back into more details into those steps and the first step is to lo vea generated code to allow modifications of members access fields invoke methods and constructors so if we could make do three steps work we would actually have something that is completely equivalent to reflection but not using reflection at all and the name of this library so the first step the first step is to during annotation processing time to create the rnr classes so we are going to take an

annotation processor of our own from our library create those rnr classes and then after that once this is done then as a developer you could create an annotation processor that is going to be using reflection api inside of the the annotation processing api which is difficult to handle so once we get that we can go on with a normal cycle of annotation processing and generates java source code by sea to the compiler and it will get compiled as well as your original source code and produce a class file is that clear yeah so what are the results that we get outside of the first step so it means that as a developer you can manipulate field methods constructors and classes before they are compiled which is kind of a yeah I really like this idea so you’re going to compile something to get classes fields and methods but before getting them compiled you will be able to use them for creating an annotation processor so it will be much simpler so it’s kind of a unification of annotation processing and reflection API at the annotation processing time and we think that by itself it’s kind of am yeah an important theoretical the achievement in Java let’s see what step two is step two we are going to make those are on our classes accessible at runtime so we’re not going only to create those classes and take them into the gvm during annotation processing time we’re going to generate code so that boosts our and our classes become available at runtime so you take your java source code you pass it to a realization profit processor then we’re going to generate code that will fill the rnr classes so we fill the eye on our classes for our own so we get all those classes into memory the whole description of the application and we are also going to generate code to do the same thing at runtime so all the information that we require during annotation processing is going to be accessible during runtime at the application so we pass this disco to the compiler and now the application when it’s running will be able to access the R&R reflection instead of true reflection here is oh yeah there is one thing so if you do that you will get during runtime you will be able to get access to the rnr reflection but this reflection those reflection classes are going to provide you a read-only view of the application it means that you will be able to get the classes to get the fields to get the members like methods constructors everything but you will not be able to invoke methods you will not be able to access fields you will just get like the rough structure provided by API reflection the API of affection what does rnr class look like when it’s generated it’s very straightforward now we define a class by giving it a name we can add field we can add annotations to these fields we can add methods in the same way we can add modifiers to all the fields that we have discovered during annotation processing so it’s it’s basically a very readable version of the API reflect the API of reflection so this code is going to be generated and at runtime your application or any library we exist will be able to access those classes those classes are 100 compatible with reflection API classes they are fields during annotation processing and generate it to become accessible at runtime so that’s step two if we look at what we get outside of step two it means that all the rnr reflection classes are now available for leaves and applications at real time they will provide a read-only access to reflection information so still not able to access fields of instances invoke methods of instances and they are faster than reflection because they don’t use true native reflection that just use pure Java statements and actually there are exactly the equivalent of what is generated by any library like butter knife or dart so yeah everything is working well but they are read-only unlike true native reflection so we are missing like very important features of reflection the ability to change the value of the field to invoke a method of a given instance of a class so we’re going to remedy this by step three in step three we are going to provide ripe access to the reflection are in our reflection API how do we do that so we still take your source code generate deuce this code in step two for generating field are and our classes and we are going to also generate what we call class reflectors class reflectors will allow us to provide not only a read-only view of reflection during runtime but now thanks to the reflectors we are going to be able to write or to modify the application via rnr reflection classes so you will be able to access fields you will be able to invoke methods what does the reflector

look like it looks like that so we got a simple Class A with one or two fields a constructor here is what a reflector for this class looks like so as you can see there are like three or four methods once you change the value of a field change the value get the value of field invoke methods invoke a constructor or multiple constructors if you have multiple constructors in your class so it’s only very simple Java statements that are generated during adaptation processing so there should be tremendously faster than reflection and they are roughly equivalent and provide you with all the features of the reflection API so as the result of step three we now got something that extends a bit would step to provide it we are now able to access all the features of reflection during a panda runtime we provide a read and write access to reflection information and it’s faster than reflection and Android yeah by the weather was the little detail with gently omitted is that yeah if you look at what reflection does when you inspect the field you got a field by a reflection you can ask the phil what annotations do you have what are you annotated with and the answer provided by the API of reflection is going to be an instance of this annotation providing you all the values of the annotations this is actually a bit tricky because if you think about it an instance of an annotation what is that an annotation is actually something that extends an interface so the Java compiler is going to provide an implementation of those interfaces so that at runtime your reflection API will be able to get those instances and work with them and we did exactly the same thing so we pass the details but we were pretty proud when we we achieved that so now we got our NR working it’s been well yeah quite a lot of job but it works so what’s next I will remain focused Sun during this design this research has been to improve the performances of dependency injection so our basic idea still a bit stubborn is to let’s say we try to fog juice and see how it goes so usually the way we’ve designed it we would have hoped that it would be very simple just replace every reflection comb through native reflection go by our rnr reflection goals and that’s it we just change the imports we had this idea in mind it should not be very difficult to fork library like juice well if we look into the some details so actually juice use this reflection for processing so all the information that is provided by reflection is used for Jews to process what to inject how to compute the dependency injection graph and so on so here Jews uses reflection it uses also reflection to access field to invoke methods and to create instances what we did in the fork of juice that we call R&R juice that we used rnr for processing accessing fields invoking methods and creating instances so in whole juice which is quite a complex library we just switched from the true native reflection to rnr reflection and see how it goes here you can see something like not really using reflection to scan classes members because in juice and R&R juice since Roger three I told about it a bit earlier we use some watchin hybrid system using annotation processing to limit the scanning of class members so it’s not really reflection but also some annotation processing is being used so how is it bill well actually this was a failure and quite a big one which was very disappointing so what happened and why did it fail is that juice uses a lot of features of reflection it’s all based on reflection and its uses reflection so much we yeah I have we actually learned a lot about reflection when we try to do that so when we 42 replace reflection by rnr reflection it came up that we had to introduce quite a high volume of volume of changes which means potential bugs and juice is so complex that we were not confident at all that this code could be even been running also we’ve faced some unexpected troubles like something that we just understood a bit later is that reflection is not only an API like others in for the Java language it’s also very very related to the compiler and to the language itself so if you look at those statements here we got a simple class a an instance name a when we do a class that for name a this is a reflection call in the same way you could say instance that get class and you would this is also a reflection call and what you would get is exactly the same thing as a dot class which is not a reflection call which is actually a compiler understood directly by the symbol understood directly by the compiler and there is no way we could do

this kind of equivalence things with our our own reflection glasses so we’ve been like hitting a wall okay when you eat a whole a wall would you do you try again now so we tried again and now we hide this idea that we wanted to minimize the amount of changes in juice and use our NR only to bypass native reflections for member access via reflectors so we just use that instead of the whole machinery of rnr we’re just going to use reflectors to just at the very end not choose reflection but use our stuff which is supposed to be faster so we did that and only that the would easy we got good performance results actually almost like 20 persons improvements when creating instances of a class via the second fork of juice but this is not only this is not really accurate because when you create a lot of generated code you also look up to load this code into your memory and it takes time at startup so we are doing great when we are running the application but I’d start up the the time was slightly increased and it actually even destroyed all the games we could gain by pure speed improvements so and it adds also a lot of complexity so it’s not really a success at a conclusion first step one of our NR we think that it should be possible to unify completely annotation processing and reflection at compile time so maybe that’s something that’s interesting for the java community at large or even for new languages like cut Lenore yeah new languages that would like to design their annotation processing api’s and reflection api so that they match each other they are easier to remember easier to use more compatible and so on i step 2 and step 3 we think that it’s just a generalization of all the work that has been done an Android recently during the last 23 years where a couple of new libraries have been introduced and we’re using annotation processing to circumvent use H of reflection we think that R&R demonstrate that this approach is feasible but actually not so much paying back so we initiated this research to achieve a faster dependency injection for Android we didn’t really at to that point but it was interesting and I think we’ve been very far in exploring annotation processing and reflection we plan to release a new version of juice and robo juice based on our and are reflectors because there are some improvements we’re not sure yet exactly how we are going to do that and when we get to decide on that and yeah we want you to share that with you so that you get a better idea of what annotation processing means how it could be unified with reflection why do the api’s are similar or different and what are the alternatives do you have any questions comments yeah thank you very much by the way yeah yeah not all of them sorry yeah yeah yeah sure yeah yeah our idea was not only to improve the performances of dependency injection by improving the dependency of juice and recycling it into rebel juice we think that our research was had a roller scoop involving JSON parsing for instance or or em like you say John android which is a bit limited by reflection as well so yeah we investigated that they are indeed some dip some new libraries that came up like Logan Square I don’t know if you’re aware of this one but it’s actually performing very well and not using reflection at all just using annotation processing and streaming API yeah nope nope nope no no it chooses yea it chooses a streaming API of Jackson yeah ah oh yeah yeah yeahs exit mmhmm yeah yeah and we think that too we we actually are a bit surprised that this problem is that you address directly by google but it looks like they have other issues to address let yeah it would be an improvement even for Jackson parsing or M lies but as the reef the results of

juice with the fork with R&R and that’s so exciting I don’t think we’re going to pitch our self in for King direction to yeah yeah how many objections methods are created by generating code okay so the question is about the number of methods created by generated good I guess that’s your concern is the decks limit yeah so it indeed you create like as you could see with reflectors like three four methods / classes that you want to use during reflection so it ends up to be like four times the number of classes that will use rnr the answer so in our application we are also struggling not to use multi decks because it’s lower so we are also trying to take you a lot of care not to bypass the exclamation actually yeah we got like maybe 2,000 new methods counting in which is a lot for us so it’s also one of the drawbacks so yeah we can gain like ten percent but we are going to increase our text the number of methods in our decks increase the complexity of juice not sure it’s worth it but yeah that’s also one of the limiting factors of the annotation processing approach at large when you think about it butter knife is going to add an a good number of methods same for darts and from everything so if you do it for ya systematically for all new technologies like JSON parsing or M light and so on and so on you will a lot of generated code that will like decrease your decks limit and you will have less space for your code so yeah it’s something to take into account yeah right any other question maybe just to finish I like to say that we think that the true solution what we have been trying to do is to patch actually some deficiency of the gvm on Android so it should be done at that level so it could be possible to get exactly the same thing as Java does it’s it means that we could in line all reflection code not with ahead of time compilation but with just-in-time compilation like a pc g vm does so yeah that could be a solution also yeah the compiler also could do the dependency injection but that’s kind of a different way to approach the solution thank you very much