It depends what you want.

A) If you want to make more money or look for career change, then you have to listen to market and learn whatever it needs or pays well.

B) If your goal is to do long term career investment, then keep learning Java and make yourself an expert of it. To become "expert", you inevitably will have to learn a lot things that are beyond Java language and platform. Later on, these knowledge can be easily reused in other languages.

A) is short term, B) is long term. How about allocate 50% of your learning to each of them, then adjust allocation when you feel you need to?

Instead of book, how about look at source code of some open source projects?

Each language has been created in different context, trying to solve problem by using different approach.

Sure, they all need basic IF-ELSE, WHILE... But it is really helpful not to focus on too detail of technical side at the beginning. At high level, understand why author needs to create this language? Why the author did not select existing solutions at that time? This kind of "culture" background will help you understand language much deeper and avoid a lot of confusions.

I hope this will help.

I will not use it.

If I need truth about something, I will do research to find out. I do not need app and I do not trust an app for that.

Would you use an app that verifies your reasoning (for the occasions you are too busy to research the truth or not actively looking for it)?

* Situation like this is not only technical issue any more. Your solution needs to reflect that.

* This is not best situation to be in, but if you learn to deal with this and emerge from it. This experience will make you so much stronger. So be ready to quit, but do not quit too early.

Good luck!

(I replied earlier, but the above two points are so important that they worth a different post.)

Nothing wrong with checking account.

When you think about "return on capital", do not forget "return of capital".

* Rewrite.

* NEVER modify existing one. Once you change one line of comment, you own all the code and problem from that point.

* If rewrite is not allowed, then ask huge pay raise for this work. Basically it is not about money, it is about bring everyone on the same page on the status of he existing solution.

* If the above does not work out, prepare to switch to another project, or quit the job totally.

There is absolutely no way to rewrite a million lines of business logic without ending up with an even bigger mess. See also: http://www.joelonsoftware.com/articles/fog0000000069.html

I read that article before and totally agree with the point.

But that situation is different from the one we discuss here.

I do not know more information about ohmygord's project, but I basically want to point out to consider non-technical side of it. For example, people in the same team may not technical, and/or think maintaining existing solution is simple. I was in similar situation before, I was lucky to happen to select right strategy to deal with the situation.

Steve Jobs mentioned this.

For enterprise software, user and buyer are not the same person.

Learn -- Learn to know how existing things work.

Think -- Think independently. Think as outsider.

Apply -- Apply what you created by independent thinking to what you learn about existing things in the real world.

Repeat -- Repeat the above the above 3 steps.

Thanks! Amazon Payment looks good.