score:26

Accepted answer

You should take a lazy approach to learning Java. Learn it when you need it.

In my opinion, much of the old Java knowledge is out of date, much of the new tutorials are redundant. You certainly don't want to bother yourself with Java's antiquated Collections, for example. Many Java-based frameworks can be safely ignored. And the heavyweight JavaEE stack can be safely bypassed until you were forced to use a part of it.

Many common patterns in Java are much simpler in Scala, with the former being burdened with much boilerplate code. Core logic should always be implemented in Scala. I believe you can do most of your work directly in Scala and only need to dip down into Java when building things like Swing or integrating with Spring, etc.

In regard to choosing and using Java libraries, my personal guidelines are:

  1. If Spring can do it, use Spring
  2. If Spring is too heavyweight, use what Spring uses.
  3. If Spring can't do it, check github projects
  4. If there's nothing on github, check Apache projects
  5. If there's nothing from Apache, check sourceforge(t).
  6. Finally, Google randomly or just build it yourself.

That's a bit tounge-in-cheek, but is the impression I get about the maturity and stability of third party libraries after having done Java for the last 12 years.

score:8

It depends entirely on your definition of "Competent Java Programmer".

A good understanding of the Java memory model and garbage collection strategies will help. As will experience with a wide range of 3rd part libraries.

On the other hand... if you're deeply indoctrinated into getter/setter dependency injection used by libraries like Spring, then you'll have to unlearn a lot of bad habits before you can properly deal with immutability - In this case, prior Java exposure is probably going to hinder you in learning Scala.

score:8

There are lots of folk coming to scala and clojure from ruby/python, lisp/scheme, C#, who need to pick up on:

primitives, autoboxing

JVM startup options, how hotspot works, 32 vs. 64 bit, use openJDK?

benchmarks, profiling, how to read stacktraces;

zillions of test libs for every conceivable need.

java.util.concurrent

Swing API calls; Classpath; Maven, ant; Hudson, Interfaces

namespaces/packages/directory layout, and all the other things automated by:

intelliJ, netBean, or eclipse

http://news.ycombinator.com/item?id=1508609

http://www.mired.org/home/mwm/papers/simple-clojure.html

+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:, EscapeAnalysis etc. http://groups.google.com/group/clojure/browse_frm/thread/c8f69037b26e2856#

compressed oops, http://blog.juma.me.uk/2009/10/26/new-jvm-options-and-scala-iteration-performance/

http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html

http://groups.google.com/group/jvm-languages/topics

Java for Clojure users

Learning Clojure - What should I know about Java and more

http://copperthoughts.com/p/clojurists-guide-to-java/

score:13

If you want to learn Spanish, start to learning Spanish, not Latin. Same for programming languages. There are two things from Java that are good to know:

The first thing are APIs. But you need only a general overview about what exists. Even long time Java programmers don't know all the details. And finding the right API or lib for a problem is usually easy, as Java is so common, and even with weak Google Fu you shouldn't have any problems.

The second thing you need to know are some basic principles and limitations of Java and the JVM (including how to build and run), that help you to understand some of Scala's problems and design decisions. One typical example would be "type erasure": If you don't understand this limitation of Java's generics, you'll run in problems when using generics in Scala.

As you can see, the things you really need to know is limited. Everything else can be picked up on the way.


Related Query

More Query from same tag