The is a possibility an oppertunity to learn Java. I once tried to learn some Java, and found it very annoying and slow to get into. I suppose it's a useful skill to have and good on a CV, and they may have fixed the annoyances I suffered last time I tried to learn it.
Now I need a good Java for Perl users book...
Re:I've said it before, I'll say it again.
lachoy on 2006-02-21T03:30:33
In lieu of paying IntelliJ (which I'd do myself, but my employer did it for me), you can hook up with an open source project and actively contribute. Jetbrains offers a free license for open source authors which quite a few of the Jakarta and OpenSymphony folks (among others) seem to have taken advantage of.
Java is actually a pretty simple language. If you haven't done it before threading can be a little tricky, but 1.5 offers a number of useful abstractions to make it easier. It's learning the libraries that's the hard part -- not because they're difficult, just because it takes a while.
I learned from "Thinking in Java", which is verbose but not bad. If you've got OO stuff and Java's type system down, the introduction in Flannagan's "Java in a Nutshell" is terse but IMO excellent. Once you've got a bit under your belt pick up Bloch's "Effective Java". Then load up one of the better open source projects in IDEA and browse away. (There's no CPAN, but there's a ton of open source Java.)
Additionally, Sun has a heap of tutorials on their site that are at least decent. Be warned that a lot of other tutorials on the web have a heavy focus on applets and Swing programming which may be near-useless if you concentrate on server-side stuff.
Re:it's pretty straightforward
Dom2 on 2006-02-21T07:52:32
To my mind, part of the problem with learning Java's libraries is the fact that they're so massively over-engineered. And they seem to rewrite, trying to throw out the old versions quite frequently. Except that they can't, as they need to keep the old bits for backwards compatibility (e.g. Vector vs ArrayList?).Ok, I'll admit. I've been toying with Java since it first came out. I still don't understand I/O in the standard library, above
System.out.println(). It's a complete mess. But I can usually look up in a reference to see what's going on. But what really bugs me is the bizarre and opaque behaviour of things like UrlConnection, in which you have to write to a stream to set the body of a POST request. Sure, you might need to do that someday, but 99% of the time you just want to say "setContent()", like in HTTP::Request.The language itself is reasonably simple to learn, although because it's so simple, I find it to be far more difficult to express concepts in clearly, relative to Perl.
That said, there are some really nice bits of Open Source Java. My favourite example is Lucene, which you should consider any time you need to do searching.
-Dom
Re:it's pretty straightforward
lachoy on 2006-02-21T13:33:23
The IO approach is very un-Perlish, but it does eventually make sense and it enables some fairly nifty behavior. For instance, with the URLConnection you can assign a String, you just need to wrap it in a StringReader/InputStreamReader first. Klunky? Yes. But it also allows you to wrap it in a ZipInputStream to do automatic compression, or an EncryptedInputStream (sp?) to encrypt it.
That points out my major beef with the Java libraries: they don't make easy things easy. With the URLConnection, they should have a method to just set a string as content, then do the stuff I mentioned behind the scenes. Another instance: what's the primary thing someone wants to do with a zip file? Unpack it to a filesystem! Is there a method to do that? Of course not! So everyone winds up writing their own shortcuts and having to maintain them, package them, depend on them, etc. (Many of the libraries in the Jakarta Commons are like this.)
Re:it's pretty straightforward
Dom2 on 2006-02-21T13:47:11
That's exactly the point I was trying to make. Java manages to miss out on making simple things easy by a large distance.-Dom
Re:it's pretty straightforward
ajt on 2006-02-21T19:50:00
Thanks for the suggestions.
Depending upon how things go I'll be doing SAP Java/ABAP work as part of SAP AG's NetWeaver technology. It's all horribly bespoke and notoriously slow and buggy, but it's where the money is...
Re:I'd kill for a perl to java dictionary
lachoy on 2006-02-21T14:13:52
That's part of thinking in a language. It took me a while to stop using Maps everywhere
:-) Regarding the dispatch table: one standard practice is to use a Map and make the values implement a particular interface, like 'Executable'. Then you can do something like this:
String dispatchKey = getDispatchKey(...);
if ( dispatchTable.containsKey( dispatchKey ) ) {
Executable dispatched =
(Executable)dispatchTable.get( dispatchKey );
dispatched.execute();
}
else {
throw new IllegalArgumentException( "Cannot dispatch " + dispatchKey );
}With the generics in 1.5 you don't need to do the cast, which is handy.
