That way, you don’t have to guess, and your understanding of the return type is even checked by the compiler.

You still use exceptions to signal major errors. But, e.g., asking a map for a key it doesn’t have shouldn’t throw an exception, it returns None.

Even so, testing on large enough corpora of documents sometimes takes several hours or even several days. I added Hadoop support but it was PAINFUL to write and it’s incredibly temperamental trying to get it working. In addition, it’s a heavy-weight solution since each separate node has to create the entire cell grid and eat up all sorts of memory, meaning I can only have one or two worker tasks per 48GB, 8-core machine.

I tried switching the inner loop to the .par() version. Things immediately broke because of some non-thread-safe code that was using and reusing a static array to avoid lots of unnecessary garbage collection; but with this issue fixed, I get about a 6x speedup (average CPU usage about 600% according to ‘top’) on the 8-core machines. This is a big win and uses up no additional memory because the cell grid is shared.

I’m not sure why I’m not getting completely efficient CPU usage, and it definitely would be nice to have some way of tuning the innards, but even so, it’s a lot of gain for not very much work (and would have been no work at all if my code were thread-safe from the beginning).

BTW Cedric: See my comment above about ‘top’ — that’s how you figure out whether multiple threads are being used.

Now, I consider the aforementioned scenarios:
CASE 1: One of the answers given (either a, b, c, or d) is correct.
In this case, without looking the actual answers, it’s easy to understand that the chance to be correct is 25%.
Looking at the four possibilities, we see that both a and d indicate 25%: there are two correct answers, which is INCOMPATIBLE WITH THE SCENARIO.

CASE 2: Two of the answers given are correct at the same time.
The only way for this to be possible is that both a and d would be correct, and then the actual answer for the question would be 50%. NICE. Now when we want to map the 50% to its corresponding letter, we discover that only one option shows that number, which is INCOMPATIBLE WITH THE SCENARIO.

We are left with scenario 3: The correct answer is NOT LISTED, hence the answer to the question is 0%.

In this “answer” post, you are actually CHANGING THE QUESTION. However, I guess that is what some teachers would do, but does not justify B being correct whatsoever!!

The amount of JVM code (94%?) written in Java doesn’t seem particularly interesting to me. What seems *far* more relevant is the proportion of new functionality being implemented in Java, and that number is certainly far lower. Our shop, for example, still has lots of Java code, but a significant portion of new code is being written in Scala, and it’s only going to increase for the foreseeable future. To take this example to its logical conclusion, let’s say that at some point we are writing 100% of new code in Scala but Java still accounts for 90% of the code we have accumulated over the years. Would you still say that Java dominates in our world? That characterization would seem very misleading to me.

Also, a given number of tokens of Scala seems to get at least three times as much done (and more maintainably) as the same number of tokens of Java. So if I write 3000 tokens of Java and 1000 tokens of Scala, I’m really doing half of my work in Scala.

Don’t get me wrong; I hope Kotlin brings something great to the party, and I’m always on the lookout for a better language that looks viable. But I am always wary of opinions that there is no significant competition to Java on the JVM. People point to jobs openings and to StackOverflow questions and the like, but such metrics are deeply flawed, as discussed here: http://www.scala-lang.org/node/10923

Also, while I’m happy for the enhancements in Java 7 and those planned for Java 8, bear in mind that during the time it took to produce the language and API enhancements in Java 7 the Scala folks made *far* more substantial enhancements. There really is no comparison. The JVM enhancements of course accrue to *all* JVM languages (although to some more than others — dynamic languages in particular benefited greatly from Java 7′s invokedynamic).

Personally, at this point I would be unlikely to work for any shop that still sees the Java *language* as the future. I would be concerned about them not being able to keep pace with their competition, for one thing, and I would just feel more comfortable working with what I consider more powerful tools and folks who know how to use them. From what I have seen recently, many companies are actually quite willing to have engineers program in Scala, if they have staff who know the language.

There will be lots of Java code around for a long time, but I don’t think it’s anywhere close to true that migration to other tools has yet to start. Those who really believe this may find themselves behind the curve at some point.

Yes, you can do that quite easily in Guice, even if Deep is a singleton. If Deep is itself created for every request, then you can inject normally. If Deep has a longer lifecycle than what’s being injected, you’d use a Provider.