Well that would only be if you wanted a reasonably accurate model of the real world.

Easily flagged by the compiler. They also have a comment that the Guy class has no knowledge of the Girl's age so they're on the right track. Between the compiler error and adding a main() function as I suggested, the solution becomes so apparent that I didn't take the time to spell it out--I just implied it with the part about where to do the instantiation :p .

The code isn't that bad...

The biggest problem is that they should introduce a main() function where one or more Girls can be instantiated and then passed as parameters to Guy.willGirlGoOutWithMe().

I'd also invert Guy.isUgly to Guy.isHandsome to avoid negation and clarify Girl.willGoOutWithGuy() but that's a nitpick.

I was also thinking... If you really need to deliver a thin package (e.g., customers are using it for mobile devices and library size is a deciding factor between you and the competition), you might do a custom fork of the Apache source. You should be able to delete the classes/files you don't need and hopefully still track upstream changes without too much grief.

Sounds like you could spend some time learning how to work a build/dependency tool like Maven or Gradle. The former has a plugin that will make fat jars for you: https://maven.apache.org/plugins/maven-assembly-plugin/index.html .

You might also see if the swagger or RAML projects are useful--I haven't tried them myself but I heard them come up in another discussion about API client SDKs.

I'm at various stages with the following:

Rust: Systems language from Mozilla. Provides managed safety à la C#/Java but accomplishes it through compile-time static analysis instead of runtime garbage collection so you get performance comparable to C/C++ without so much risk.

Druid: distributed/large-scale online analytics processing. Provides an interesting mix of precomputed aggregates with options for granular scans when needed.

Electronics: Just bought the Circuit Jam app for Android. It's a gamified approach to learning how charge and current and voltage and resistance relate when wired in series or in parallel with e.g., resistors and capacitors and such. Once everything is unlocked, you end up with a basic touch-oriented circuit sim.

Deep-learning/TensorFlow: Deep learning is something of an umbrella term for the resurgence of the neutral network approaches to machine-learning/artificial-intelligence. Using these new techniques, we're starting to see some progress in image/voice recognition, etc. E.g., Alexa/Cortana/Okay-Google/Siri, self-driving cars, etc. TensorFlow is an open source framework from Google for composing the computations at a little bit higher level.

Not mine but a relevant koan:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

Agreed. LZ4 is the reigning champ when one needs high IO/throughput (though other algorithms achieve higher compression ratios). Snappy is another codec to consider--it's almost as fast but sometimes available/compatible where LZ4 isn't.

Another general-purpose tool to look into would be the Apache Parquet format. It makes use of run-length encoding, bit packing and record shredding to promote a very concise representation of encoded data prior to compressing it. It does look like there's a C++ library (https://github.com/apache/parquet-cpp), although I don't know how robust it is compared to the Java implementation. Here's an interesting article about it: https://blog.twitter.com/2013/dremel-made-simple-with-parquet