Feel like I had to comment since I'm self taught and I just read "Java Concurrency in Practice". :D

  * Effective Java
  * Java Concurrency in Practice
  * Head First Design Patterns

Take a look at dated, but still relevant book by Brian Goetz - Java Concurrency in Practice - many problems are illustrated with a code section.

[1] https://youtu.be/dGVqrGmwOAw?t=23m57s
[2] https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz...

http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...

It's old, but the material holds up well since it covers a lot of fundamentals

It's a great intro to concurrent programming with lessons that apply to virtually any high-level programming language. The chapter on the Java memory model is the best practical description of how languages map to multi-processor memory models I have ever read. (Chapter 16 in my edition.)

After reading this book it's easy to understand why concurrency features in other languages are necessary and what they are doing behind the scenes. Golang channels come lightly to mind.

Gosling's "The Java Programming Language".

And Josh Bloch's "Effective Java".

After that, Java Concurrency in Practice.

Langr's "Agile Java" is good for just that.

Bloch, Goetz, and Doug Lea have each written excellent books on java concurrency.

That's just about all the java books I would want to recommend. Many j-books are trash.

1 - http://www.amazon.com/gp/aw/d/0321349601

I highly advise reading "Java Concurrency in Practice".

Note that future Java primitive classes don't have monitors.

http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...

I only know about that book because of Rich's mentions of it.

To be honest, I"m also a little surprised that the Pickaxe book is in the list. Not that Ruby isn't the bees knees; it just didn't strike me as being influential on Clojure.

Not sure what threading primitives you're talking of, but it depends. In general Scala has very sane abstractions for dealing with concurrency.

So what's some really great, clean, elegant object oriented code that I could read to better understand what makes up good OO design? What are the books one should read to develop a deeper understanding of OO's qualities? It doesn't matter what language or platform they focus on, since I think the fundamentals ought to be independent, and I'm willing to work hard. Rails internals, Django internals? Some Java framework? Or is there some awesome piece of Smalltalk code out there that demonstrates the roots of OO? Is the Gang of Four book still relevant? Where do you go for getting the bigger design picture?

For context, I've done a lot of Java (Android) but I don't think I've been exposed to good large scale design in Java (I've read Effective Java and Java Concurrency in Practice, but both of those deal with the nuts and bolts of programming in the small) Most of my functional programming experience is with Clojure, which is very opinionated and takes a radical approach to OO, and I think the bar has been set kind of high by Rich Hickey.

Please don't tell me to go get a job at Google or your company where the code is beautiful all the time; that's just not fair.

2) Remember to work on projects that are something more than algorithmic puzzles. Algorithmic puzzles are fun, great and are brain gymnastics, but you should also learn how to write low-level socket code (Richard Steven's "UNIX Network Programming" books are excellent in that respect), deal with concurrency (switching languages again, Java Concurrency in Practice is a great introduction).

3) Participate in open source projects. Dan Kegel has an excellent guide on how to contribute:

http://kegel.com/academy/opensource.html

Even if your contribution to an open source project is small, it will require reading and understanding a great deal of non-trivial code.

Finally, as moonpolysoft said, don't call yourself a ninja or a rockstar.

That said, for most orgs, the biggest changes you might see would be in libraries and frameworks used. There will most likely be less XML, better build tools and more modular library usage than 12 years ago.

Java Concurrency in Practice (2006) is older but relevant and clearly describes concurrency on the JVM. A must read for any Java, Scala, Clojure, etc. software engineer; well-written, enjoyable, concise.

Practical Object Oriented Design in Ruby by Sandi Metz is a fun read packed with good principles for working in Ruby that are applicable in general to object oriented programming.

Smalltalk Best Practice Patterns by Kent Beck is worth a read because the general principles are applicable to any OOP language.

Clean Code by Robert Martin is excellent but a time commitment. (If you had to pick between SICP and Clean Code because time is at a premium I'd err on the side of Clean Code for practicality. Writing maintainable code is paramount.)

The Joy of Clojure (Fogus/Houser) is excellent and mentally digestable even if you have no Lisp or Clojure background.

The book "Effective Java" (from 2001) still has to one the "must read" for any Java programmer that didn't read it.

In it Joshua Bloch has always been very clear, from the start, about all the deeply ingrained ugly Java warts that Java had from the start (and still has). Like for example the complete and total utter impossibility to respect the equals() and hashcode() contracts in the face of inheritance.

Took a long time to set in but now quite some Java programmers are beginning to accept that having equals() and hashcode() at the top of an inheritable OO hierarchy may not have been the greatest thing since sliced bread.

The second book to read is Goets and al.'s "Java Concurrency in Practice" (one of the best looking programming book cover ever, which never hurts an incredibly high-quality content).

But the real lesson is that: Java is too complicated and has way too many warts to ever produce beautiful code. The JVM is not all bad but "Java the language" is really fugly.

Switch to a language that has a saner way to deal with concurrency (Say Clojure's STM or Go) and you can throw most of the pages in these books to the trash.

I think one of the best ways to learn software architecture is to have a clear view of what the challenges are, and the Kleppman book does a really good job of providing that clear view.

[0]https://dataintensive.net/

Our developers use Java (mostly).

Our research department uses whatever they are most comfortable with for research, but the result of their research is coded up in C++. If we had to do it over, we'd probably do everything in Java. Misc. notes:

Personally, I am WAY more productive in Java.

I supplement Java with Clojure.

I find the performance penalty for using Java is pretty-much negligible. It's always how you do it that matters more than what language you do it in. Don't use Java Generics for number crunching though... use a dedicated primitives collection library like Colt.

Java and C++ are quite similar in some respects. I would say though, that it's easier to go from C++ to Java, than from Java to C++.

Best C++ books:

Accelerated C++ by Andrew Koenig and Barbara E. Moo

Effective C++ by Scott Meyers (make sure you get the 3rd edition)

Best Java books:

Effective Java by Joshua Bloch

Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, and Joseph Bowbeer

If you have to use C++, start using the Boost C++ libraries early on. You can learn a great deal just by using the Boost libraries, and reading their documentation.

The older generation are in this place because back then none of the technologies you listed existed and so they had to know the more low level things.

A book that might help some of your knowledge gaps (at least directionally) is The Imposter's Handbook[1] by Rob Conery.

If you're specifically aiming to get away from CRUD take a look at the various Domain Driven Design books by Eric Evans[2] and others. This is the opposite direction to your ask though (more high level than low level).

If you want to go deeper in Java, read Effective Java[3] and Java Concurrency in Practice (JCIP)[4]

Lastly, if you want to experience the reasons why some of that early comp-sci stuff happened the way it did, playing with expensive hardware is the least effective way to find understanding of constraints. Instead consider grabbing devices with significant limitations like an Arduino, ESP32, or similar (I'm partial to the Wio Terminal[5] and M5Stack[6] as interesting easy to get started devices, but others would suggest various Arduinos or Raspberry Pi devices). Realistically you're going to learn much more by coming up with a self-challenging project and completing it than just by learning it for the sake of learning.

[1]: https://bigmachine.io/products/the-imposters-handbook/

[2]: https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

[3]: https://www.amazon.com/Effective-Java-Joshua-Bloch/dp/013468...

[4]: https://www.amazon.com/Java-Concurrency-Practice-CONCURRENCY...

[5]: https://www.seeedstudio.com/Wio-Terminal-p-4509.html

[6]: https://m5stack.com/

As a point of comparison, I put together a quick Python script that defines a simple single-threaded event dispatcher and then does the same thing as your testPerformance() test, and it handles over 296k events/s on my machine (where javaEventing handles 3.7k).

This use of multi-threading is used to achieve full asynchronisity

The way that you're currently synchronizing, the only concurrency you're seeing is for your handlers. You only trigger and dispatch out to handlers one event at a time.

There are two scenarios where threads are always going to be unavoidably slow: high contention, and processor-bound tasks with more threads than processors. Your current synchronization policy pretty much assures you're going to run into high contention, and if you're using this for processor-bound tasks, you're going to pay a severe tax for the number of threads you're generating, as well.

Put in the threadpool. Take a look at ConcurrentHashMap and CopyOnWriteArrayList. Work on your synchronization policy. High throughput concurrency and eventing is hard, but Java actually has a lot of nice building blocks to work with. If you want a good overview, you should check out Brian Goetz's Java Concurrency in Practice.

At first I open the ToC and go read the few stuff I do absolutely want to read about and "can't wait" to read.

Then I force myself to read the entire book like a novel at least once.

One of the great thing about reading it at least once is that once a while you'll read something you don't really think you'd need right away or that won't necessarily "click through" but, later on, you'll remember "seeing it somewhere in the book". And bam, you take the book's ToC or index and find back what you're after.

I've done it countless time with "Java Concurrency in Practice" for example. At first I read what I wanted to read the most. Then I read like a novel. Then now I use it as a "reference".

(most of the book, just like most Java books, can be dumped to trash now that I'm working with a language using lockless concurrency but that is another topic ; )

You should read Java Concurrency in Practice, the entire book is explaining all the concurrency methods they have. And thats already a very good book (one of the top in my list). In Scala, I just need to read through a few pages of documentation and the rest is simply practice in mixing and matching patterns and a few configuration settings.

#2. ... hmm, that might be it.

Other books I absolutely loved are Effective Java 2 and Programming Interviews Exposed. I'm waiting for Amazon to ship me the second edition of the latter.

Hackers and Painters is a classic I default to whenever I'm looking for inspiration.

Also, anyone working with an OOP should really read Java Concurrency in Practice. That really helps in terms of learning how to think about multiple threads in a OOP world.

Not sure how events by themselves can solve the threading issues as events can be multi-threaded too. I've seen people write far worse event driven code than multi-threaded code. If people want to use events heavily, I think it's better to use a well known design pattern so others can understand what you are trying to do.

You're also completely correct about placement new: I am working on a cleaned up version of this class, this was essentially a first pass to get myself more familiar with concurrency in c++0x. What complicates things a bit is that allocators are (much like all else in STL) meant to be used as class template arguments, which makes main separate compilation impossible -- hence the need of an adapter from an STL-style allocator to a pure virtual class. Separate compilation is why I also made a void* version of this initially.

I have a much cleaned up version in the work that will handle more than void . There's an implementation I call it ConcurrentLinkedQueueImpl that handles just void , that is compiled separately -- and there is generic version ConcurrentLinkedQueue that is specialized for void * (ends up just proxying the calls to ConcurrentLinkedQueueImpl), with the generic version (in turn) using ConcurrentLinkedQueue<void *> and placement new to hold any type.

Once again, the version posted there was a rough pass to get myself familiar with 0x concurrency constructs and hazard pointers -- the code is fairly messy.

[1] http://www.amazon.com/Art-Multiprocessor-Programming-Maurice...
[2] Everyone should read this book cover to cover -- http://jcip.net/

I challenge anyone to gain an understanding of volatile variables from his description. His example of volatile vs. synchronised contains an example of incorrect code but not an example of how it should be fixed, and doesn't even contain a particularly clear explanation of why it's bad.

The explanation of the bytecode generated for a synchronised method compared to a synchronised block is curious if you're into bytecode but totally useless for a working programmer, and offers no guidance on choosing between them. Worse, it actually makes it sound like the option you almost certainly don't want (the synchronised method) is somehow more efficient than the almost universally better method (synchronising on a lock object, which provides much better lock granularity, prevents deadlock in the case of some external object claiming your object lock and generally makes lock ownership much clearer and easier to track).

Finally, his example of the AtomicReferenceFieldUpdater ignores the javadoc (This class is designed for use in atomic data structures in which several reference fields of the same node are independently subject to atomic updates) and proceeds to show a contrived example of a compareAndSet that is really only a more confusing set, and doesn't actually achieve anything at all.

There are much better sources to learn this stuff if you really need to know it, starting with Java Concurrency In Practice - no Java programmer should be writing concurrent code without having read the first 7 chapters of this.

"Say you had the code

  // run in two threads
  sb.append(key).append("=").append(value).append(", ");

  key1=value1, key2=value2,
  key1=key2value1=, value2,
  key1key2==value1value2, ,

[1] is weirdly worded, or even wrong (I don't think "the lock could be release at any point" is correct) but the sample result does make sense to me if there are multiple threads banging on it at once. StringBuffer's append methods are synchronized, but without external synchronization, multiple calls could be interleaved.

I don't recall ever having heard of [2] before, and my copy of Java Concurrency in Practice isn't immediately at hand.

- Theoretical CS:
- Compilers: Principles, Techniques, and Tools (The
Dragon Book)
- Introduction to the Theory of Computation, Sipser

- Programming:
- Java Concurrency In Practice, Brian Goetz
- Generics in the Java Programming Language, Gilad Bracha
- Professor Frisby's Mostly Adequate Guide to Functional
Programming
- Unix for Poets
- Modern C++