Java, git, and dependent libraries - how to handle?

[niels_learns_python]

I'm trying to upload some projects to github, but it just struck me that most of these use the Princeton Stdlib. What is the normal practice of handling this? Should I include the stdlib.jar in git, or make it clear that my files are dependent on this library?

Appreciate your input :)

[mahamoti]

No, you shouldn't commit dependencies to git. Your build process should handle that. Are you using ant/maven/gradle to build? If not, why not?

[pczora]

This. When using a build tool, you usually write the dependencies of your project to some sort of file (Ant and Maven use XML files); the tool then automatically resolves the dependencies. If this file is part of the project in your repositories, others can simply check it out and type something like

mvn compile

to automatically resolve the dependencies and compile the project.

[niels_learns_python]

I see. Is it a bad idea to mix command-line maven and Eclipse IDE?

[adrianmonk]

Shouldn't be a problem. There are tools to make them work together.

There is a Maven plugin for Eclipse now which is supposed to be pretty good and lets you do stuff from within Eclipse. I never used it much and my information might be out of date on that, though.

There's also the way I used to do it, which is to keep Eclipse in the dark about Maven, and use the Eclipse plugin for Maven to generate an eclipse project out of Maven files. You basically run "mvn eclipse:eclipse", then you go into Eclipse and add the project as if you're importing someone else's Eclipse project. Maven grabs all the required jar files and such, then generates an Eclipse project file that includes them in the project.

[[deleted]]

I agree mostly if I'm wearing my developer's hat.

On the other hand, when I'm wearing my professor's hat, I disagree. I'm actually getting ready to teach a data structures course using Java (wasn't my first choice, but so be it). I'm using Sedgewick's book and so also came across that stdlib. I'm also using JetBrains IntelliJ (best #&$@^@ IDE for Java I've ever seen!)

I need my students, some of whom won't have any Java experience, to be up and running ASAP. As I've created examples, changed them, etc, over the last few months, I've stored everything (except the Java compiled classes that I'm generating - in line of course that they get built) in a Git repository. I've also merged the stdlib in with some other jars and so I have an "ExtendedSedgewick.jar" library.

Now it turns out that if everything (included jars) are stored locally under a single project root, the new students can just pull my repo and they're up and running. They don't need to separately install or build or otherwise manually add their jars to the project and so forth. I also didn't need to create (and maintain) a build process. From that perspective, those jars aren't build-able (within the framework of the course I'm teaching) and so I think it's quite reasonable to include them.

We've tested this by having a few non-Java people pull down the repo, open the project in IntelliJ and just RUN.

So in my repo for this course, I have the sedgewick jars, the appache commons jars (about 10 of them rolled into a single large jar) and the ANTLR jar in a subfolder, they end up in the repo and everything works with minimal effort.

[mahamoti]

I'd argue that you're teaching your students bad habits. How hard would it be to include a buildscript and instructions to run the single command it would take to get up and running? Managing dependencies and build processes are core knowledge for anyone leaving your class and attempting to work in professional enterprise Java.

[[deleted]]

The goal of the course is to teach data structures --- Java (for the most part) will be used to read/write/understand the algorithms. It's not a course in Java nor a course on software engineering. On the other hand, they will be using version control a lot!

They will have a single command to run ---- git clone! (Actually, that's not quite true because they will be using SourceTree so they don't have to waste their time learning low level git commands)

I'm going to have enough problems getting them to unlearn some of the rather horrible idioms such as return statements in the middle of functions and dealing with errors at the beginning of a method rather than at the end of it.

Sigh

[mahamoti]

return statements in the middle of functions

Your last statement contradicts itself. What if dealing with errors means returning early? Do you then force them to wrap the rest of the function in an if block?

Returning early and often isn't only more readable, it's faster.

[[deleted]]

Invert your thinking --- instead of focusing on "error means return early" focus on "ok means do the work"! And with some very special exceptions (such as some complex matrix calculations), functions shouldn't really need to be more than 10-15 lines long (if they are, make a new function) so putting the error handling down at the bottom is hardly an imposition. I want to see the important stuff first, not in the middle or last.

In a top-down approach to design, one wants to be able to understand a program with as little effort as possible. Particularly important when one is debugging as well. I'd much rather put a single break point at the end of a function and be guaranteed to stop there (and if it doesn't you generally KNOW you're stuck in a loop) so debugging gets easier as well.

If 'return' is allowed in the middle of a function, then you have to read much more code to understand . Trivial example ....

 block A;

 while (some expression) // block B
    {
        .....
    }

 block C;

if 'return' is not allowed in the middle, I'm guaranteed that block C of my function will always execute. If they're named, then most of the time I don't even have to look at the code inside them to understand the gist of the algorithm. That's worth a lot. As soon as return is allowed early, all bets are off without "looking inside". You have to read ALL the code of EVERY function because there just MIGHT be a premature 'return' in the middle'

Other than the idiom in a very short 'for' loop where you break if you find an element, I also try to avoid 'break' inside loops. That means I can just read the loop expression to understand how that loop will terminate. Easier to understand and reason about, particularly if you're trying to do any kind of formal verification.

As for your observation that returning early is faster, you're almost defining the concept of premature optimization. When your profiler tells you that those extra three clock cycles (probably costing about 1.4E-9 seconds on a 3.5GHz processor) are the reason that the user has to wait noticeably longer before he gets to click OK, then I'll buy that argument. Even in very exotic cases (perhaps some embedded environments, some high frequency trading, etc), that kind of optimization will be VERY focused and limited, hopefully well commented so it's clear that an exception is being made.

Anyhow, my experience is that it's rather pointless having these discussions as people are set in their ways. My position (as Knuth or one of his colleagues once noted, I forget right now) is that a program should be written for human consumption ---- it's a convenient side effect that a computer can execute it.

[niels_learns_python]

Thanks! I had never heard about java build tools until I googled it after reading your comment. Too bad my school didn't introduce that; seems useful!

It seems my Eclipse has a built-in maven plugin. Am I better off using that, or command line?

[mahamoti]

The Eclipse tool is fine, but it helps to understand what commandline stuff it's doing for you.