On 27 January 2014 20:39, Oleg Kalnichevski <[email protected]> wrote: > On Mon, 2014-01-27 at 20:14 +0000, sebb wrote: >> On 27 January 2014 19:43, Oleg Kalnichevski <[email protected]> wrote: >> > On Mon, 2014-01-27 at 19:33 +0000, sebb wrote: >> >> On 27 January 2014 18:54, Oleg Kalnichevski <[email protected]> wrote: >> >> > On Mon, 2014-01-27 at 13:24 -0500, Gary Gregory wrote: >> >> >> Wow this is confusing! Why not repackage the classes instead of >> >> >> renaming each one with an HC4 postfix? >> >> >> >> >> > >> >> > That was my initial plan, too. But try re-writing the sources using >> >> > regex when you have multiple classes with the same name. I had to give >> >> > up after a full day of wasted efforts. My regex skills are very basic, >> >> > though. So, improvements are highly welcome >> >> > >> >> > http://svn.apache.org/repos/asf/httpcomponents/httpclient-android/trunk/build.gradle >> >> >> >> How do you decide which classes need renaming, and which ones don't? >> >> >> > >> > By comparing different versions using reflection. It is in the script. >> >> The script contains lots of special ("magic") package and class names, >> so presumably a simple comparison is not sufficient. >> How are these exceptions determined? >> > > There are several differences between version 4.0-beta1 used by the > script and some arbitrary snapshot taken by Google. Some things > unfortunately have to be adjusted manually.
If they took a snapshot, there must be a corresponding revision. It would be trivial to create a tag once the revision has been established. >> >> == >> >> >> >> Are there likely to be many developers who need to provide an >> >> application that runs unmodified on both Android and Java? >> >> If not, then it would surely be sufficient to just provide a shaded >> >> version for Android which uses a different package name? >> >> >> > >> > Maybe not. But there are enough applications that are compiled against >> > Android APIs that cannot be used with repackaged code. >> >> Not sure I follow. >> >> If an app is compiled against the Android APIs, I don't see how it can >> take advantage of any new classes without changing the source and >> recompiling. > > How about multiple implementations of the same abstract API, one being > newer and containing fewer bugs? If the implementation class name is the same, I don't see how the two versions can co-exist without classpath issues. If the implementation is a new class, I'm not sure how the existing binary code can take advantage of the new implementation. What would cause the existing code to find the newer class? >> In which case, would it not make sense to convert the code to use all >> new class names? >> >> Maybe I'm missing something, but I'm not seeing any great advantage to >> the proposed Android build. >> > > If you are familiar with Spring, think of Spring Rest template. No, I'm afraid I have no experience of Spring. > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
