Building abstraction upon abstraction, design pattern upon design pattern, isn't as much of a chore as it felt before.
I feel like I am building a large structure to solve a simple problem, like a rube goldberg machine, and I can revel in the complexity.
There is a certain zen-like quality in chaining seemingly unrelated design patterns together to create a crazy behemoth that still completes the task assigned.
I suppose doing Enterprise™ Java™ Development™ for a living won't be so bad, after all...
Java is a programming language you can use while your brain is off, because it's just on-rails (lol) superfluous manual template expansion. While you might be lulled by that sedating feeling, do not confuse that with any sense of quality.
Name:
Anonymous2016-06-14 6:45
it's fun to write code like that when you do it alone and have a well defined scope. now imagine trying to debug huge bloated Java code written by someone on the other side of the globe with comments like
//sets x to 2 x = 2;
and no other documentation. now imagine that in true ENTERPRISE fashion you don't have access to all the source code because muh secrets and you have to either treat it like a broken black box or decompile/disassemble it (protip: all decompilers are different flavors of shit while bytecode/jasmin/smali is assembly for a computer that doesn't exist).
the same goes for C++ and C# - the bigger and more enterprisey things get, the worse it is
The JVM is the most amazing piece of software in existence. It gets near bare metal performance and runs on basically all hardware out there. I used to make fun of the JVM, but now I realize why Google decided to use it as the foundation for Android. I don't know why anyone would choose to write code on native platforms anymore. Anything not using the JVM inevitably is under vendor/hardware lock-in.
Name:
Anonymous2016-06-14 7:27
>>7 You were wrong all those years, I remember that.
Name:
Anonymous2016-06-14 9:05
>>6 Enterprise documentation should be filled with formalized system models and project specification documentation.
Name:
Anonymous2016-06-14 9:25
>>9 enterprise documentation is filled with bullshit
>>16 ART is a runtime that executes Dalvik bytecode, the instruction set, which is a different specification from Java bytecode, meaning that ART cannot interpret Java bytecode, therefore, as a JVM is defined as executing Java bytecode, ART is not a JVM.
Name:
Anonymous2016-06-17 10:16
>>17 it's a bit more complicated than that. Dalvik bytecode (.dex) on older devices is turned into optimized, JIT-compiled version (.odex) that is then executed by Dalvik VM. on newer devices, Dalvik bytecode. ART is able to compile .dex files ahead of time and just execute them natively.
Isn't Java the main language used by Android appers? So do you write source code in the Java language and then compile it to Dalvik bytecode rather than JVM bytecode?
Name:
Anonymous2016-06-18 18:57
Check em
Name:
Anonymous2016-06-18 21:42
>>22 yes, Android compilers turn Java code into dex bytecode. then they turn them into .apk files which is a fancy way to say .jar which is a fancy way to say .zip and sign them. then ART turns them to machine code anyway.
Name:
Anonymous2016-06-19 1:35
>>22 JVM bytecode is actually retarded, slow, and hard to optimize. It's also a stack machine, which while it was cool in the sixties, he's a lot of problems. DVM is a register machine. With that, many instructions for the JVM became irrelevant because you got it for free with registers. Overall though, Dalvik bytecode is much closer to the bare metal, and doesn't contain many of the pointless abstractions the JBC spec has, for example.
>>24 Not quite. Everything is compiled into a single file for Android, comparable to linking I guess, rather than .class file pollution.
Name:
Anonymous2016-06-19 2:04
>>25 Everything you say about a stack machine is entirely the intentional fucking point of the advantages of a JIT VM. It's disassociated with the number of real registers, so the compiler is free to shuffle it in any way it can, and view it in a more abstract dataflow model.
Name:
Anonymous2016-06-19 8:48
I have proven that Java is, in fact, as slow as balls. https://progrider.org/fossil/tree?ci=tip&name=antifibs java time: 136 ms python time: 62 ms racket time: 473 ms That's right, this dung-heap of an language is twice as slow as FIOC. What a joke. Larry Page is a fucking idiot.
Name:
Anonymous2016-06-19 10:48
>>27 Also, there's a Seeples test now, and it's only twice as fast as Python. Good for you Guido.
Cudder, if you write me a super optimized assembler I'll love you forever, nipah~★!
>>27 you're counting the cold startup time for the JVM, which everyone knows is slow but amortized over 2000 hours of uptime 100 extra ms is not that much sage
Name:
Anonymous2016-06-20 14:16
>>30 As I did with Sepples, Pythong, and Typed Racket. And if it takes a hundred milliseconds to start, it is as fast as C++, which is unlikely because it is not only slow as balls, but it (and the rest of them) use their bignumber libraries, but I didn't feel like going through the bullshit to do that for C++, it really would be impressive.
>>37 technically speaking they are Java bytecode on non-ART releases and a mixture of that and native code on the ones with ART. but that Java bytecode is not JVM bytecode because Android has its own virtual machine