I remember attending a meet-up on this very topic within the past year. It was held at the offices of a small startup recently acquired by twitter. The presenter made the distinction between Java as the programming language and Java as the runtime environment (i.e. JVM).

In his opinion, Java the programming language was on its way out whereas Java the runtime environment was here to stay.

Why is that? The JVM reflects countless man hours of stability fixes, performance improvements, and scalability work. It's a real big investment that only mega corps with deep pockets can make.

In my experience, what I have found is that there is a certain breed of programmer who doesn't like Java the programming language. It seems to me that it is because Java is statically typed. This means you have to type out all these interface and class names with every method signature. It's a lot of typing. You add in all those getters and setters boilerplate and you find that you have a larger, some would say cumbersome, code base to maintain.

If you find that you resemble that description, then check out Clojure which is a version of lisp that compiles to Java byte code running in the JVM. It can, but doesn't have to, be pre-compiled and it is dynamically typed. You can provide type hints but you don't have to. For this reason, Clojure programs are much more dense than Java programs. Less typing in order to get the job done.

Be careful what you ask for. All that typing means that you can find and fix a lot of bugs in the compile step. With dynamically typed languages, you get to find those bugs at runtime. Maybe that is why other posters here believe that Java is for the B programmers.

As someone who has worked http://www.dynamicalsoftware.c... on such systems in the past, I concur. Graphical programming languages are not used by serious engineers. It is easier to express a complex algorithm textually than by any manner of drag-and-drop manipulation of icons. My take on the OP's attitude is this. Programming is too hard. It should be easier. The OP is obviously not a good programmer because, if they were, then they would realize that what is hard about programming is not the mouse vs the keyboard. Rather, it is the abstract cognitive ability to analyze a problem into smaller, more manageable parts then synthesize a solution up from those parts into a system that is accurate, reliable, consistent, and performant. I first heard this programming is too hard sentiment in the 90s. Frankly, I can't help but label this as just another sense of entitlement by a generation who has not had to suffer from anything other than the existential angst of their own mediocrity. Hard words, I know, but there you have it.

I remember when facebook got big enough that I finally decided to create an account there. Not because I wanted to share private details of my life with my friends. Because the FB audience was big enough that I felt compelled to have some representation there. What my timeline displays is what I call a public profile. Think of it as the linked in for hobbies and vacation travel. Don't publish anything that wouldn't hold up in a criminal investigation. I'm not saying lie. Remember Andy Warhol's now famous "15 minutes of fame" quote? Well, famous people need a PR manager. In today's "15 minutes of fame" world, everyone needs their own DIY PR manager. Think like a PR manager before you post.

Where I work, they pay for every engineer to attend a conference of their own choosing. This year, I am going to the Cassandra summit in San Francisco. Last year, I went to the Lucene Revolution conference in Boston. The year before that, I attended Velocity. Zoosk is still a start up but has been around for six years. They run R&D projects about twice a year for new hires and conduct a hack days competion every year. They have one project where six engineers are working with new technology to reinvent their whole stack.

That coincides with my observations as well. Here are some more observations. The developer spends most of her time coding whereas the engineer will be involved in all aspects/phases of the software development process including; requirements capture, analysis, design, configuration and release planning. The developer tends to favor one programming language which he treats as a "swiss army knife" in that he will create a lot of code getting that language to do everything. The engineer usually knows lots of programming languages and his approach on language selection is more like picking "the right tool for the job."

Don't get me wrong. I'm a big advocate for mind maps. See http://ploneglenn.blogspot.com/2010/10/mind-mapping-in-modern-age.html for a list of map mapping software that I have used over the years. I just don't see why you would use a mind map as a replacement for UML. Outside of them bothing being a type of diagram, I don't see much similariity or purpose. You use UML to model object oriented systems. Mind maps are a diagrammatic way to organize just about any cognitive activity. Using a mind map as a replacement for UML would be like attempting to drive to the super market with a pencil. http://stackoverflow.com/questions/423218/best-tool-to-create-architecture-diagrams-for-software/423288#423288 is what I recommend for diagramming in UML.

People here seem to think that you are looking for another email client. Instead, it appears to me that what you really need is a way to archive and search your local machine. In light of that, take a look at http://beagle-project.org/ Beagle can search your IMAP stuff and local file system stuff too. I run Ubuntu so the UX for installing, configuring, indexing, and searching with Beagle is pretty easy. Beagle is available in the Ubuntu Software Center. You can search from either the command line or from the firefox search bar once you have configured that.

J2EE folks should definitely check out JDO as a better way to develop for the cloud. With JDO, you can stay relational or move to EC2 or GAE without making a big code commitment.

Infinite scalability isn't the only snake oil in the cloud. Other cloud computing myths include "all you need is a credit card" and "cloud is cheaper."

It's no longer language constructs, data structures, or algorithms that are cutting edge. Innovation has moved on to more fertile pastures. Yes, those who build software tools, libraries, IDEs, and compilers will continue to innovate. They have and will continue to come up with some brilliant stuff. But cutting edge developers don't pick a shop because they write in groovy or whatever the language-de-jeur is. Cutting edge developers go where they believe the next killer app is going to be born.

The best developers are multi-lingual. They don't identify with a single programming language. They're not VB developers or Java developers or even Rails developers. They can pick up any language/library/environment quickly. They don't really get off on curly braces versus colons. What feeds the best developers is the challenge of world domination through innovation.

Change the world, right?

IANAL but my guess here is if the attack is coming from the IP of the server(s) where your app is running, then you could listed as a defendant. If you are sharing a server or have a VPS account, then you are still not patching the OS of that machine so it is vulnerable to getting infected and caught up in a bot-net. Even with dedicated machines, an incorrectly patched firewall or security appliance could leave your machines vulnerable.

Why should corporations care? Two words "litigation exposure." A bot-net living in your network takes down an e-commerce site for day. They will see you in court. Good luck with that "don't blame me, blame my ISP" defense.

I think that kind of "not my problem" thinking is what is driving the current cloud computing craze. Corporations seem to think that they can side step the accountability hassle if they outsource IT to the cloud. Good luck with that too.

Database, web, frameworks, IDE are all important if you want to get into J2EE. I recently gave a presentation at the local JUG about GWT which is Google's toolkit for writing RIA in J2EE. About half of the talk was an introduction to GWT and the other half covered GWT specific issues with regards to Eclipse, Maven, Spring, JDO, Hibernate, GAE, EC2, Acegi, Lucene, FreeMarker, etc. The point is that there are a lot of OSS Java libraries out there that rapidly accelerate your productivity in Java development and it is important to learn how to consume some of these APIs if you want to be competitive.