Agreed. The least effective developers I’ve had the displeasure of working with never understand how their code executes end-to-end. And the best ones have a deep knowledge of it.

This is no fluke! If you don’t know how a classloader works with the Java classpath, how to set various JVM flags for operating the JVM, etc., then I’d argue that you’re an amateur, and I wouldn’t trust you to write correct code in a production setting. It’s critical knowledge to know how your code runs, and if you don’t know that, then stay away from production systems. If the goal of these courses is to teach students enough about Java to use it in a professional setting, then knowing how classfiles are produced, bundled, distributed, loaded, and executed by a JVM is critical knowledge.

More succinctly, if you don’t know how your code makes it to a production server and gets executed, you’re not ready to work on it.

(And if the goal isn't to teach students how to use Java in a professional setting, then why are they learning it at all? Use a teaching language so students can focus on the concepts instead of Java's idiosyncracies.)

eh, I understand the sentiment - but it's a little overkill. Junior programmers can be code reviewed and taught these things over time, and also be wildly productive in a production setting.

Sure you can teach junior programmers all kinds of stuff that they should have already learned or should know how to learn, I do it all the time. I'm arguing that this is crucial information that even entry-level engineers should know. If they don't, then I give them a link to the relevant documentation and politely ask them to read it. It's a prerequisite.

Are there any books or articles that go through the things that you’ve mentioned like how the class loader works etc? Most of the tutorials or books I have seen do not even touch this aspect and I want to get better at it.

Oracle documentations typically. And javadoc for those classes.

But I don't think it is such a key to anything. It is sort of stuff that is easy to learn when you need it, easy to forget and not useful most of time. It makes sense to read when you done learning other things, but not for beginners.

Isn't eclipse a piece of tooling? I mean I think the best argument against teaching eclipse is IntelliJ is much better, imo, and is more widespread than eclipse at this point. Student should have a module/class whatever about command line tools as well. I this comparison is comparing two things that aren't comparable, an IDE vs learning the CLI. I also think you contradict yourself in your last sentence. Teaching an IDE in class should help people be comfortable with their tools but at some point they might need to know what the tool is doing under the hood.

> but at some point they might need to know what the tool is doing under the hood.

The problem is the IDE makes it so easy to never have to look under the hood, to the point when people take a peek the get overwhelmed and quickly return to the comfort of the IDE.

However, in real world of production environments there will be no IDE holding your hand and as such you can't get away without a good understanding of the engine under the hood.

Yeah they’d probably be using some build system or framework or script and still wouldn’t need to know the invocation for javac.

The situation in which you run javac or edit in vim in production is absurdly rare.

In real world, you always use tools and in real java world there is always ide or application server or something.

I haven't really played around with java since the 90's, and I bought a Java book and tried hopping back in. It was really frustrating because the book uses 8 and I downloaded 9 and Eclipse was slightly diffferent, something with modules blah blah.

Plus downloading the actual Java SDK was confusing, the versioning, it not being free anymore...

OpenJDK packages seem easy enough.

In particular, command line compilers have been used virtually the same way since the first command line interfaces, so knowledge of javac is definitely transferable.

IDEs change more frequently.

I agree that many developers are not very adept with tooling, but is that because they don't use the CLI? Or is it just that they aren't interested in those parts of software engineering? Eclipse is a tool too, and not a simple one either.

The author is specifically talking about students. The emphasis at this stage plays a key role in whether they'll have that interest or not. Knowing is a prerequisite to developing interest.

I agree, but regardless of if they're exposed to a CLI, they will be exposed to tooling. Why is GUI tooling less likely to spark that interest?

GUI tooling almost entirely uses the command line layers under the hood, so it is strictly more complicated while hiding more of the real process - the worst of both worlds.

My point about Git is an example of this. Teaching Git is hard, partly because Git's command line UX is bad, but layering the complexity of, e.g., EGIT on top doesn't really remove most of that and makes it harder to teach (because expressing what to do in a GUI is strictly harder than communicating text commands, among other things).

EGit doesn't call the git command line application, it uses a Java implementation of git. Although I can agree it's debatable whether they have improved on the command line interface or not.

IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.

What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.

It could be - but in the majority of cases it isn't - and you will need to fall back to CLI and UNIX abstraction layers when the IDE breaks - because that's the way it's been done since forever and if you want to work with existing (and probably future) tooling and be able to solve the problems when they happen in the layer above you will need to learn the interface used to expose all the functionality to the tools under the hood.

> It could be - but in the majority of cases it isn't

I don't think that's really true, at least for the Java ecosystem which is implicated here. Eclipse does not call out to command line tools for most things, as far as I've seen

> "What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler?"

Build and CI systems don't go through a GUI IDE, making it required for developers to understand the CLI anyway.

As an example, Maven support in Eclipse and IntelliJ don't call the Maven command line application, they operate entirely within the IDE.

> What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler

It's not simpler! It's way more confusing to figure out that your make file told your compiler to run a command with some unknown set of obscure options that are causing an error than to just have the IDE pop a dialog and tell you in plain words, or better, not even let you set an option incorrectly in the first place.

The CLI is more explicit than a GUI. In a GUI, compiling / running / testing your code is an afterthought that happens at the click of a button.

In the CLI, you have to be explicit about what actions are taking place. You have to physically type in what command you want to run and the different arguments to it.

The convenience of a GUI is fantastic, but the abstraction makes it a very bad learning tool. Being able to open up a terminal and fix the inevitable git / build / configuration errors is a very valuable skill that developers should have.

I don't see the distinction. I started my career using command line tools and am completely comfortable with them. Yet for more recent projects I stay within the IDE (usually Visual Studio).

It doesn't matter whether I tick a checkbox for compiler warnings or add that option to the command line. The only difference is the IDE makes options easier to discover.

It's the same for Git. A decent GUI gives you a much better visual picture of the state of your working copy.

Maybe gradle then? Or actual tooling?

I’d agree that some focus on that in CS programs would extremely valuable. Maybe things are better now, but when I went in 2008-2012 git wasn’t even mentioned and basically all tooling was learned on your own.

I haven’t taken an introductory CS course since the mid 90s, so I don’t have enough knowledge to know whether I agree or disagree with you. What was the base level of knowledge like when you were in introductory courses? Back in the day, you couldn’t guarantee that everyone could even turn a computer on, so for loops were a second midterm thing.

Edit - I should mention that my last sentence was the perspective of 18 year old me. I was 18, but in my defence I was 18. :)

IDE counts as tool too. And knowing it is not different the knowing other tools.

>A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers

being a useless developer doesn't make it not computer science. not all of computer science is software development.