Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am constantly reading about how much Cobol code is still in production. And the main reason that it hasn't been updated into am more modern language is that it would take too long/cost too much.
My question is: If there was a tool that converted Cobol to, say, Java, would any organizations find it useful? Or would they rather continue maintaining what they know already works?
Currently, a large volume of the COBOL code (I'd estimate well over 90%) is untestable.
No one knows what it really does.
They know that -- minimally -- it does the expected job most of the time. And when it doesn't, the bugs are known.
Worse, some percentage of COBOL is just workarounds for bugs in other parts of the COBOL.
Therefore, if you subject it to any scrutiny, you'll find that you don't know what's really going on. You can't create test cases.
Indeed, you'll find that most organizations can't even agree on what's "right". But they're willing to compromise on what's available.
The cost and risk of examining the core business processing is unthinkable.
Any conversion tool would have risks associated with it, and the resulting code would have to undergo a lot of testing.
Given that a lot of these systems are in use daily to run a business, a lot rides on the continuing operation. So it is not just "how long" or "how expensive", but can we trust it to work 100% the same.
One will always find tools to convert one language to another - they usually go by the term "compilers".
There is always a shortcoming with compilers that have to perform the task of converting code in language X to language Y, especially when the said code was written by a person. That shortcoming happens to be the fact that readbility is often lost in the process of translation. There is no guarantee that the code compiled from COBOL to Java will be understood by any programmer, so in effect the cost of translation has actually increased. In fact, it is difficult to define readability in such a context.
Lack of readability and understandability translates into lack of knowledge of runtime behavior of the translated code. Besides there is no guarantee that people understand the original code completely; surely they do understand bits and pieces of it.
Probably a little of both. There are companies that provide tools and services for conversion using both automated and manual techniques.
Many companies, however, follow the "ain't broke" philosophy, which is likely as wise as anything. Especially since many conversions result in attempts to "improve" the existing system or try to introduce modern software design/construction philosophies and result in a mess.
Many systems written in Cobol have many transactions going though them. They work well on the mainframe platforms that they run on. It would be risky to change them just for the sake of change.
I think some organizations could find it useful, particularly organizations where interfacing with/designing around legacy code has become more costly and problematic than converting the code to Java (or another language)
while ( (CostToPortToJava > CostOfNotPortingOverTime++) && DoesLegacyCodeStillWork() )
{
StayWithLegacyCode();
}
PortCodeToJava();
There are a few factors here:
Cobol program files are super long and just about always on ultra-secure mainframes. Usually the Java developers don't have access to them.
Colleges & Universities haven't taugh Cobol for more than 20 years. As a result, all of the really top-notch Cobol developers have moved up in their companies to be replaced with a bunch of tech school grads. These people didn't love programming enough to be hackers (or they'd do C, Python, C++, whatever and wouldn't have taken a course) or enough to go school (and be Java, .Net, Python, whatever).
Java developers generally lose their minds when they look at Cobol programs in their 50,000 line glory, so they aren't any help.
There really aren't any documents, and the logic is so tight in these programs that you should really just read them and convert them.
Most of these companies are financial companies where the best way to blowup and not be in the industry anymore is to screw something up. Good way to screw something up is to tack something like converting a critical task from Cobol to Java.
It's going to take a long time - every so often, part of one of the programs stops working or can't do something, and it gets replaced. I don't see a lot of senior managers having the stomach for the all of the FUD in one of these projects, and the timeframes are pretty long in terms of return on money spent.
COBOL is, in effect, a superb DSL (domain specific language).
It's domain is business rules as embedded in (mainly) backend applications.
Find another language that....
is feature rich in that specific domain
has some years of actual, applied, experience behind it so all the gotchas are cured or out in the open
has a TCO (total cost of ownership) lower than the existing COBOL legacy mountain
is cost-effective to convert to
....and you will have the killer application for backend business applications.
Something to realize about old COBOL applications, besides the language dissimilarity, is that at a lot of data structures built in these applications don't conform to any later RDBMS structure, so really you would be talking about rethinking a lot of the underlying architecture and design, not just changing the language syntax, and replacing that would have a lot of performance risk once it hit real world loads, even if it could be QA'd sufficiently.
The bottom line is that it is more economical to bolt on new features in a modern language than rewrite it. As long as that continues to be the case, COBOL will continue to live on.
Cobol has the advantage of being fast for moving data around, which is what that kind of applications tend to do a LOT. Also the machines are designed for I/O, not processing speeds. Hence, any translation to another language will most likely be slower than the Cobol counterpart on identical or similar hardware, leaving no reason to do so.
Let me ask a counter question: WHY convert it, if you have something in place that works?
(Similar to tearing down a bridge ever 10 years just for rebuilding it again right afterwards - it is usually always cheaper just to maintain what you have).
There are translators around which can be modified at little cost to make it run on a specific machine or operating system and some are available from England and can be run there or on site. Standard versions exist for the major models (anyone can contact me about them). Cobol to another language source code or script is relatively easy to do automatically and would produce a text file for import into a source file on the target machine with 95 percent or more code compatibility. Simple manual amendments are all that are necessary before running the compiler or JIT software to achieve a new program - do not forget to amend the job command language or macro for mainframe jobs when testing or going live. New cobol compilers exist for ICT/ICL mainframes and one or two others and these compile faster than the old software and sometimes the new compiled program can run several times faster.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
First of all, I love Python, and I currently use it for most stuff. However, as a PhD student, I mostly implement prototypes for testing and evaluating ideas. This also includes that I'm usually the only one coding, and that -- while I certainly try to write half-way efficient code -- performance is not a primary issue. And for quick prototyping, Python is for me just neat.
Now I consider to go with some of my stuff more "serious", i.e., to bring it into a productive environment, make it better maintainable, and maybe more efficient. So I wonder if it's worthy to rewrite my code to, say, Java (with which I'm also reasonably familiar). I know that Python is not slow, but things like Java's static typing including seems to make it less prone to errors on a larger scale, particularly when different people work on the same project.
It's only worth it if it solves a real problem, note, that problem could be
I want to learn something better
I need it to go faster to reduce power requirements in my colo.
I need to hire more people and the talent pool for [insert language here]
is too small.
Insert innumerable real problems here.
Python and Java are both suitable for production. Write it in whatever makes it easiest to solve the problems you and or your team are facing and if you want to preempt some problems make sure you've done your homework. Plenty of projects have died because they chose C/C++ believing performance was going to be a major factor without thinking about the extra effort involved in using these language well.
You mentioned maintainability. You're likely to require more code to rewrite it in Java and there's a direct correlation between Bugs and LOC. It's up for debate which one is easier to maintain. I'm sure both camps believe theirs is.
Of the two which one do you enjoy coding with the most?
The crucial question is this one: "Java's static typing including seems to make it less prone to errors on a larger scale". The crucial word here is "seems." Sure, Java will help you catch this one particular type of error. But how important is that, and what do you have to pay for it? The overhead imposed by Java's type system means that you have to write more lines of code, which means reduced productivity. I've used both and I have no doubt that I'm more productive in Python. I have found that type-related bugs in Python are generally easy to find and fix. Keep in mind that in a professional environment you're not going to ship code without testing it pretty carefully. The bottom line for a programming environment is productivity - usable functionality per unit of effort, not the number of bugs you found and fixed during development.
My advice: if you have a working project written in Python, don't rewrite it unless you're certain there's a benefit.
Java is inherently object oriented. Alternatively python is procedural.
As far as the ability of the language to handle large projects you can make do with either.
As far as producing more usable products I would recommend java script as opposed to java because of its viability in the browser. By embedding your js in a publicly hosted website you allow people with no coding knowledge to run your project seamlessly in the browser.
Further more all the GUI design features of HTML are available at your disposal.
That said any language has it's ups and downs and anything I've said here is simply my perception.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a history of hating Java, having used it pretty regularly in the late 90's during the 'slow as balls' era. As such, I never really learned it well. From what I understand, Java is actually a pretty good language to use these days. I've been thinking about diving into it because of Jython and Clojure. That is to say, I'd like to program in Java and use inline Jython or Clojure where appropriate. But truthfully, I'll probably just be programming in Jython/jRuby and calling up clojure from there.
Which brings me to my question. I know both of these languages can be called from Java, but is that necessarily good practice? Should I even bother learning java if I just want to use Jython as the primary language? Seeing as how that's a large part of my motivations here, I'd like to know that I'm not terribly misguided before jumping in. I'm aware there is a very high risk for projects to become a kludge if done in multiple languages like this.
I'm still learning about the JVM and the like, so I apologize if this question is painfully obvious.
Jython can be viewed as a cross compiler from Python to the Java Virtual Machine. As such, to get the most out of Jython you'll obviously have to learn Python, and probably will need to learn Java.
You can skip some of the Java learning, but at the end of the day, Java and the JVM grew up together. That means that Java code tends to lend understanding of the JVM. It is possible to gain understanding of the JVM without Java, but that's not a path well travelled. Any Jython code that imports a Java library will immediately have you searching Java documentation, so if you avoid leaning Java you're going to learn it piecemeal anyway.
You will have to decide if a piecemeal approach or a formal approach is more appropriate for you and your situation. A lot of deciding which path to take is knowing how you learn best.
As far as the "slow as balls" period of the 90's, that's when I was learning Java. Personally, I feel it is better to describe it as "slow as balls if you did incredibly stupid things with Java". Now I think people have built up a sufficient skill set to avoid translating C directly into Java. That said, I do occasionally encounter the 2000+ line method, so perhaps I'm being a bit rosy in my projection. The entire JVM is laid out in such a manner that good object oriented code runs faster, and if you're constantly trying to go to "other" objects for all the data you need locally, you'll just stack thrash the JVM.
Regardless of opinions, the JVM is now the hot Java item. There has been "other language" support by one means or the other for over a decade now; however, the excitement around Domain Specific Languages seems to have sparked an interest in compilation technologies and the JVM. The other languages benefit from the JVM being an easy target to hit with built-in cross platform support, excellent performance, huge availability of libraries, and generally good documentation. Learning Java and the JVM will help you with a lot of the JVM supported languages, as many of them don't flesh out their library space in favour of hooking into a pure Java library.
I'd say it's worth knowing Java even if you plan on only using other JVM languages. I use JRuby and Scala, and have played around with Clojure. If you are building things to run on the JVM, knowing Java is a bit like knowing C when working natively–you don't have to know C, but if you do, you can write the bits that need speed in C and wrap them in a Ruby or Python library or whatnot.
It's worth knowing the basic principles of how Java works in terms of things like interfaces and annotations and how the classpath works because otherwise you are working with basically a leaky abstraction. What happens when your interop isn't very good? This is especially true if you are planning to do Clojure and Jython!
The other reason to know Java is simply because if you are using code in the Java ecosystem, you have to be able to read and write Java. You need to write a library? Yes, you can probably write it in Clojure, but if you want other JVM language users to be able to use it, you should probably have written it in good, idiomatic Java. Scala is close enough to Java for this purpose; Clojure or Ruby or Python, not so much. Just being able to read and comprehend Java programs is very important too.
The other great benefit is simply that you get more libraries and they are better tested. You need a double-ended queue? Check the Java Collections Framework. Good random number generation? java.security.SecureRandom. UIs? Well, Swing, AWT and SWT are... okay, bad example. Knowing the benefits and shortcomings of these only comes from doing some Java programming and learning the various ways not to suck at Java.
From a couple of years experience of using Clojure (plus many more years of Java...) here is my perspective:
You don't strictly need any Java experience to write Clojure code - Clojure is a full language in its own right and you can write perfectly capable programs without using any Java.
You will need to set up the JVM environment - the Java environment has some rules about where code gets loaded from (i.e. the "classpath") that need to be followed to get a working environment. Not a big deal, and most IDEs will do it for you, but it can be a hurdle for people completely new to the JVM world. I'd suggest careful following of the setup instructions for whichever IDE/toolset you choose.
There are some Java-related concepts that are helpful to understand - for example, Clojure harnesses Java exception handling features with (try ... (catch ...)) etc. so it's useful to be somewhat familiar with the Java approach to exception handling.
Ultimately you will probably want to use Java APIs - bacause a huge amount of the value of being on the JVM in the first place is in having access to the huge diversity of libraries and tools that are available in the Java ecosystem. You don't need to write any Java code to use Java APIs from Clojure, but you do need to know enough Java (method signatures, data types etc.) to be able to read the JavaDoc documentation of the APIs and convert this into an appropriate Clojure function call. Often, this is as simple as (.someJavaMethod someJavaObject param1 param2) but sometimes it can be more complex (e.g. when you need to instantiate a subclass of some Java class to pass as a parameter)
Java isn't a bad language to learn anyway - while I'll readily admit Java has some weak points (as do all languages!), it's still a great, simple, high performance, cross-platform, object-oriented language that has a lot of value. Even if you only do a few short tutorials and never write anything substantial in Java, I'd still recommend it for the learning experience.
I believe most of the above would also apply to Jython.
I can't speak for Jython, but if you want to really get to grips with clojure, you want to understand its trade-offs compared to Java, especially wrt memory/gc and the basics of Clojure/Java interop. You also need at least an abstract understanding of how the clojure collections are implemented unless you really don't care about performance - that's not to say that clojure is particularly inefficient, but more the opposite: the implementation of its immutable collections is fairly unique and tailored to clojure's stance on persistence and performance and it helps to understand the underlying details when you're trying to improve on performance issues.
For all of that, I don't think you actually need a lot of Java knowledge. Being able to read Java fairly well, a basic understanding of the concepts, and a knowledge of where to find the documentation is probably enough.
I think if you want to do a hybrid Clojure/Jython project the interoperation details are most crucial. That probably means you have to know in some detail how classes, interfaces, some of the standard library and (to a minimal extend) generics work in Java and how to deal with all of those in your chosen languages since the interoperation necessarily reduces to the more basic Java constructs. Some of this is tricky and can be confusing, and in clojure's case at least the documentation often refers back to Java concepts and documentation for obvious reasons, so you have to make sure you read both, closely.
I would definitely learn java and learn it well, not only because Clojure is built on top of the JVM but also to get anything done you will be calling Java libraries all the time, and you may even need to dip into Java occassionally.
On another note it would be expand your mind to understand Java's OO concepts and pain poaints too and this will enhance your undersatnding of Clojure too.
Above all, study the Java libraries. Part of the joy of using the JVM is having access to "it's already been done" libraries, as well as to parts of the core language that accomplish certain tasks with optimum performance on the JVM. In addition, some languages (e.g. Clojure) purposefully dip directly into Java and don't completely discourage it in your own code, so if you want to be able to read others' code Java basics are a must.
As for the rest of "learning Java" (design patterns, concurrency in Java, etc.), I wouldn't waste your time unless/until specific projects requirements demand it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Are there any tests that compare Javascript's performance with Java's?
UPDATE: Since everyone is asking why the hell this question, here is some context :)
As you all know - I hope - Javascript nowadays doesn't only reside in the web client but also in the web server with node.js.
It could also be run in mobile phones and dekstops with appcelerator and phonegap.
It could also be used substantially in the web browser to make the user experience first class like with desktop applications.
But Java could do these things too, running applets on the web client, and on mobile phones. It's also a language for the backend with many frameworks to choose between.
Since each one of them could almost/entirely replace each other in the mentioned area, I want to know the performance difference between them, for every case I described:
Client: Java Applets vs Javascript
Server: Java EE vs Javascript with Node.js + Express
Mobile phones: Java ME vs Javascript with Phonegap / Appcelerator
Desktop: Java SE vs Javascript with Phonegap / Appcelerator
I hope the context is more clear now.
Java and JavaScript are both programming languages. Programming languages are just a bunch of abstract mathematical rules. Programming languages aren't fast. Or slow. They just are.
The performance of an application has nothing to do with the language. The most important factor is the application architecture. Then comes algorithmic efficiency. Then micro-optimizations. Then comes the quality of the compiler/interpreter. Then the CPU. Maybe a couple of other steps in between. The language, however, doesn't directly play a role. (And of course if you're talking about benchmarks, then also the particular benchmark plays a role, as well as how well implemented the benchmark is, how well run it is, whether the guy who performs the benchmark actually knows something about benchmarking, and even more importantly statistics. Also, the precise definition of what you actually mean by "fast" is pretty important, since it can also have significant influence on the benchmark.)
However, the language might indirectly play a role: it is much easier to find and fix performance bottlenecks in 10 lines of highly expressive, clear, concise, readable, well-factored, isolated, high-level Lisp code, than in 100 lines of tangled, low-level C. (Note that those two languages are only examples. I don't mean to single any one language out.) Twitter, for example, have said that with a less expressive language than Ruby, they wouldn't have been able to make such radical changes to their architecture in such a short amount of time, to fix their scalability problems. And the reason why Node.js is able to provide such good evented I/O performance is because JavaScript's standard library is so crappy. (That way, Node.js has to provide all I/O itself, so they can optimize it for evented I/O from the ground up. Ruby and Python, for example, have evented I/O libraries that work just as well as Node.js and are much more mature ... but, Ruby and Python already have large standard libraries, including I/O libraries, all of which are synchronous and don't play well with evented libraries. JavaScript doesn't have the problem of I/O libraries that don't play well with evented I/O, because JavaScript doesn't have I/O libraries at all.)
But if you really want to compare the two, here's an interesting datapoint for you: HotSpot, which is one of the more popular, and also more performant JVM implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, HotSpot didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.
V8, which is one of the more popular, and also more performant JavaScript implementations out there, was created by a team of guys which included, among other people, a guy named Lars Bak. But actually, V8 didn't appear out of thin air, it was based on the sourcecode of the Anamorphic Smalltalk VM, which was created by a team of guys which included, among other people, a guy named Lars Bak.
Given that the two are more or less the same, we can expect similar performance. The only difference is that HotSpot has over a hundred engineers working on it for 15 years, whereas V8 has a dozen engineers working for less than 5 years. That is the only difference in performance. It's not about static vs. dynamic typing (Java is statically typed, but most JVMs and certainly HotSpot make no static optimizations whatsoever, all optimizations are purely dynamic), compilation vs. interpretation (HotSpot is actually interpreted with an additional JIT compiler, whereas V8 is purely compiled), high-level vs. low-level. It is purely about money.
But I am going to bet that for every pair of Java and JavaScript implementations where the Java implementation is faster, I can find another pair where the JavaScript implementation is faster. Also, I can probably keep the pair and just use a different benchmark. There's a reason the call the Computer Languages Benchmark Game a "game": they even encourage you right on their own page to play around with the benchmarks to make any arbitrary language rise to the top.
I only have an anecdote to add: I've recently reimplemented a Java calc server (finance) in Javascript (nodejs v0.6.8). WRT development time, the Javascript implementation was a breeze compared to the original Java implementation with far fewer lines of code. It was a breath of fresh air, really.
The Javascript-based server is able to calc through 2.4k trades/sec whereas the Java server handles 400+/sec on the same hardware using less memory. I wouldn't attribute the speed increase to raw V8 vs. Java 7 performance but rather to the implementation. The Javascript implementation uses far fewer data structures, does an order of magnitude fewer method calls and takes a more straight-forward and terse approach.
Needless to say, I'm very happy with the performance of node.js. And this, coming from someone who was Java only for many (9) years.
Here are some tests comparing Javascript (V8) and compiled Java:
32 bit
64 bit
They indicate that Java is generally faster1. However, if you dig around with those pages and the linked resources, you will notice that it is very difficult to compare like with like.
Interestingly, Javascript does significantly better than Java (under certain conditions) for the "regex-dna" benchmark. My guess is that this is because the Javascript regex engine is faster than the Java regex engine. This is not entirely unsurprising, given the importance of regexes in typical Javascript applications.
1 - Strictly speaking, you cannot say that language X is faster than language Y. You can only compare specific implementations of the respective languages. And the site I linked to is clear about that ... if you care to go in via the front page. However it is not entirely unreasonable to generalize from specific datapoints ... and the apparent of absence of contradictory datapoints ... that Java is typically faster than Javascript in computationally intensive tasks. But the flip side is that that kind of performance is often not an objectively important criterion.
Java, obviously.
Programmers love to compare execution speed like some sort of pissing content. It is just one metric, and the majority of the time, not the most important one by a long shot. Java is a language that has a mix of being fast enough for almost anything, but high enough level that you get stuff like GC, which you don't usually get in similar languages. Javascript is a dynamic closure language that is great for getting stuff done quickly (and for FP programmers stuck in an OO world ;-) ). There isn't much in the way of intersection in the spaces where either would be appropriate.
I'll stop pontificating now
EDIT: to address the edit in the post
Due to the way one writes idiomatic javascript (functions composed of functions), it lends itself surprisingly well to asynchronous programming, probably better then any other language of similar popularity. Node.js shines when it comes to a huge amount of short connections, so javascript is a really great fit for that sort of thing.
While node.js is absolutely drenched in awesome, being the new hotness really doesn't mean it is the best at everything, no matter what the hype says. If a java app is replaceable by node, chances are java wasn't really appropriate in the first place.
Probably not, but it doesn't really matter.
Prior to Google Chrome's JavaScript JIT, Java would win over JavaScript as soon as the problem got big enough to overcome the load time.
Java should still roundly trounce JavaScript due to integer vs. float math. No matter how good the JIT it can't really make up for this.
WebAssembly will turn this on its head anyway.
http://benchmarksgame.alioth.debian.org/u64q/javascript.html
(Remember to look at the cpu column as-well-as elapsed secs).
According to the above link JavaScript as reality stands now is much slower for almost everything.
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.
As a Java newbie I'm wondering: of all the languages in the world, why is Java frequently used for enterprise applications? What makes it that way compared to the other languages? Will it continue to be this way in the upcoming years?
I'd appreciate your insights. Thanks in advance :)
One word: libraries. Java has an vast array of excellent libraries for solving most of the common problems one needs to solve when developing enterprise applications. In many cases, there is more than one good choice for addressing a particular need, and oftentimes those libraries are free and open source under a business-friendly license.
Some have argued that there are, in fact, too many choices in the Java ecosystem, and that developing enterprise software in Java requires developers to make a large number of decisions that can have far-reaching impact on the end product for better or worse. This has probably helped propel the popularity of alternatives like .NET, which has a reputation of offering fewer choices, but with the benefits of a more well-integrated application stack and tools set. What direction you choose depends, I guess, on whether you place more value on "freedom of choice" or "freedom from choice".
There are lots of reasons a large company (the type to go for enterprise solutions) would pick Java. Note I'm not saying all these reasons are correct or valid. But the relevant point is that they appear valid to a CTO at MegaCorp.
Learning Curve
Java is a simple language without much of the flexibility of other members of the C family, this cuts both ways, but it is seen as a straightforward language for use by an army of programmers. Enterprise projects tend to involve large numbers of developers (rightly or wrongly) and it is much easier to get a developer to a minimum level of competence in Java than C++. You also have a whole generation of graduates who have probably been largely schooled in Java.
Choice
Java has a vast array of libraries, frameworks, tools and IDEs, and server providers. To an enterprise its good to have choice, even if that's just for use as a bargaining chip when negotiating price. The language lends itself to code quality tools that allow enforcement of corporate standards (and as mentioned there are a lot of those tools).
Platform Independence
Java is write once, run (well, debug) everywhere. Sun has actively encouraged open standards that allow multiple vendors to implement their solutions. These standards give the customer the comfort that they can migrate from one vendor to another if a given vendor goes under or starts charging more. Of course the reality is that each vendor does their best to provide some "added value" features that tie the customer to them quite nicely.
Maturity
Its been around a long time, running a lot of servers. If your web application needs to be "6 sigma" or similar and you are the MegaCorp CTO, you are not going to look that kindly on Joe the developer wanting to do it in RoR.
Timing/Marketing
Java came out when programming was moving towards the web. It was positioned cleverly and got a strong position early in web development. Because of the open standards, there are some very big companies producing these platforms and they market Java pretty hard to sell those platforms.
Inertia
Large corporations move forward at a glacial pace (a lot are still using Java 1.4 five years after 5 was released), so once they've picked Java, it takes a massive investment to move to another platform. With each day that goes by they're cranking out more Java that would need to be migrated. Most of these companies are not primarily coding shops, so it is a very hard sell to convince the business to spend a few tens of millions rewriting their entire code base for no immediate business benefit.
Another reason might be the care Sun has taken to keep Java backwards compatible. The vast majority of Java code can be run on the latest version of the JVM without a problem. That is quite an achievement, given the age of Java. On the other hand you might argue Java has not changed all that much in all these years.
Enterprises like stability in a platform.
Sun targeted Java to speak to the needs of enterprises early on. It pushes standards that promote vendor independance at every level. Platform independant, database independant, application server independant, etc.
In addition they promoted enterprise level tools for it, in terms of messaging, transaction management and other things that the enterpise worries about.
Before Java, enterprise level stuff tended to be done in C++ (there were plenty of exceptions (does anyone remember PowerBuilder?) but that was the rule) and Java fits well as a successor to C++ for business applications, where that kind of memory management isn't something worth paying for.
In addition to all of that the language itself speaks to enterprises in terms of avoiding hard-to-get-right constructs that can really mess up a code base, such as operator overloading. Enterprise level applications tend to get handled by many different hands, not all of which are the top of the line programmers, and having safty nets to prevent shooting themselves in the foot is a desirable thing.
It also came along at the right time. A new paradigm (this was well before .NET existed) that promissed to combine multiple vendors into an ability to compete with Microsoft, which got the likes of IBM and Oracle on board, that happened to fill a new hole, which was the emerging requirement to develop web applications, where C++ was no longer an obvious choice.
I shouldn't be saying this, but...
The real reason is because it's named after coffee!
Business is about time, money and opportunity.
Using Java means that your number of errors in the code goes down, simply because pointers are hard. You use a GC and you instantly remove an entire class of errors from your code.
Secondly, Java was one of the first languages to ship with a pre written library of functions, which really did cover a lot of the development phase. This restricted the way things were done but it meant that people could learn faster, had more tools at their disposal and had a great set of libraries to do things like network, GUI, web, encryption etc. Java on its own as a language really wasn't that special, but Java plus the Java API was.
So if you've got a language that has less errors and more infrastructure for free, then you end up with more code in less time. Sure the code doesn't cure cancer, it's not as fast as C++ code to achieve the same task, but it will achieve the business' goal of getting an application.
If you make more code, for less money, you can pursue more opportunities. You then bring inertia to the table in terms of code that's already been implemented in Java and you start seeing why the business doesn't want to move away from their comfort zone.
Personally I believe one major reason is the cross-platform issue.
Java programs written "correctly" (without assumptions of the underlying operating system) can run on any JVM. This means that you are not tied to a particular platform, unlike .NET which marries you to Windows.
I have seen Java code run on mainframes, Linux routers, inside Oracle database, and naturally on PC's.
It's cheap, RAD, cross-platform, and developers abound.
Developing in C++ is too slow and expensive and .NET has not been around for long enough. Business inertia is huge, remember.
Businesses want languages that are backed by a professional provider (ie. a company like Sun) and often stay away from Open Source languages for the simple reason that it was not written by a company.
Also for client-server applications, you have an abundance of choices for production-quality app servers that have the same J2EE interface (IBM WebSphere, BEA Weblogic, JBoss). Alternatively, you could use the Spring Framework on any server like Apache Tomcat the complies to the Servlet API if you're convinced you don't need EJBs. In contrast to .NET, it's hard to find choices with respect to app servers.
There are an abundance of choices with regards to frameworks for a given task be it an ORM tool, logging, collections, caching, web UIs, etc. There is no hardly any need to reinvent the wheel.
Finally, while it's fashionable these days to lament the very real shortcomings of Java the language, it's a language where folks know how to get things done and how to avoid certain anti-patterns.
The other answers are all good. Two things need to be added, corporate standards and the bandwagon effect. If you want to build an enterprise system you need to have pretty strong case for not using your company's entrenched standards and this is mostly JavaEE. And if you need to resource a project it is a lot easier to recruit a Java programmer than it is, say, Erlang.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am a competent C++ developer. I understand and use polymorphism, templates, the STL, and I have a solid grasp of how streams work. For all practical purposes, I've done no Java development. I'm sure some of you were in a similar situation at one point when you had to learn Java. How long did it take you to become a competent Java programmer?
I think that learning the language is not difficult. In fact, I used to be a full time C++ developer, and at some point I started writing Java code. But the thing is that I don't remember ever learning Java, so I guess I just figured it as I went. I've been doing full time Java for a long time now.
If you are well familiar with C++, you may want to read a list of the major differences (e.g., everything is dynamically-bound) and then start practicing on an environment (just download Eclipse). The small differences are the main thing you would have to get adjusted to.
Now that Java supports generics, one of the major switching pains is gone. Multiple inheritance, while not supported, is not a big deal if you get used to interfaces, and in fact having interfaces rather than abstract classes with pure virtual functions (PVFs) improves readability.
To me Java is a nice and friendly and relaxing sandboxed version of C++. I don't have to worry about general protection faults (GPFs), I don't have to worry about memory leaks, I don't have to worry about messing with pointers. However, don't let that confuse you, there are still plenty of opportunities to screw up royally, and they're sometimes even nastier to detect.
Just take the leap. If you have the instinct, it shouldn't be a problem.
I went the opposite way. Started with Java, then moved to C and C++. For my own personal experience, it was much easier to learn Java than C/C++ (C++ especially).
Java in many ways is meant to be C++ with many of the undefined and unnecessarily complicated portions removed or simplified. IMHO, it had great success with that goal. As a result it's a very easy language to learn and use. Especially for someone who is familiar with C++.
The actual time it will take is very dependent upon the person learning the language. However, I think it's safe to say it will take less time to become competent in Java than it did in C++.
Shouldn't be too bad. The syntax and classes should be very easy for you to grasp. There are some differences but none of it is too challenging.
The hardest part is more about learning the packages, since those will be different. The built in Java classes and functions, and then to use Java in a practical manner, you'll need to learn J2EE or whatever you might be actually using it for. The latter part will probably take more of your time than the language itself.
If you're already a competent programmer (especially in C++) then Java doesn't take long to learn at all. The books I would recommend (in order) for anyone who wants to learn Java are:
Head First Java
Thinking in Java
Effective Java
You may find that you zip through Head First Java rather quickly, given your experience. For that reason I suggest you check it out of the library and skim it before moving on to Thinking in Java.
Also check out Sun's Java Tutorials.
C++ to Java: 1 week.
Java to C++: 1 month.
As Tom Hawtin wrote, the key issue is how you define competent.
You'll be able to pick-up the language fairly easily, but it's the idioms and the libraries that you will have to learn. And there are quite a few differences between niches you work in (e.g. embedded or enterprise), and between libraries that supposedly solve the same problems. Here are a few examples:
In business/enterprise apps, you generally work with databases. There you can have:
plain JDBC
SQL mapper (iBatis), wrapper around verbose and repetitive JDBC
ORM solution (Hibernate), with a philosophy of it's own
With desktop UIs, you have two competing platforms:
Swing, a part of JRE
SWT/JFace, from Eclispe foundation, originated by IBM, with native UI support
Web frameworks are too many to mention, with different ideas of representing the UI, configuration, folder/package structure etc.
DI (dependency injection) is common in business apps, either by 3rd party frameworks like Spring, or as a part of EJB3 standard. But, I don't think it is ever used in embedded set-up.
It would be fair to say this is just a tip of the iceberg.
Back in 1995 when I did it, it took me about half a day to get comfortable with the tools and basic ideas, a day or two to get the language, a week to get the more obscure parts of the language (there were less of them at the time) and a month to get the libraries (there were WAY less of them at that time).
Now I would guess that the tools and basic language will take as much time, a couple of weeks to a month for the obscure parts of the language (depends on what parts you hit, and when). The basic libraries will be a month to two months (java.lang, java.util, and a few others). The remaining class libraries 6 months to forever depending on what you need to learn and how often the keep updating them :-)
I know C++, and had to work with Java once and picked it up in 2 weeks. Of course there were quite a few surprises but it's easy.
I have C++ background. Picking up Java took me few days - the language seems really simple - at least its basis. I still consult my Java guru - google quite a bit, but it's usually a matter of exploring API and standard libraries. Java has some annoyances, but you should spot most of them them easily and quickly.
I was recommended Thinking in Java (there's an ebook for free), but was never persistent enough to read through it. I don't write rocket-science code in Java and to do it, my skills are sufficient.
Having said that, it would be good to have better formal knowledge of the language. At the moment I'm thinking about studying for SCJP, which seems a sensible way of learning, plus you will get well-recoginized programming certificate once you pass it (I've heard it's not worth much, but still it may be a motivation...).
You can also try Java Black Belt - the answers frequenty surprises me. After taking few tests I wonder how my programs even compile, which suggests I'm probably not the most competent Java programmer around :)
How would you define competent? For my money, most professional (as in they do it for money) Java programmers never manage to reach competent.
These days, a programming language derives much of its power from its libraries and accepted idioms.
While it takes relatively short time to learn the Java language, learning to use the available libraries (collections, io, etc.) effectively will probably take significantly more time.
I think there are two approaches to meaning of term "competent Java programmer".
If it is about lexems, syntax and terms of OOP I began to completly understand Java before 2 (two) days of learning.
But firstly you will be charmed by impossibility to shoot your own leg ;)
But if it is case of embeded class system (i.e. packages), APIs references, tips-and-tricks and etc., it takes about half-year to feel yourself friendly with Java. I think.
I too learnt C++ first and then Java. It took very less time as I was already familiar with OOPS concepts. In the initial phase of learning I was really happy with new concepts in Jave like garbage collector. I referred The Complete Reference by Herbert Schildt and it did help me to get the syntax quickly.
I started from C++ and learned C#/.NET. That didn't take long.
As C#/.NET is developed very near to Java (they used many of Java's base techniques such as GC, reference classes, JIT, ...) I think it is not that hard to learn Java.
I would go with six to eight weeks.
Shouldn't take you more than a day or two to learn the language, but you might have to spend a few weeks on the class library: how to use collections, the concurreny package, reflection, logging, swing/awt, dynamic proxies, MBeans etc.
i learned c++ at a small age of 15 and became a professional software programmer. But when i searched for job there was only job available for java developers.I thought it was hard to change my language.So just for trial i Downloaded java compiler and just for fun typed some code and i found it is not much different than c++. and only after 6 hours of research and learning i became a java developer .so it is very easy to switch between c++ to java.