views:

356

answers:

7

I've been doing web application development for the last 3 years in PHP. I'm now on the verge to give Java a go. My last use of the language was nearly 8 years ago and was mostly academic.

I'm reasonably well acquainted with PHP's object model (version 5) and I have almost exclusively been coding in OO. I would now like to transport that experience and use it to develop in Java.

Where I'm coming from:

  • linux as a desktop and server
  • Vim/gVim + plugins as an editor
  • MySql for db
  • apache httpd
  • experience with a bunch of PHP frameworks, Zend+Doctrine being the ones I use most

What I've garnered so far about a move to Java:

  • I need an IDE: IntellijIDEA, NetBeans or Eclipse
  • I need to pick a development framework. Some recurrent names: Spring MVC, stripes, wicket.

Now I need some insight that could help make this transition smoother. But from the way people talk about it, Java seems to be an entirely new beast with its own ecosystem. It sounds as though moving to Ruby or Python would actually be easier, which is curious since, when I look at it, Java conceptually seems the closest to PHP, albeit stricter and precompiled.

As weird as this may sound, very few people have publicly documented their experience of such moves. I have searched google, amazon and stackoverflow for similar questions and the results leave to desire. I just can't believe that I would need to start the same as a newbie if I wanted to be productive as a web developer in Java fast.

Anybody is welcome to respond, but I somewhat think that people with some valuable experience in both languages would enrich this discussion the most.

  • What helped you get going quickly in Java?
  • What concepts are omnipresent in Java and absent from PHP and vice versa?
  • Some gotchas for PHP developers going Java.
  • How long before you felt the transition was complete?
+4  A: 

Start with the Java Tutorial

http://java.sun.com/docs/books/tutorial/getStarted/index.html

Then go buy Head First Java

http://oreilly.com/catalog/9780596004651

It will get you going pretty quickly in the language which is essential regardless of what you want to do.

Thorbjørn Ravn Andersen
A: 

Best advice would be to stay away from Java.

12345
But he is moving away from PHP.
stesch
Do you have any arguments that confirms your opinion ?
Michael B.
real programmers do it in Assembly!
Woot4Moo
There are a few things wrong with this post. Firstly, no reasons are given why to stay away from Java. Secondly, it is not answering to the question, as the question is about transition to Java, not or Java is a smart idea.
Peter Smit
At least provide some reasons why you think Java should be avoided.
jckdnk111
Not the best answer, but in the end he might be right.
rick
@Rick, depends on what he wants to do, and where.
Thorbjørn Ravn Andersen
@Thorbjørn, yes of course, but do you have experience in web app development with a dynamic language? It really is eye opening.
rick
rick, yes. Fast in the beginning. When you reach critical mass code-wise your application will be brittle to change, i.e. mainteinance will be risky.
Thorbjørn Ravn Andersen
@Thorbjørn Depends on on the architect.
zaf
@zaf, here the OP is his own architect....
Thorbjørn Ravn Andersen
+1  A: 

I recommend hitting up JavaBat at here

It will give you some good ideas. It took me 1 solid year in a professional setting to get a very firm grasp on Java and I have been able to move into other OO languages quite easily once I had the thoughts beaten into me.

Woot4Moo
+3  A: 

Strictly speaking, you don't need an IDE to work in Java. I've been coding heavily in Java for well over a decade (and heavily on other stuff for over 25 years), and I don't much like IDEs. Perhaps that implicit indicator of my age is part of the issue :-) It's a trade-off, like anything else.

I'll plug Stripes as a nice simple framework, but mostly that's because it's relatively small and limited in scope. The large frameworks like Spring are "kitchen sink" ecosystems, and learning Java with one of those frameworks may smooth some of the difficult parts but leave other basic aspects mysterious. Again, it's a matter of personal preference.

It's good to have somebody around who knows the language. Oh, and to that point, make a friend of the Java API documentation. As platforms go, the Java API has its ups and downs but for the most part the documentation is at least pretty thorough and pretty accurate.

You'll also want to get really familiar with JSP and its relationship to Java and Java web service architectures, because that'll be what you'll relate to your PHP experience most directly (I'd think).

Pointy
Not using an IDE knowing about the language you are programming in, is wasting your own and your employers time.
Thorbjørn Ravn Andersen
That is a matter of opinion. I'm happy for you if you find an IDE to be an aid to your productivity.
Pointy
+1  A: 

The best move I made was from Java to PHP.

Beware of complexity. Primarily, the key to great software is simplicity, and that is why PHP combined with a good framework kills Java.

With Java, you risk becoming a slave to your servlet container and framework. Choose the simplest most flexible framework. Controls and custom tags are the devil. You'll waste days learning things that were designed to make development quicker, but are ultimately too complex and inflexible. Java will slow development due to: complexity, compilation, and static types. You'll come to loathe null pointer exceptions.

Edit: Tools aside, Java and PHP are very similarly structured "C" style languages. Much more so than Python or Ruby. It is the static typing and complex tools that make Java so foreign.

rick
*Chacun à son goût* of course, but much of what you describe as being reasons to flee Java are, to me, great strengths and "power tools." But I do agree that framework choice is very important, and that's a hard thing to advise because it's so subjective.
Pointy
Static typing is _the_ quality that makes it possible to build cathedrals in Java. In my opinion.
Thorbjørn Ravn Andersen
@rick, this doesn't really answer the question...
Pool
Sure, my answer is laced with personal opinion, but I did answer the most important point IMO: gotchas. Choosing the simplest framework is the point I wanted to make. The question would require an essay to answer completely.
rick
As for static vs dynamic typing, well that is a fun debate. Douglas Crockford (whom I idolize) now prefers dynamic typing over static. He makes the point that compile-time errors are usually obvious. Run-time errors are responsible for most bugs and compilation does nothing for those. So the flexibility and development speed of dynamic outweigh the disadvantages. I'd add that web applications are compelling for dynamic since they always deal with string inputs/outputs. It seems to me, that large backend applications where data is passed around a lot would benefit from static types.
rick
@rick, I think you should try doing some programming in Haskell, just to see what types _can_ do for you.
Thorbjørn Ravn Andersen
+1  A: 

Have you seen quercus (http://www.caucho.com/resin-3.0/quercus/)? It might be a good way for you to ease into the Java world without getting overwhelmed.

jckdnk111
Do you have practical experience with it?
Thorbjørn Ravn Andersen
+5  A: 

I wouldn't try to learn an IDE at the same time as learning a language. An easier transition would be to stick to your shell and habitual text editor, and use the following shell-friendly tools:

  • ant, for organising your project, running automated test suites, incremental compiles
  • BeanShell for interactive testing, trying things out quickly
  • A quick trick: javap from the commandline will give method signatures for any class in the standard library. Similar to php -r but gives more information since Java is typed.

The online documentation for Java is precise, professional, and consistent in tone and format. Unlike in PHP where all of the functions are in one flat namespace, the standard libraries in Java are class hierarchies. You've got to know your way around that standard library, which means knowing hierarchies + responsibilities: for example you've got to know that java.util.List is a subinterface of java.util.Collection with the addition of a concept of ordered entries. With that information in your head, a google search for java.util.List will take you to the Javadoc for the class, and the Javadoc will tell you exact method signatures and link you to a selection of concrete implementations.

Some miscellaneous distinctions:

  • Strings are sequences of characters rather than sequences of bytes. Absolutely the right way of doing it.
  • Systems produce and consume streams (of bytes or characters) rather than byte buffers. For example, if you wanted to filter the output in PHP, a standard practice is to ask ob_get_contents for a byte buffer then to transform the whole buffer. In Java, you add a filter to your servlet that transforms the output a byte or a character at a time. It's a bit imposing to work with initially but it's simpler and more Lego-like when you get used to it - your stream processor doesn't have to know where things come from and where they go.
  • Almost everything useful is an interface, and creating an instance of an interface can be tricky, non-standardised, and not always well-documented. In PHP, you can get up and running with XML with new DOMDocument(). In Java, org.w3c.dom.Document is an interface, so new() won't work. Javadoc is very precise about how interface instances behave once they come into existence, but it can be quite coy and prudish when you're trying to find out how an object is actually born. Very often, you'll have to look for tutorials and code examples and copy-paste a piece of boilerplate that gives you an instance of DOMDocument or java.sql.Connection or whatever. One reason frameworks like Spring are popular is that they separate out the ugly object-creation code and present you with a world where interface implementations are just magically there.

I actually switched in the opposite direction. I found that Java works very well in a large company where you might be working on a single component, handing it off to someone else who integrates that component into a larger system, which is then packaged and handed off to a separate operations team - that's where all this indirection and configurability (FactoryBuilderFactory type abstractions, web.xml files, etc) makes sense and does something useful. In a small company where the programmers are the ops personnel, Java is a lot more work. With Java, you'll have to get used to concepts like starting up the Java process, monitoring the Java process to make sure it stays up, monitoring the Java process to make sure that it doesn't go into a coma where it's alive but not responding, shutting down and restarting the Java process with minimal disruption when you're updating code, etc, etc. If you have separate ops personnel, that's fine, it's their job, they're very good at it. If you're a programmer, babysitting a Java process can be distracting and difficult to do well.

d__
The java char is too small. 16-bits is insufficient for Unicode. Additionally there is this new "Code Point" thing which apparently is needed for doing it properly. In other words - String is not enough.
Thorbjørn Ravn Andersen
Yes, good point. Strictly, Java strings aren't sequences of characters, they're sequences of, what is it... UTF16 code units? Java programmers are stuck with character model from 1995, when 16 bits were thought sufficient. It's still better for productivity and data integrity than the 1965 character model PHP programmers currently work with. I haven't yet investigated the PHP6 character model, which is reported to be more Unicode-compatible.
d__