We Keep Coding

Issues when writing a medium/large system

There is some hype with languages like Python (that I like very much) and Ruby but I was writing a medium-size system in Python and feel the lack of some tools that I would have if I was using Java: Eclipse features, JUnit integration and some language-features like catching some errors in compile time.
Some people says that Java is dead as a language. But large important software are written in Java: Hadoop, Lucene and many others.
Is Java a better language than Python or Ruby for medium/large infrastructure software like these?

This kind of question can get very argumentative... For enterprise software most of time the key factor is political, not technical.
If you own the business, stick with the technology that best fits your vision. If not, use Java - it is politically safer.
On the technical field, it is almost a tie.

You make a valid point in saying that Java is more suited to enterprise software. That's really where Java shines: it works very well for enterprise programming.
However, your gripes about the tools in Python and Ruby are unfounded. PyDev for Eclipse takes full advantage of the same features that you would enjoy if you were developing in Java. Ruby has a similar plugin for Eclipse. Unit testing frameworks like pyunit, nose, and others exist for both languages (and I believe PyDev has support for unit tests). Also, just like a Java compiler would catch an error at compile time, a Python script will give syntax errors before you run it, along with an (IMO) much more understandable error system than a Java compiler.
Since Python and Ruby are scripting languages, their area of expertise lies more in small tasks, rapid development, and using frameworks like Django or Rails. So yes, more heavy-duty languages like Java are great for enterprise, but there's something to be said for the elegance and ease of use of Python and Ruby.

All much of a muchness really. There are features in Python/Ruby that your aware of that make them a more appealing offering than say Java. Static typing can be your best friend most of the time, and a pain for the other.
Lack of tooling is related to adoption. Java/c# has a larger adoption.
Corporates/Enterprises and medium to large organizations, like to procure solutions with contracts as opposed to technical merits.
From experience Python does have some speed issues, I can't comment on Ruby, but I imagine that if your applications require dedicated speed I would not use python.
Also threading and multi-core processing is not as good as it could be in python, although 2.7 seems to improve a lot of the old problems, I think the GIL problem still remains for threading.
My only comment on Java is that it now has Oracle behind it, and depending where your sitting and how you like Oracle, might change your attitude to Java. especially if your designing for Open Source solutions.

From PHP to Java. Any advice? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
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?

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.

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.

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).

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.

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.

This appears to be a bit of an old post, but hey...
I moved from C# to Java and I've just started a role and am moving from Java to PHP...
First off: Java is awesome :)
for your IDE get Eclipse, once you get used to it, you never have to leave the IDE (apart from SQL bits). It manages projects really well, you can download alsorts of plugins, such as SVN plugins. It allows you to run a Tomcat server within Eclipse and it will output errors straight to the Eclipse console.
for the framework, I used Struts and Tiles and Torque for the ORM, took me a while to get my head around them, but once we made friends, I can't imagine any other way of developing. Although I imagine for a small project it would be a lot of overhead!
agreed with an above post - get HEADFIRST JAVA, thats how I learnt and I used it for lots of other languages, they have a visual method of learning thats alot easier than pure textbooks - well for me anyway. I was up and running with in a day and confident within a couple of weeks I guess - but always learning :)
yip Java is strict, but you come to love it, for me moving to loose 'ol PHP is a bit wierd.
you will also need to download Tomcat to run your Java bits, its easy as to get running.
Java organises all your classes very nicely, none of this 'require_once(some_text_file.php)' rubbish, just 'import myClass' and off you go.
one of the things that annoys me is, there is no way of telling which JAR libraries you are NOT using, so after a couple of years working on a site, your lib folder can get a bit messy - specially if mulitple people are removing and adding functionality.
I could go on.
Paul

For my case, I only dealt with lot of procedural coding on the php, so jumping to Java, not only did I find everything to be more verbose and less forgiving than php (but now I know why it must be this way, and I love Java a lot) but learning to organizing my code in classes and also learning the eclipse IDE took about 1.5 years of just tinkering, trial & error, making stuff on my own (mainly swing applications).
I guess just creating stuff on your own, utilizing the vast amount of Java libraries out there to build your own stuff is fun is the fastest way. Also I think I could've saved more time by reading the java sun tutorials thoroughly. Even more time saving is making sure you've done a thorough search for libraries that prevent "reinventing the wheel".
Good luck!

Scala as the new Java?

I just started exploring Scala in my free time.
I have to say that so far I'm very impressed. Scala sits on top of the JVM, seamlessly integrates with existing Java code and has many features that Java doesn't.
Beyond learning a new language, what's the downside to switching over to Scala?

Well, the downside is that you have to be prepared for Scala to be a bit rough around the edges:
you'll get the odd cryptic Scala compiler internal error
the IDE support isn't quite as good as Java (neither is the debugging support)
there will be breaks to backwards compatibility in future releases (although these will be limited)
You also have to take some risk that Scala as a language will fizzle out.
That said, I don't think you'll look back! My experiences are positive overall; the IDE's are useable, you get used to what the cryptic compiler errors mean and, whilst your Scala codebase is small, a backwards-compatibility break is not a major hassle.
It's worth it for Option, the monad functionality of the collections, closures, the actors model, extractors, covariant types etc. It's an awesome language.
It's also of great personal benefit to be able to approach problems from a different angle, something that the above constructs allow and encourage.

Some of the downsides of Scala are not related at all to the relative youth of the language. After all, Scala, has about 5 years of age, and Java was very different 5 years into its own lifespan.
In particular, because Scala does not have the backing of an enterprise which considers it a strategic priority, the support resources for it are rather lacking. For example:
Lack of extensive tutorials
Inferior quality of the documentation
Non-existing localization of documentation
Native libraries (Scala uses Java or .NET libraries as base for their own)
Another important difference is due to how Sun saw Java and EPFL sees Scala. Sun saw Java as a product to get enterprise customers. EPFL sees Scala as a language intended to be a better language than existing ones, in some particular respects (OOxFunctional integration, and type system design, mostly).
As a consequence, where Sun made JVM glacially-stable, and Java fully backward compatible, with very slow deprecation and removal of features (actually, removal?), JAR files generated with one version of Scala won't work at all with other versions (a serious problem for third party libraries), and the language is constantly getting new features as well as actually removing deprecated ones, and so is Scala's library. The revision history for Scala 2.x, which I think is barely 3 years old, is impressive.
Finally, because of all of the above, third party support for Scala is incipient. But it's important to note, though, that JetBrains, which makes money out of selling the IntelliJ IDEA IDE, has supported Scala for quite some time, and keeps improving its support. That means, to me, that there is demand for third party support, and support is bound to increase.
I point to the book situation. One year ago there was no Scala book on the market. Right now there are two or three introductory Scala books on the market, about the same number of books should be out before the end of the year, and there is a book about a very important web framework based on Scala, Lift.
I bet we'll see a book about ESME not too far in the future, as well as books about Scala and concurrency. The publishing market has apparently reached the tipping point. Once that happens, enterprises will follow.

I was unshackled from the J2EE leash last year wanted to do something new after 12 years of Java in the enterprise building very large system for some of the worlds biggest companies.
I had tried Ruby on Rails in the past. After building a few sample apps I did not like the feel of it or the fact that I would have to write a ton of unit tests to cover stuff that is normally done by a compiler.
Groovy on Grails was my next port of call. I have to say I do like this but it suffers from the same dynamic typing problems as ROR. Don't get me wrong I am not putting Grails down as it is an excellent framework and I will still use it. Each has its own place IMO.
I then jumped on Scala and have now built a hybrid application based on Scala and Spring MVC. At first working with Scala is difficult but it gets easier and more productive the more time you put into it. I've reached a tipping point where I now want to invest time in Lift as well.
The combination of "Programming in Scala" and David Pollak's "Beginning Scala" books is good for learning the language, the latter with a less academic bent.
Scala is still young and has some way to go. I think it has a bright future and I see momentum is already picking up. Recently one of the creators of the Groovy language said in a blog post he would never have bothered designing Groovy if Scala had been around at the time.
I think some more work on better Java API integration/wrapping will give Scala the boost it needs to win more followers. The basic integration is there already but I think its could be polished a bit more.
Yes IDE support is there but it is basic at the moment. The powerfully refactoring support of Intellij is not there yet and I miss that a lot. The compiler + IDE support with a mix of of other plugins is not mature yet. I sometimes get very weird internal compiler errors caused by how Scala sits with JDO enhancement for the Goggle app engine. However these are little things that can be easily fixed. Early adaptation of new technologies and languages always comes with a little pain. But this bit of pain can produce great pleasure in the future.
If I look at the capabilities of Scala compared to early Java its miles ahead. When I moved from C++ to Java the JVM was not ready yet regarding scalability. There used to be lots of weird crash and burn JVM core dumps on various OSes. All of this has now been fixed in Java and the JVM is rock solid. Scals runs in the JVM so it has been given a massive head start on native platform integration. Its standing on the shoulders of giants!
After years of building and supporting enterprise applications my vote is for a language where a compiler can catch most of the non functional bugs before even unit tests are built. I love the type checking mixed with the power of functional programming. I like the fact that I am doing OO++.
I think the development community will decide if Scala is the future or not. The downside of adopting Scala now would be if it did not pick up momentum and adaptation. It would be very difficult to maintain an Scala code base with very few Scala developers around. However I watched Java come from the skunk works into the enterprise to replace C++ and it was all pushed from the bottom up by the developer community. Time will tell for Scala but currently it has my vote.

Beyond learning a new language, what's the downside to switching over
to Scala?
Thinking, thinking, thinking..... nope, there is none :-)

I'll tell you my little personal experience, and how I found that it wasn't so easy to integrate Scala with existing Java libraries:
I wanted to get started with something easy, and as I thought that Scala was very well suited for scientific computation I wanted to do a little wrapper around JAMA (Java Matrix library)... My initial approach was to extend the Matrix type with a Scala class and then overload the arithmetic operators and call the Java native methods, but:
The Matrix class doesn't provide a default constructor (without arguments)
The Scala class needs one primary constructor
I thought one good primary constructor could be the one accepting an Array[Array[Double]] (first thing that sucks, that syntax is much more verbose and hard to read than Double[][])
As far as I know by reading the manuals, the parameters of the primary constructor are also implicitly fields of the class, so I would end with one Array[Array[Double]] in the Scala subclass and another double[][] in the Java superclass, which is pretty redundant.
I think I could have used an empty primary constructor that initialized the superclass with some default values (for example, a [[0]]), or just make an adapter class that used the Jama.Matrix as a delegate, but if a language is supposed to be elegant and seamless integrated with another, that kind of things shouldn't happen.
Those are my two cents.

I don't think there are any downsides. Actually learning new language is very helpful for broadening your programming knowledge. You might gain from Scala such things as generic classes, variance annotations, upper and lower type bounds, inner classes and abstract types as object members, compound types, explicitly typed self references, views, and polymorphic methods.

It consistently breaks backwards compatibilty.
Community size is small.
IDE support isn't there yet.
Otherwise its fine.
It is just a young language, it will get there eventually.
Great for hobbyists, not ready for enterprise.

The two, by which I mean four, biggest downsides I'm seeing are:
Many working as developers in the professional community aren't trained and are unwilling to learn how to use a functional language, they won't even give it a go so they can understand why it's a better approach. This means you'll always be fighting an uphill battle getting adoption until it's mandated at the corporate level.
RDBMS integration is still a bit spotty. Plenty of solutions, but nothing that really sticks out as becoming a standard. For me though, this might be an advantage rather than a disadvantage. JPA2 is a mess and causes more issues than problems it solves. Hibernate criteria queries aren't much better.
IDE support is still lagging, but mostly in the area of debugging at this point. Code inspection is doing pretty good (at least in IntelliJ).
You'll never want to write another line of Java again! Likely you'll want to punch a wall or break something when forced back into the awkward syntax of Java.

The answers here are somewhat dated circa 2022 so I thought that I would contribute with an update. I have been working in a tech company that started using Scala at about the same time this question was originally asked. I recently blogged about lessons learned in that shop when trying to teach Java developers how to work with a code base written in idiomatic Scala so this topic is top-of-mind for me right now.
Just about all of the maturity issues in tooling, educational
collateral, and integration are gone. Version 2 of Scala is just as
rock solid a programming language as version 8 or 11 of Java.
Some of the most obvious advantages in switching to Scala are no longer
relevant because those language features have been added to newer
versions of Java.
Where Scala continues to outshine Java is in terms
of modularity and readability which affords idiomatic Scala as able
to handle code complexity better than Java.
That improved code scalability comes at the cost of a higher
learning curve which makes Scala less attractive to junior developers
who tend to make up the majority of your engineering group.

Why would you choose the Java programming language over others? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why would you choose java over others? Why did you choose java to program your application?
Please include what you are using java for (desktop application/ web application/ mobile).

Excellent tooling: IDE, CI, etc.
Vast array of 3rd party libraries.
Huge amount of documentation available.
Large pool of developers available.
Platform ubiquitous.
Excellent performance.
Excellent specification.
Sturdy garbage collection.
Managed memory.
Native threads.
Choice - implemented by multiple vendors.
I have used Java to build various middle-ware products: Inventory mgmt; CMS; chemical registration; etc.

One of the nice things about Java is that everyone knows it. Of course, now that I've said that, I'll get 80 comments from people claiming to have never learned the language. Be that as it may...
Like it or not, Java is the closest thing to a lingua franca (the idiom means "common language") we have in the industry today. Just about every has either used Java at some point, or (more commonly) is actively using it now. That sort of ubiquity can be extremely attractive to some companies, particularly those reliant on consultants. If you start a project in Java, you're pretty much guaranteed to be able to find talent to maintain the code base for years down the road.
On a different tack, Java is an excellent language for developing cross-platform desktop applications...it's just that nobody knows it. Most of Java's dominance is on the server side coupled with a little bit of love from the J2ME crowd. However, if you objectively consider Swing in Java 6uN, it's hard to find a better tool for the job. Don't get me wrong, I see that it has its flaws, but many of those have been fixed in recent releases. Most of the issue now is mindshare: everybody knows that Java is slow and ugly (neither of which is strictly true anymore). The other problem is that Swing is very much a cross-platform UI toolkit. This means that it is inherently much harder to create professional UIs in Swing than in Cocoa or even WinForms.
Finally, a really great reason to pick Java (as opposed to .NET or Objective-C) is the ecosystem. Other answers have mentioned libraries, which really deserve a significant spotlight; but I'm thinking specifically of the rising language diversity. If you write an application in Java today, you can seamlessly transition to Scala at any time. You also have the option to do scripting in Groovy or JRuby, not to mention taking advantage of the powerful concurrency abstractions in Clojure. Because of its portability and high-level nature, the JVM is increasingly the preferred target for language compilers and interpreters (even more than the CLR). Java is really at the center of that nexus, not really benefiting directly from the vast cloud of languages which swarm around it, but certainly deriving value from all of the interoperability, present and future.

My reasons for prefering Java over other programming languages at this time are:
price - it's free
performance - really fast these days thanks to the HotSpot JIT compiler
effectiveness - lots of power with rigorous features like type-safe, sand-boxed, etc.
OOP capability
very good, well-thought out exception handliing; C++ exceptions are the opposite!
portability - it runs on almost everything
tool availability - awesome IDEs like Eclipse & NetBeans are free, as are web servers like Tomcat and application servers (JBoss, Glassfish, Geronimo, etc.)
flexibility - does graphics, desktop GUIs, web user interfaces - all kinds of things in all kinds of runtime environments
aptness - many enterprise apps today have to support HTML, SQL, and XML - Java has good support for all of them built in and you can get third-party libraries for free that make this even easier/better
well-supported - Sun keeps adding improvements and fixing thing going one or two versions back
forward compatibility - unlike something like VB which undergoes wrenching change in its syntax every couple versions or so, Java's syntax and semantics seem about 99.9% upward compatible from version to version
I have been writing programs in Java for over a decade and I am pretty satisfied with it. I have used other languages for almost two decades before that. So I am not biased by describing the one thing I know - it is one of many languages I know intimately.
When upgrades to the JDK/JRE come out, I look the documentation over to see what is changed. Sun is good about telling/explaining this. I have never had an extremely rough time porting from one JDK to the next.
When I have switched from one OS to another as my main OS at home or at work, it has not caused a problem for the Java applications I write - or the tools I use, generally. The one exception is Borland JBuilder, which some Borland marketing or technical genius decided to frequently stop supporting. Eclipse and Netbeans run terrifically on the Mac and probably always will. I have used Java on:
MS-Windows 95, 98, NT4, 2000, XP
Sun Solaris/SunOS Unix
IBM AIX
Mac OS X
Linux
Motorola cell phones (MIDP, CLDC)
Palm Pilot PDA
Java VMs (virtual machines) are everywhere! They are in:
web browsers
cell phones
PDAs
desktop computers
web servers
application servers
I have written programs on all of these. All you have to do is get an IDE with the right plugins, get the API documentation for the target environment you want, and start programming.
The GUI programs I write actually do look & work correctly on different platforms! I cannot tell you how long other vendors promised to do and how often/long they have failed. Just look around, some still exist.
Sun promised this in Java 1.0 and they sort of delivered it with AWT. However, the abstract windowing toolkit used native GUI components and the differences between these components (which followed no unifying standard at all) were too great to get same/nice look/behavior on all platforms.
Sun delivered very well upon this portable GUI promise when the Swing GUI API was delivered a decade ago, back in December 1998.

1) Very good and free documentation
2) Very good developer commercial and free tools
3) good certification and training resources
4) good runtime and free tools
5) good profiling and monitoring tools
6) very good support options from various companies
7) very good open source community with huge amount of libraries

Things not yet mentioned:
Cross-platform Desktop Application, even with sophisticated GUI
bunch of tools
static typing (see GWT)
error messages at compile time
very clear error messages

Java provides a very rich API right out of the box and hands-down produces the most portable applications since there is a Java VM for almost every platform.
BTW: I haven't used Java since I left college since I work for a Microsoft shop, but I can't think of a single thing I can do in C# that I can't do in Java, whether it be enterprise applications, web applications, or desktop applications.

Portability is the key to java. I know that a program that i am coding will run on any system, there is no need to create different releases for different OS's.
Java also offers built in security, making the coding of the safe programs easier.
Java is fast, with clean code java is benchmarking in the same range as C++.
C# is the language that gets compared to java the most often. C# isn't as portable as java, and has very few features that java doesn't. This makes java much more attractive unless the program will ONLY be run on a single OS, in that case i might code it in C++.

I switched from years of C++ to Java because I was working on higher level stuff and needed the benefits of memory management, reflection, and sandboxed execution that I get with Java.
I have tried COM in the late nineties and could not touch it.
.NET looks promising and in many ways is now much better than Java. Unfortunately, being window-centric is a complete dealbreaker for me.

Another benefit is the awesome static analysis tools available e.g. FindBugs. These perform a lot of checking on your code above and beyond those performed by the compiler, and can help identify bugs and/or code smells before testing begins.

Lots of great reasons have already been mentioned. I'd like to add the political part. I trust Suns language a lot more than Microsoft alternatives. It's not because I hate Microsoft, it's just that Sun is going a direction with Java that I really like, and Microsoft is going a direction with .net etc. that I really don't like.
This is very subjective, I know. But to me it seems like Sun really want to create a great language, and try to make money somehow. While Microsoft seems more interested in making money by vendor lock-in and systems that looks great and feels great, but may not be as good as it looks in the long run.
So the way Microsoft is handling it right now, I don't even care about how good or bad it is, technically. I don't care, I'm not going to use it.
Java has everything I want from this kind of programming language, including all the boring political stuff most people just skip. I don't know about any other current language that has all that.

The main reason I use Java for most of my desktop app projects is for cross-platform compatibility. It's quite easy to make your app run on OS X, Windows, and Linux and look native on all platforms.

I use Java for our BPM platform and used Java in the past for enterprise web apps.
It depends on what you want to do. Considering language features, libraries available and IDE experience, I personally would choose C# over Java. C# 3.0 has many useful features that Java lacks, such as LINQ, Lambda expressions, etc. Some people prefer the huge library choice that is available for Java, but I think there are just too many ways of doing things. Java IDEs like Eclipse and NetBeans are getting better, but I think Visual Studio is still much easier to work with.
Of course,if you are not using Windows, you don't have much of a choice but to choose Java. Ruby and Python can be good options for things like utility apps and GUIs, including Web apps, but for enterprise apps that don't use Windows, Java is pretty much the only option.

Please don't follow blindly all java-entousiasts. Java has its own flaws. Java is great for rapid development, enterprise oriented stuff, and "high productivity" project (with the tons of projects, community,...).
And if one guy show me a benchmark highlighting how java code can be as optimal as C stuff doesn't mean the complete java solution is fast and lightweight.
Java will never find its way on some performance critical applications, like games, codecs, web browser. No major game software is developed in java, and not because the developper are not capable of writing one piece of Java code that has the same speed as C or C++, this is because the very limitations of the language involves that performance and memory consuption will never reach a good C/C++ code. Takes VisualStudio and Eclipse. Java is great for one stuff (productivity stuff, enterprise middleware), but if you want to write codecs, games, performance critical libraries, you'd better try knowing C.
But, one the other hand, you'll write the java code faster and safer, with C and C++ you're taking more risk (pointers!) and this takes usually more time.
And don't forget the joke "Write once, Debug everywhere", this is actually true. You have to deal with different JVM implementation nightmare with Java.
Other programming language have their interest, bash/python scripts for local scripts (repetitive action, fast and quick UI,...). Php or ruby for webapplication are very well deployed and documented on the web.

Using it for desktop applications.
Excellent IDEs available, wonderful API, "C-style" syntax makes it easy to pickup. Once the JVM starts, the performance is great.

Why would I choose Java - is it the most popular language out there right now? If not, it's gotta be damn close, so if I'm building a product I might choose this because it would be the easiest to hire developers for.
Why did I choose Java - because it's what I know best.

Why would I choose Java? If I happened to have a team of replaceable code monkeys developers that knew Java better than anything else, that is probably what I'd go with.

Scripting in Java [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Me and some friends are writing a MORPG in Java, and we would like to use a scripting language to, eg. to create quests.
We have non experience with scripting in Java. We have used Python, but we are very inexperienced with it. One of us also have used Javascript.
What scripting language should we use?
What scripting language should we not use?

I'm responsible for a fairly large hybrid Java/Jython system. We use java for core API development, then wire Java objects together using Jython. This is in a scientific computing environment where we need to be able to put together ad-hoc data analysis scripts quickly.
If I were starting this system from scratch today, I would not choose Jython as the scripting language. I like Python fine, but I frequently encounter awkward mismatches between the Python type system and the Java type system. For example, if you just want a hashtable, should you use a Python dictionary or a Java HashMap? The decision might be different depending on whether you are just using the data structure locally in Python code or passing it across the Java boundary. Jython does a certain amount of type coercion for you, but it's not perfect. It's annoying to even have to think about issues like this when the purpose of using a scripting language in the first place is to enhance your productivity.
I assume JavaScript or JRuby would have similar issues. Today I would choose a scripting language that is specifically targeted to the JVM and leverages the Java type system. The obvious candidates are Groovy and Beanshell; Groovy seems to have been picking up momentum lately so I'd look most closely at it.

I agree with Viktor's Jython suggestion. Other than that and JavaScript (which you've mentioned, and is built into Java 6+ via the javax.script package), Groovy and JRuby are also worth looking at too.
By the way, you should look at Wyvern, also an MMORPG written in Java and using Jython for scripting. Steve Yegge, its author, has much to say about it from time to time. :-)

Java supports a variety of (scripting) languages, some are listed in Wikipedia here and here. You probably should choose language with powerful DSL and metaprogramming capabilities, such as Clojure.
But if you need something simpler, JavaScript might be a viable alternative.

How about Jython?
http://www.jython.org/Project/

what about creating your own specialized scripting language? If your app is written with java, you can use ANTLR (http://www.antlr.org/) to create your language parsing code.
The reason I say this is because a general purpose scripting language may provide too much power (because the script it to be used for quests only i assume).
But if making your own language is too hard then any of the above suggestions works - you just have to figure out how to bind the game's runtime into the script. I also suggest Lua (http://www.lua.org/) as another choice that lots of games use.

Short version
Don’t use a scripting language! Instead focus on configurability (which is something that a non-programmer can do well).
Longer version
One oft-used argument in favour of having a scripting language is that it allows for lesser programmers to more trivial tasks. Don't belive this, it will not save you any time, since trivial tasks are already accomplished by real programmers in no time. Aim for configurability instead of scripting, and you will have a much lower risk of bleeding over complex algorithms and concepts into the incapable hands of game designers. :)
Lack of hotswapping (edit-and-continue) would have been a reason to implement a scripting language in an MMOG (you don’t want to reload the whole game for a minor code change), but using Java, with built-in hotswap, you really have no reason for adding a scripting language on top.
I have spent years pondering these questions; in the day I implemented a complete scripting language, IDE, VM, debugger, etc for an MMOG myself. Since, I have grown wiser.
If you still choose to go down the infinitely crappy path of no return, keep the following in mind.
Pick a mature language which has been around for a while.
Auto testing, debugging and editing will suck bigtime until you make your own tools/plugins/start hacking around in the VM.
To date, I have never seen a DSL that improved the situation (getting a more maintainable product). Myself, I integrated Python into my indie game engine, but eventually came to my senses and ripped it out. "Stackless Python" is just a way of saying "unmaintainable but fast". Please, anyone correct me if I'm wrong?

See Java: Scripting language (macro) to embed into a Java desktop application

You have quite a few options:
Groovy - http://groovy.codehaus.org/
Jython - http://www.jython.org/Project/
JRuby - http://jruby.codehaus.org/
Possibly even BeanShell (http://www.beanshell.org/)
I'm a fan of Python myself so I'd recommend Jython, but they're probably all reasonable options.

I would have to recommend Javascript for this purpose. Mozilla Rhino http://www.mozilla.org/rhino/ is an excellent implementation that would fit your needs perfectly.
I recommend Javascript over Jython or JRuby because of familiarity. Trivial Javascript follows a very familiar syntax that anybody can use. However if someone wants to do something more intense, Javascript is a very powerful functional programming language.
I regularly use Groovy and Ruby professionally and believe that their purpose is best for writing parts of applications with particularly complex logic where Java is cumbersome to write. Javascript is a much better choice as an embedded, general scripting language to use in a game. I haven't used Python, but it's syntactically similar to Ruby and I would believe it's purpose would also be similar.

LuaJ seems to be a nice way to embed Lua into Java:
http://sourceforge.net/projects/luaj/

I am a big fan of Python/Jython due to the clean syntax - which may suit you if you have some python experience.
Otherwise Groovy which is based on Java syntax and may be an easier learning curve if most of your developers are Java guys. It also has the advantage of closer ties with the Java language and libraries.
Beanshell is good if you have simple scripting in mind - it doesn't support classes. However I don't think it has had any support over the last few years (the JSR seemed to kill it off...) so is perhaps a bad choice if support is important to you.