[lawl]

I do.

I worked on a few large scale java web apps and regularily had to find and fix performance issues. I'm not sure if it would have been possible for me to easily dig into GC internals or find bottlenecks in Spring itself, without some lowlevel understanding.

So first of all you need some kind of lowlevel understanding to understand a GC. Hell I've talked to Java guys that couldn't explain the difference between stack and heap.

And you need to be able to support the "few tens of megabytes of libraries" (which surprise, are not just a few tens of lines of code) for real projects. If shit hits the fan and you can't google the solution, you need to dig into the framework code.

Which is (I think) is why the OP sais, don't use a framework if you couldn't code it yourself.

Sure you can work yourself top down the stack, but chances are (from my experience with others) that since Spring just works (in most cases) and for small apps never really have to deal with the GC, they think it's okay to not understand that stuff.... until shit hits the fan.

[lmm]

The reason I don't buy this kind of logic is there's always going to be a layer you don't understand. I've had programs I've written break because of JVM bugs, are you going to say no-one should be writing Java if they can't write their own JVM? I've hit bugs in OS-level libraries, are you going to say that no-one should be writing programs if they can't write their own OS? (I mean, ultimately hardware bugs do happen, so you need someone who understands how to build a CPU out of transistors - but I've spoken to designers at Intel who've said that no one person understands the whole of a modern processor). I can understand not using immature or obscure libraries if you don't understand them, but Spring and Hibernate are about as established as it gets.

You have to start somewhere - and, sooner or later, you have to learn to debug other people's code or systems. (Which is actually pretty easy with modern tools; you don't need a deep understanding of spring to find a performance problem if you have a decent profiler)

[lawl]

Well actually that kinda is what I'm saying. You don't need to be able to hack out a complete OS from the top of your head. But yes you should have some basic understanding of how syscalls works, what a kernel is and what it's job is etc. And with some docs implement your own. I actually think that's reasonable. No one expects you to hack out a kernel that has feature pairity with the Linux Kernel. And a basic VM isn't really that hard, it takes bytecode and executes the corresponding operations.

Again, I'm not talking about a full blown JVM with feature parity and all the JIT optimizations. But actually given docs and some time even implementing a JVM should be doable, sure it will be slow but interpreting bytecode is really not that hard.

You just can't do this if you don't have a basic understanding of C or other lower level languages.

Also your CV probably sais Software Engineer and not Hardware designer. So I'd say hadware bugs are out of scope.

[lmm]

> yes you should have some basic understanding of how syscalls works, what a kernel is and what it's job is etc.

If we're talking about experienced developers then sure, at some point people should learn that stuff. But as a beginner it's impossible to understand everything at once; start at the highest level, the level you're actually going to be working at most of the time. There'll be time to peek behind the curtain and learn the details of what's going on at lower levels later - and good programmers absolutely should do this. But I don't think people should start off without frameworks any more than they should start off in assembly.

> Also your CV probably sais Software Engineer and not Hardware designer. So I'd say hadware bugs are out of scope.

If that's what counts then my first job title was Java Developer :P