Hi all, Well, thanks for all the help, but now I'm stuck on step the 9th, trying to compile SignApk.java. And I think I'm just going to give up.
I'm getting compile errors of the form: SignApk.java:20: error: cannot find symbol import org.bouncycastle.asn1.ASN1ObjectIdentifier; Look, I've installed plenty of programs from source before. Dozens. Now, I don't expect every program ever to be quite as simple as "./configure; make; make install", but this is getting ridiculous. For pretty much every other program I've ever installed, I've never needed to know much about what language it was written in, or any of the internal details of that language environment. Provided I've got the right compiler and/or runtime installed, I've just downloaded the source, checked the README or INSTALL file or doc/ directory, and then done something like "./configure; make; make install". Maybe it was "cp makefile.unix makefile; make; make install". Oh, sure, sometimes programs have had dependencies. But installing a dependency is just "apt-get install libdependency-dev". Or, "wget ftp://dependency.com/latest/dependency.tgz; tar -xf depencency.tgz; cd dependency; ./configure; make; make install;" And once that's done, I can go straight to the program I actually want to use, and the configuration/build step will *automatically* find the dependency, and make me a program which will *automatically* use the dependency. That's it. I'm not trying to hack on these java programs. I'm don't want to study the code for its own sake, or track down a bug, or submit a patch upstream. I just want to *build* and *run* them. That's all. Nothing more, nothing less. Now, I've got these three repos. And none of them have README files. Anywhere. (OK, platform_system_core does, but it doesn't actually contain anything worth reading.) Or INSTALL files. Or doc/ directories. Or configure scripts. Or makefiles. They do have what look like makefile fragments, with comments, but no help as to how to actually use them - and all of the Java build processes I've briefly looked at seem to use either XML or JSON as their build description format. platform_build has an "envsetup.sh", but it's bonkers. First, it tells you to invoke it as "build/envsetup.sh", even though it's not in a directory called "build". Then, you don't *run* it, you *source* it into your shell and it does a whole bunch of violence to your environment, like creating function/alias called "m" to build the tree. Because you probably didn't have "m" aliased to anything you wanted to use yourself, did you? And that's just platform_build. The other repos don't have an equivalent, at all. So, after all of this, I'm left with 4 theories about what's going on here. 1) Google is ignoring all industry standard best practices for writing and packaging simple command-line apps in Java. 2) There are no industry standard best practices for writing simple command- line apps in Java, because Java is so uniquely unsuited to the task that practically no-one ever even tries.[0] 3) Google is actually following industry standard best practices for writing and packaging simple command-line apps in Java, and everyone in the Java industry thinks that the issues I'm seeing are a perfectly acceptable state of affairs, and not, you know, bug-nuts insane. 4) James Gosling read the spoof interview with Bjarne Stroustrup about how "[C++] was only supposed to be a joke, I never thought people would take the book seriously", thought it would be a good laugh to do for real, and is trolling me 20-odd years later. Of these, 1) seems unlikely on the face of it. That just doesn't seem like how Google would get things done. On the other hand, if 2) were the case, why in the softly-spoken name of the Elder Things would Google have picked Java to write them at all, rather than Python, Ruby, Perl, shell, C, Go, DOS batch files, or one the many thousands of other programming languages ever created which seem much better suited to the task, by virtue of not needing to be compiled, or, once compiled, can automatically locate both themselves and their dependencies and can just be, well, "run"? But then that only leaves 3) and 4), which are the most terrifying of all... Or, there is an option 5), which is that all of the above isn't actually that complicated, and I am actually really gorram stupid for not understanding it. I'm certainly *feeling* pretty stupid after a couple of days of banging my head against this particular brick wall, and it's not doing much for my perpetual case of imposter syndrome either. Whatever. You can keep your Java. I've had it. Adam [0] Re-specifiying dependencies on the command line every time you *run* a program? Really? As if anyone would do "ls --link acl,attr,pcre,selinux" every time they wanted to list the files in a directory. And have you *seen* the dependencies for something like a text editor? Try it - "ldd /usr/bin/vim" - especially if you have vim.gtk or greater installed. Now imagine that every time you wanted to edit a file. I mean, *REALLY*? -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201407152320.33072.a...@spra.gg