Slashdot Mirror
Java, Where To Start?
I'm a web developer who has design and programming experience. So, VB, ASP, PHP, Coldfusion, Perl, even C and C++ I have in my belt. I also use Dreamweaver and/or do a lot of my HTML/XHTML/JavaScript coding by hand. So, the DOM, DHTML, etc, all good to me and even OOP thinking and design I have when I code. And I even have MySQL and other databases, again, not an issue here. So, my weak point is — Java — I see so many jobs out there with J2EE, Hibernate, Eclipse, Netbeans. Beside the obvious, which is to learn Java the core language, I don't know where else to go from there. There is so much! What should I read? in what order? What software do I require? UML? Swing? I mean, what is the curriculum required for someone to say they are a solid Java developer? Even assuming I have to go through Java itself, what are the good books out there?
Everyone and his dog does Java these days. Including 100.000 guys in India.
Be smart and find something new, cool and on the rise.
TCAP-Abort
I'm continually surprised by the number of shitty jvm-version-dependent apps that people get paid to crank out. Don't be that guy.
Isn't it better to specialise in a few of the varied languages and systems you have worked on, rather than trying to spread yourself thin?
There is truth in the saying 'jack of all trades - master of none'.
So, maybe concentrate on building up the other skills, rather than trying to 'bag' a new technology. I used to try to gain exposure to loads of different technologies but found that when you do so you do at the expense of the 'depth' of knowledge you have in any one.
... then learning Java, EJB, etc. ... it should be a walk in the park. You shouldn't even need a book. Just go get the specifications from the Sun site and read them.
Seriously, Java is orders of magnitude more simple than C++. (That's a pro and a con.)
If you want a Java job, just update your resume to say that you know Java. I have met lots of J2EE experts at work, who would not be able to code a "Hello World" program, if their jobs depended on it. Also learn lots of buzz words.
If you want to learn Java for knowledge, join a community college, install Eclipse and get started.
Java is a good language to learn for the current marketplace.
The real problem thats putting people at risk of outsourcing is not the choice of language.
Its all about your skill as a programmer. If you're average, then there are plenty of average coders willing to work for less in India.
No, you've got to be better then average, great even, and that takes a lot of work.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
Please, for the love of God, forget the frameworks. They come and go pretty quickly and each one is usually over-hyped to begin with.
Learn to be a great Java programmer. That means knowing the standard library in and out. Develop really good OO modeling skills. Learn what it means to write robust code. Understand and use exceptions effectively instead of littering blank catch blocks everywhere. All of these skills will serve you far better than knowing what arguments the RegistrarClassFactoryStubGeneratorJarBridge uses in its create() method. From there, as needs come up, you can experiment with higher-level abstractions. But please do NOT become one of those people that 'learns' that all database access should be handled through *insert-ridiculously-overcomplicated-framework-with-50-config-files-that-must-be-in-special-places.*
Aside: the reason Rails became so popular is because it managed to 'just work' without all of this inane configuration and magic files. The Java community is practically in love with complexity, since it is very enterprise-y.
The key is the libraries: that's where it goes from being merely another OO language to being able to do something useful. I'd start by getting a simple "hello world" program running, then thinking up a home project which allows you to start adding features and functions.
Most of the documentation I've seen is pretty poor - it gives argument lists and describes functionality in isolation, but misses out the higher level WHY you would want to use a function. Learning that is where the gold is.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Java's an entire ecosystem unto itself these days. So there's no simple answer - you have to figure out what kind of apps you want to be involved in building, then that will inform your choice of Java based technologies. For the most part I do enterprise web site development, and that mostly on the server-side, so I'm a Java EE/Hibernate/Spring/Eclipse person. Plenty of professional experienced Java developers will never use any of those technologies!
Once you've figured out what kind of apps you want to be building, I'd suggest visiting the Sun Forums if you have any technical question and then poking around the Java.net site, theserverside.org, JavaRanch and the java usenet newsgroups to get a better feel for what's out there and how it's rated by developers. Feel free to drop me an email if you have any questions that you want to ask offline.
Ignore the naysayers - for the most part they don't know what they're talking about. Sure you should have other languages under your belt, sure there's offshore competition, but still, Java experts are in demand and they will be for a long time yet.
--- These are not words: wierd, genious, rediculous
If you are a serious programmer and want to solve real business problems, concentrate on what Java does well - glue things together and use well thought out class structures to map onto the things you want to do.
In my admittedly limited experience over only 25 years or so, if you leverage the strengths of Java you can do things you can do in other languages about as fast, with good reliability, good debugging, good code re-usage and rare platform incompatibilities.
Oh, and get used to Derby (formerly Cloudscape), because you can then have your SQL database all bound up in your 100% Java application and still talk to spreadsheets etc. as easily as if you were using Access.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
It's a difficult industry to get into as you're probably aware. Recruiting for Java posts is a minefield - it's full of people who should be stacking shelves in a supermarket.
I don't think you can go far wrong if you get as much experience in core Java as possible. The same goes for J2EE; if you understand what it is and know the trials and tribulations of building a web-app from scratch, you're on the right track. Then, and only then, should you move onto working with frameworks; so build applications both stand-alone and web, and do the boring stuff yourself (i.e., write your own web.xml.)
Spring and Hibernate are funny ones. Spring's just an IoC framework. Until you're proficient in OO design, you probably shouldn't worry about it. Oh, and learn what IoC is first. Don't just think 'spring' and say you know it. Very few people know why they chose spring as a framework (there are plenty of IoC containers out there).
Hibernate (an ORM solution) is a dark art. Get the basics done first. Write JDBC DAOs yourself and learn why you'd need ORM before you dive into it.
Basically, learn the core concepts.
ilovegeorgebush
O'Reillys "Head First Java" is IMHO the best technical resource / learning tool I've ever used; it's honestly fun to read. You can read it online for 30 days free using the Safari service.
A favorite excerpt of mine (on how to remember the single-inheritance, multiple-interface concept):
Roses are red,
Violets are blue,
Extend only one,
But implement two!"
Honestly, all of these acronyms you can list, and yet you don't have the initiative to learn another language without posting silly questions like this?
It's not about "learning a new language". Learning Java is trivial. The problem is the hundreds of bloated, redundant, incompatible "frameworks" and "libraries" that exist for Java. Which one to learn is a valid question (albeit, it doesn't have a good answer).
We do Enterprise web development for a major University and leverage Java as our core language. We use a combination of software including Java, Hibernate, and Stripes to manage student information for tens of thousands of students. We have found this to be an excellent combination.
Recently, I have been experimenting with upgrading our platform by using Groovy for unit testing and batch jobs. Groovy is basically dynamic Java. It is 99% compatible with Java so essentially you can drop in you Java code and it will run except on a few edge cases. This is because Groovy compiles down to the same bytecode that a similar Java class does. You can't tell the difference except the smile on your face as your coding is reduces by approximately a 6:1 ratio.
Groovy incorporates some of the cool features that other 'dynamic' languages such as Ruby and Python have been rubbing in us Java guys noses for quite awhile such as closures, operator overloading, and autoboxing. A good book on Groovy is by Scott Davis' called "Groovy Recipes" (ISBN 10 0-9787392-9-9). Groovy is the ticket to moving Java into the 21st century.
If you are feeling adventurous and are starting a project from scratch, I suggest another web framework called Grails. This convention based framework and development environment uses the Groovy language and leverages popular and solid frameworks available such as Hibernate and Spring. A good book on Grails is "Beginning Groovy and Grails: From Novice to Professional" (ISBN: 978-1-4302-1045-0).
Dynamic Java is here folks and it runs on the JVM which is where things seem to be heading (JRuby, Jython,..). Why use a language that must be transformed to use the JVM? Instead use a language that the JVM was designed for!
Seriously, is there some shortage on Java dicumentation out there or something? Granted, I don't know the language as I never had a need for it, but I can't trip over without falling into a pile of Java tutorials.
That is precisely the point of the question. You could quite easily spend 6 months solidly reading the stuff out there, so what OP is looking for is a recommendation or two to save him spending months finding the stuff that's worth reading in the piles of dross. I'm hoping there are some good answers, because I to would quite like to get a handle on the more enterprisey side of Java.
It is only there to start the JAVA vs xxxx holy wars that bring in the advertizing revenue as everybody and their brother/sister chime in, again, and again, and again......
Undetectable Steganography? Yep, there's an app fo
I second that recommendation.
However, I'd suggest you go pretty light on actually reading the books. Just get in there and build something.
Sure, you can use the books as references. I'd get O'Reilly's "Java in a Nutshell" reference, and also one or two of their Java cookbooks, so you can look at some reasonably clean example code.
But you should mainly pick a number of small projects and build them. Java is a mature platform with a lot of history and extensions for all sorts of circumstances. That can be interesting, but you'll need very little of that for a working knowledge. As you build things you'll discover which areas you really need to know more about.
I never really liked NetBeans, I tried it with ver 5 and decided to stick with IntelliJ and Eclipse.
This is one of the examples that us Java foreigners want to learn. Here are some Java buzzwords that you see in jobs asking for devs:
Netbeans
J2EE
Eclipse
Jakarta
Struts
MVC (which isn't a java-only concept, but then again, newbies don't know)
Websphere
I really wish there would be an "intro to java technologies" book that explained newbies like me, with diagrams and colored figures what the heck is each buzzword and what it means, but I don't just mean a dictionary paragraph.
See, anyone could spend a couple of days googling each buzzword, but then there's the problem that one could learn TOO MUCH and get TOO DEEP trying to undersand ONE OF MANY things in java. And then you can find out that what you learned won't get you anywhere because suddenly the technology you learned became obsolete.
Around 8 years ago, I tried to learn java and JSP, and then found out that everyone switched to J2EE. Then I tried to learn J2EE and completely got lost. Then I tried to look at some J2EE courses sponsored by IBM but they costed at least $600. Then I said "fuck it, I'll stick to PHP. I can install an Apache webserver in one click on my Windows compy and I'll learn PHP on my own - for free". Try that with Java. See, the problem isn't the language itself, but the bunch of stuff built on Java, the frameworks built on java, AND the popular apps built upon some of the java frameworks, which is actually what the companies expect you to know.
What we need is a broadth-first approach of learning, starting with the language (one chapter for the java basics and examples should be enough). I mean explaining only the basics of each, comparing different technologies, telling you where they fit in a web app, and which ones are recommended or not, and why.
try to learn hibernate, which will be the last time you think about databases.
LOL there is no other API where you think more about databases than Hibernate. The simplicity is deceptive.
As a Java developer for nigh on ten years now, and someone who painfully learned how to program database connections by hand, then use orms like Hibernate, I might caution against Struts (though the rest of your order-of-learning is excellent). Struts was definitely in my path of learning, but I am not sure what it offers these days that isn't done more comprehensively - and to my mind, more cleanly - with Spring.
Of course, there are a lot of legacy systems these days built on Struts - for good reason. So if you're looking to work on older code, it's not a bad thing. But if you're planning a career with stuff that is from scratch, I think that Spring forces one to code in a better manner than nearly any other framework out there.
It may be, of course, that I'm just in love with inversion of control - which I think is one of those things that, if you understand it, gives you a much better command of abstracted design.
One other thing I think is pretty cool is JavaBLACKbelt, which has a pretty good, community developed set of quizzes that are useful for gauging your own command of the language.
[Ego]out
Considering that Java has been (probably) the most used language for a while, you get a lot of crap. So, here's my "crap filter" list of what you should learn to really hop into the JVM ecosystem.
Books:
1. Effective Java, 2nd edition, by Josh Bloch
This covers most of the twists and turns of the basics that an experienced programmer would need. I wouldn't worry about getting a simpler book.
2. Java Concurrency in Practice
Understanding the JVM model of concurrency is important, and this is the only guide that had a pretty in-depth look into the subject. The Sun documentation absolutely sucks at covering concurrency.
APIs
1. Guice http://code.google.com/p/google-guice/
Dependency injection is the most recent thing that makes Java a very powerful language for building large appications. And Guice is by far the best implementation of DI. (Yeah, you could learn Spring, but I just don't care for it.)
2. Hibernate http://hibernate.org/
I hate Hibernate. But it basically set the standard for EJB3. If you know Hibernate, it's not a very hard road to learn all the other "enterprise" crap.
On the other hand, any substantial server-based solution probably uses a ORM solution like Hibernate.
3. Apache's Commons http://commons.apache.org/ and Jakarta http://jakarta.apache.org/
There is a ton of projects under the Jakarta umbrella these days. The first one to try out is the commons-lang libraries, which provide very easy to use toString. equals, and hashCode implementations that are 'good enough' 99% of the time. Why do you need those? Read Effective Java. :)
Interesting stuff:
1. Hadoop http://hadoop.apache.org/
Hadoop is an open-source implementation of Google's MapReduce idea.
2. Scala http://scala-lang.org/
Scala is my favorite "non-Java" JVM language by far. For me, the scala interpreter is how I learn APIs. In fact, most of my new code is in Scala, not Java.
3. Groovy, JRuby
Just some more used non-Java JVM languages. I've used JRuby a bit, but have moved on to Scala. It's still a significant project, however.
4. Web application frameworks: Wicket http://wicket.apache.org/ + Databinder http://databinder.net/
Wicket is the simplest page-based Web framework I've ever used. I just find it easier to navigate than Rails. If you really want an ORM-based solution, go for the Databinder extensions. Databinder will get you coding in a couple of minutes.
5. Restlet http://restlet.org/
We have several different clusters, and a bunch of machines that need to transfer data around. I learned how to set up a restlet server that was integrated with Guice in a couple of hours, and now, have a very easy means to script together many different servers.
I've had the misfortune of purchasing a few Worx titles, and they are indeed incoherent, gigantic and largely useless. I've generally had good experiences with O'Reilly books, however.
But the most useful has really just been google. Finding interesting examples and work through stuff, as most books on modern Web technology tends to be rather out of date by the time it hits the bookstore.
I don't know, but it works for me.
Try Wikipedia, it has articles on each of the things you list and lots more. Unlike projects' individual sites, it tends to start by telling you what each actually does. Most of them are hardly earth-shattering, it's just that Java developers seem to like assigning a silly acronym or coffee related name to every equivalent to a CPAN module.
There is a difference between computer science and writing business logic.
Yes you are wrong.
.Net and nothing else, you know. It's not that it can't be done in e.g. Perl, but its so much *easier* in Java.
When we talk about Java we mean JavaEE, not standard application programming. Sure Java is no better than most other languages when it comes to building small to medium desktop apps/clients. But once you go past a certain point in size/complexity Java is your friend. Perl and php are not. JavaEE is meant to be used for large (really large), complex, distributed, high-availability business systems. And it's damn good at it.
There is a reason most systems of this type are built in either Java or
Basically assuming the environment (ie plugin host) is nicely written the all the boring nut and bolt stuff should be taken care of, if you can find a well supported java application that uses plugins go for it!
That means you can have "fun" while you learn which is the quickest and best way to learn
I'd highly recommend the java "trail" tutorials, and once you get you're head round the API the api docs are extensive, more than learning a language (which is just really a C type sub set) you are learning the JVM's environment.
Use a text editor for writing code and dont rely on multiple guess itelli"sense" type IDE's
Enjoy!
there are thousands of windows applications that don't work on Linux - thankfully
jeez... Who modded you insightful? The Java platform today is an enormous pile of layers, frameworks, and standards. It's not just Java/EJB. Learning the entire JavaEE ecosystem is more than most people are capable of. And yes, I have worked with both C++ and the JavaEE stack.
Compared to some other languages, Java is pretty limited in what abstractions can be practically implemented,
Like what? Name anything and Java probably already has a library for it. Java is just as flexible as anything these days, and wether your thing in running Ruby on Rails on top of the VM with some Java through in the backend or some functional Groovy work Java has options.
That's a big advantage it has going for it, so many people have used it now there are a lot of resources and options for wherever you might want to go with it. Even if you decide to use other languages learning Java just to understand how to use it as a base is really worthwhile, and because of the platform neutral architecture and excellent community standards body (JCP) as a platform it will continue to thrive.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I thought destructors were the inverse of init (constructor) and C++ has operator delete as the inverse of alloc (operator new), the difference between a destructor and a finalizer being that you can't rely on a finalizer being called at a particular time, or even being called at all.