Celebrating 20 years of juicy Java. Just don’t mention Android Oracle is celebrating 20 years of Java, which was officially announced at the SunWorld conference in San Francisco on May 23 1995. Java 1.0a2 was made available to download. In addition, Netscape’s Marc Andreessen came on stage to announce that Java would be integrated into the Navigator web browser. The origins of Java go …
No, this is still a very common use case for java, especially at the enterprise level. What are the alternatives? A bespoke app for each platfrom? Too much effort. All the cross platform APIs I've seen are pretty rubbish.
HTML5 falls far form the mark for a lot of applications.
A lot of our B2B partners still have Java portals. Glad the purchasing role has been removed from my job description, I could de-install Java.
We still use it for server side on a lot of platforms.
My Surface Pro 3 has been a lot quieter since I de-installed Java and Flash.
"No, this is still a very common use case for java, especially at the enterprise level. What are the alternatives? A bespoke app for each platfrom?"
The problem is that 90% of the time that is what you end up with anyway - or worse just a list of "supported" platforms that basically boils down to "IE on Windows 7 or below" because supposedly enterprise java apps are always godawful activex tie-ins that only work on one particularly outdated version of Java on ancient versions of Internet Explorer.
Java should be cross platform, sure, but if it actually _was_ then we wouldn't all be so desperate to be rid of it.
“On browser, desktop and mobile the folks who make the operating systems for those environments, as well as things like browsers, have an interest in tightening those things down and allowing fewer third-party things to run,” he added.
No.... they have an interest in cutting down the amount of security risks. It's not that long ago that it seemed like every week we were being told to update the Java VM as an urgent because some new exploit was discovered.
Java took off rapidly. It met an immediate need on the fast-growing World Wide Web
I've been doing web stuff pretty much since Java was around. It was only ever niche on the web. Back then computers didn't have the oomph to do much fancy graphics in a virtual machine so Java was essentially limited to cryptography.
The cross-platform stuff was then, and still largely is, marketing. Sun was a single platform hardware company. But it managed to successfully market Java as a better (because memory managed and thus safer) C++. Netscape PR aside, the real work was in getting Java onto CS degree courses meaning that graduates were trained in something that was being pushed at managers. Moore's law meant that memory was much less of a restriction than it had been: for enough money Sun or IBM could sell you hardware beyond your wildest dreams. This is why Sun did so well out of the dot-coms.
It never really went anywhere on the desktop. I can only think of a handful of applications written in Java that I've ever used. The Java ME stuff was also pretty limited, largely due to the hardware (phones didn't have much memory and write once, run everywhere never really worked).
Flash, developed by Macromedia succeeded by being a better development environment for non-programmers than Java. ActionScript may have been a shitty runtime but it did what it needed to well, or well enough to create sufficient demand for ubiquity. This is why many new languages target non-CS graduates so much: traction is perhaps more important than having the best runtime.
Java's legacy may well be the work that went into JIT compiling which has now become pretty universal. Develop in whatever language you like and the right JIT will compile it to near native speed.
Cross platform in Java works really well.
Most web apps are developed on a PC running Windows or Linux and end up being deployed on all kinds of servers and architectures. Not only are the target operating systems often different but often the JVM and even the app server are different.
So cross platform is a reality of Java.
Even client side programming generally works extremely well. I've had no trouble writing fairly complex apps which run on Windows and Linux using Swing and SWT. The biggest issue with client side is that integration with the user interface often exceeds what the APIs might offer (e.g. system trays etc.) and so some JNI might be necessary. There are some incredibly complex client applications implemented in Java, e.g. Eclipse.
Cross platform in Java works really well.
Which is why all our desktop apps are written in Java… Oh wait, they're not. The LibreOffice lot are even busy ripping Java out – not that I'm personally convinced that this is such a good move.
On the server-side Java got established in the corporate space and will remain for the duration But it wasn't because it was multi-platform, it's because it was what IBM, Sun, et al. were able to convince the suits to buy.
As I said, the work done on the JVM has made it a lot easier for other languages to be reliably cross-platform. Also: thank god for QT!
"Which is why all our desktop apps are written in Java… Oh wait, they're not. The LibreOffice lot are even busy ripping Java out – not that I'm personally convinced that this is such a good move."
Eclipse & IdeaJ are two non trivial applications running on Java. And they're not just used for Java development either. Eclipse RCP is used in a raft of enterprise desktop apps. There are games too, of which Minecraft is the most well known.
"On the server-side Java got established in the corporate space and will remain for the duration But it wasn't because it was multi-platform, it's because it was what IBM, Sun, et al. were able to convince the suits to buy."
It was established server side because it is incredibly reliable and cross platform. Businesses value these things over raw throughput, Developers can write and package a .war / .ear application on a PC, transfer it to a suitable app server running on virtually anything and it will just work. It's extremely powerful and as testament to that, countless backends are powered by Java.
"As I said, the work done on the JVM has made it a lot easier for other languages to be reliably cross-platform. Also: thank god for QT!"
A QT application has to be recompiled, packaged, deployed and tested for every platform it runs on. It's no panacea.
I don't personally care what tech I use providing it's fit for purpose. I program Ruby, C++ (including QT), Java, Python, Javascript with no trouble. But I do take issue with claiming Java is not portable. It is BY FAR the most portable way to develop code. Nothing comes close.
It was established server side because it is incredibly reliable and cross platform.
That might be the case now, it wasn't then. Remember Sun was shipping its own hardware. Java was only as good as the JVM on the target machine. It took a lot of work to get all those JVMs working both well and fast. The cross-platform experience on mobile was much worse because the JVMs were much worse. As there was no money in it for Sun or IBM they didn't really have much of an incentive to work around the quirks of mobile OSes and chipsets. The initial attraction of Java was much more than it didn't get the same kind of memory errors that were only too common in C++. The excellent standard libraries and standardised deployment also appealed both to the enterprise and academia and JDBC still stands out for working with databases.
I've never got on with Eclipse but I won't discount its popularity in some areas, though I note that you again highlight use by enterprises. The IDEA J stuff is much nicer but look at the resource use compared to something running more native. Hasn't Google switched to IDEA from Eclipse for just that reason?
Sure QT requires compile and test steps for every architecture but modern hardware have made those far less of an issue than in the past. Companies are, however, driven by the productivity of their programmers, not by compile times.
I'm not really knocking Java but I do think it has peaked as a programming language.
Count yourself lucky. My experience, and the experience of many other Java developers, has been that it is "Write once, debug everywhere," with scores of platform-dependent quirks and outright bugs that drive implementation to the lowest common denominator, rather than a single, elegant solution.
> The cross-platform stuff was then, and still largely is, marketing. Sun was a single platform hardware company.
I disagree. When I moved from "cross-platform" C++ to Java in the late 1990s, all of a sudden the sun shone every day and the birds began to sing again.
You also forgot that the ecosystem was developed precisely to run on a variety on consumer devices.
It was only ever niche on the web.
I used to think the same, but then I worked at two companies that made massive use of Java in web clients. One was a wide range of tier-3 trading platforms distributed as Applets, the other a massive online game, also an Applet.
I think things like the trading platforms are distributed via Java Web Start these days, and gaming is switching to Unity.
Yep - one undervalued (ok - undersupported, undermaintained and ultimately undermined) aspect was the distribution. Being able to run an application just by visiting a URL - that was progress, particularly for large firms where it promised to replace sneakerrnet. I have a vague recollection of how impressed I was by an earlier technology that did just that, naturally it died a death.
It's a shame the promise of no-more-version-management didn't play out - ironically, for the apps it's probably still true but the onus of upgrading has shifted focus to the JVM.
I used to think the same, but then I worked at two companies that made massive use of Java in web clients. One was a wide range of tier-3 trading platforms distributed as Applets, the other a massive online game, also an Applet.
Applets, while no doubt important in some areas (I remember Brokat for banking and I think WebEx still uses it), were still very much niche on the web. There's no doubt applets were essentially the precursors to the rich client wheel we've recently reinvented in JS, but there was no money in them for Sun.
I was delighted to leave the Java language behind; compared to Python, C#, F#, Scala (and more), the language feels tortuously verbose and seems to attract and encourage the sort of ponderous developer who enjoys adding yet more indirection rather than getting the job done well in any sensible timescale.
However credit where credit's due: despite Oracle, the JVM is a fantastic piece of technology and the Java concurrency libraries are written with a level of skill and elegance few people (including me) will ever reach.
But the JVM really needs a new flagship language and Oracle isn't the company to make it happen.
The JVM is a fantastic piece of technology +1 to that
the Java concurrency libraries are written with a level of skill and elegance few people (including me) will ever reach. -1 one to that. In this day and age there is a simple maxima on all platforms it is (yes, I mean to shout): "MUTEXES AND REST OF POSIX THREADS WORK!!!" Java concurrency implementation is dependent on the underlying thread scheduler which java till this day does itself instead of fully relying on the OS (despite using OS threads for a while now). The consequence of that is that there is an embedded ancient piece of Solaris scheduler in it which constraints mutex rates, posix wait/notification rates and a few other key parameters in a modern app to a magic number which depends on the phase of the moon, the mood of the developer mother in law and a few other key parameters. In the meantime all OS-es and libraries as well as languages which rely on the OS native threading and notifications have moved on and are fully preemptive and NOHZ on most platforms.
You also forgot to add that this is all hobbled by dire core class implementations. I had to look at them several times recently and it is NUTS. In the day and age of nearly all CPUs having instruction sets for accelerated big integer processing (ffs, 8087 had that when it initially came out), the big numbers have no offload to JNI on supported platforms. Network functions like getnameinfo, etc are ifdefed and while present in the source remain unused and bogus obsolete analogues from the gehostby_* family are used instead - you name it. In fact, once again, my hat is off to the JVM bytecode interpreter and JIT developers, it is only because of their stellar work we do not notice how bad the core libs really are.
But the JVM really needs a new flagship language and Oracle isn't the company to make it happen.
I agree that Java's syntax shows its age, but I wouldn't expect it to be superseded soon, and not because of Oracle. The alternative JVM languages all offer syntactical features that purport to make development quicker, or perhaps safer. Even accepting that these features are as magic as their enthusiasts believe, they can't deliver enough of an improvement to justify a switch. Things like language syntax are very important when you first start to learn a language, and they can make that process pleasant or nasty. But for experienced users the differences between any fairly up-to-date languages are not enough to affect the development process much.
Both DPD and the Royal Mail (and probably more, these are the two we use) require Java in the browser for sending stuff to lavel printers and automatically add consignments into their system, and it's a royal pain in the arse to maintain. Unfortunately, can't see a replacement coming any time soon.
Having got rid of Flash a long time ago, I only keep Java around on my macs because, annoyingly and oddly, Adobe Illustrator won't launch without Java installed*. Weirdly the rest of the Adobe suite are fine without it.
[*Actually, that's not strictly true. You can launch the Illustrator binary with: "/Applications/Adobe\ Illustrator\ CS6/Adobe\ Illustrator.app/Contents/MacOS/Adobe\ Illustrator" in a terminal and the app runs fine. But that soon gets tiresome].
Was the workarounds that were performed to get around the failings of the JVM. These became so well known and thanks to the GoF were implemented in every language whether they needed them or not.
Factory pattern,
Singleton pattern,
Facade, etc etc etc.
If you know the language that you writing in, and understand why the patterns came about it's pretty obvious that you don't need them.
What the hell?
Patterns like factories, singletons etc. exist to solve problems not tied to any one language. e.g. I might use a singleton because I only want one of something such as Logger to exist in my program and therefore I control access to it to prevent more than one from being created. It wouldn't matter if I was writing JS, Java, Ruby, Python, Perl, C, C++ or anything else - the manner I create a singleton might change but the pattern is the same.
If you think you "don't need them" then it says more about lack of programming knowledge than anything else.
Upvoted (what's with the OP attributing Pattern necessity to the JVM???), but let's not jump to conclusions too quickly.
Language does matter. If you can, say return function pointers, then you may find whole categories of problems for which Strategy is overkill. Factories? Great, when needed.
Design Patterns holds a special place in my esteem. Reading GoF's book was the first time I truly got how OOP was supposed to work. Most of the other books I had read either started getting lost in deep OO theory without clear rationale for their approach or else immediately fixated on explaining inheritance one more time. First book that clearly got me to think in terms of composition instead.
But, and I believe it might even have been said in that book, do not implement a Pattern lightly. Well-done, it solves a problem. Done willy-nilly, just because everything looks like a nail complicated to your mighty hammer Patterns, it creates horribly messy and convoluted code.
Did some debugging on a failing enterprise SOA-style expense processing system. 1 expense report, with 1 expense line in it => 20 MB trace, 500+ function calls, dozens upon dozens of objects being instantiated. And many, many, Patterns of all stripes, factories foremost. Impossible to track what was going on. (I never did figure it out but ending up diff-ing a successful run log with a failed run log and caught the issue - failing external API call - that way instead).
It wasn't in Java, but OMG did it have Enterprise Java Programmer Here written all over it!
Code composition, which is a lot of what Patterns are about, is an extremely powerful technique. But there is a tension between very clever dynamic code and easily readable code. Stupid fixed procedural code may be dumb, but it can also be easier to read.
Read this guy's "hacker code" vs. "clever code" for example. Wasn't meant to be ironic. If you need the complexity, fine. If you don't, please think twice before reaching for that hammer. Maybe think it through with a unit test instead.
http://csis.pace.edu/~bergin/patterns/ppoop.html
Personally, my main beef with Java is not so much the language itself, as the perception that its culture is not one that values simplicity.
The workarounds for Java's many failings largely seem to involve reflection hackery or delegating to someone else's hackery in a lib.
Patterns are something else, any Java connection accidental. 'Patterns' are useful as documentation and shared naming of techniques and philosophy, describing things that previously had a myriad of different names (if named at all) with few programmers knowing more than a few of them - mostly invented on demand rather than learned.
But I agree that languages now being capable of directly representing them is a mixed blessing ;)
I waited for the comments to come in after this article arrived. On my score card I got points for "language is verbose", "Desktop sucks" and "Java security is terrible". I'm quite surprised not to have got "It runs too slow" and "the VM is too big".
Despite all the revisionist history, Java got in there because it solved a whole bunch of problems that no other platform quite managed. For a start, outside of Delphi, it was just about the only 'platform' that you could get hold of. Sure you could mix up a nightmare brew of C, x-windows, sql libraries and so on, but that was so painfully vendor dependent that each and every project required a fresh start. In contrast, you could knock up a Java app with a gui that talked to the network, database and file system of your choice and not have to re-build it every time you needed to run it on a different machine or for a different client. The browser integration promised (but never delivered) that those apps would eventually be able to be delivered automagically by the internet, but even without it, software houses could deliver tools and demos and apps far more easily than they had before.
Things like the standard runtime libraries, easy dependency injection, automatic documentation generation and very consistent approach to API behaviour meant that picking up Java to do a job was an order of magnitude easier than the equivalent in just about any other language at the time. That's nothing to do with CS students or managers' preference - it was a handy tool that also happened to scratch the itch that most developers have to learn something new (which has since benefited Ruby, Python, Scala et. al.).
The Java guys have never really got UI development, and that pretty much killed off browser integration and desktop apps, despite repeated attempts like JavaFX. It's funny therefore to see Android use Java for a UI-heavy platform. (it's also probably worth mentioning that Minecraft seems to have done fairly well for a little game written in Java). Meanwhile, web development and now big data have absolutely thrived on the ability of Java to evolve into new areas.
Whilst Scala has been an interesting diversion, the small size and relatively limited resources of the development team have been a constraining factor - resulting in painfully slow tools and weirdly inconsistent core libraries. With Java 8 making useful inroads to functional styles, and the solidity of things like the collection classes, I'm not sure that the 'other JVM language' will ever get out of it's niche.
So - thank you Java. I still remember evaluating it for an early project (and having to wait for it to be delivered by post on a CD) and twenty years later, it's still relevant to my clients and still evolving into new areas. It's far from perfect, but it does a lot of jobs pretty well. Long may it continue.
Java got in there because it solved a whole bunch of problems that no other platform quite managed
...and created a whole bunch of problems that that no other platform quite managed either.
But I and the rest of the internet are glad you did so well in your score card points.
I'd like to see a real world adoption graph as I'm betting minecraft spike it up, and doesn't anyone else find it odd microsoft buying minecraft and paying licensing to Oracle for Java? There's always advice that there is no need to run Java and it's insecure which always neglects to mention the wee ones factor, but then that also goes for not using flash plugins, yet youtube works without flash it doesn't do basic things like annotation, subtitling or even whether one has watched a video or being able to change devices and resume playing at the same point. Security is one thing, practicality another.
You know the install screen for Java on windows that tells you that it's used in everything from ICBMs to pet rocks?
Does anyone else remember when it used to state that Java was used in kettles and toasters? I *know* I saw it there, but no-one else seems to have any idea what the hell I'm talking about...
As dedicated Reg readers know, Java is in at least one toaster.
Finding a Java-enabled kettle is left as an exercise for the reader. Or, hell, just implement one yourself. (I could wire an old Java-equipped feature phone into an electric kettle in about an hour, I'd guess, and have it, I dunno, turn itself on if it hears someone walking around the kitchen? Hard to think of a useful application.)
Today Java is among the world’s most popular programming languages, ranking second after JavaScript
Second by what metric? Recent years have seen a boom in rich web pages and SPAs, and Node.js means server-side JavaScript is increasingly important. But I'd be astonished to learn that there's more JavaScript code in use, or that more development effort is going on in JavaScript. Or are they counting the number of CPUs JavaScript runs on?
To be fair to the article it linked to the source of the ranking.
"most popular programming language" is one of the many willy-waving contests on the interwebs. There's still a fuck of a lot of FORTRAN and COBOL and others out there that almost certainly doesn't get picked up on.
There's still a fuck of a lot of FORTRAN and COBOL and others out there that almost certainly doesn't get picked up on.
Yup. Every time RedMonk or someone else publishes these studies, people point that out in the comments. But to be fair, RM do note some of the major limitations of their methodology, and caution against misinterpreting the results, in the introduction.
And, yes, there's still quite a lot of active Fortran1 and COBOL development. We sell a lot of COBOL development tools. But businesses don't host their back-office apps on Github, and there isn't much of a COBOL community on Stackoverflow.
1And probably some FORTRAN, but it's been a quarter-century since the language was renamed, and by now most people have likely caught up.
The metric is a combination of number of topic tags on Stackoverflow and number of lines of code in projects on Github (although the axis label simply says number of projects). The top 4 languages by this measure are Javascript, Java, PHP, and Python. Overall, it looks to be fairly web development heavy which probably reflects the user base of Stackoverflow and Github.
I don't see a link to their raw data, but judging from the graph Javascript is ahead on amount of code written, while Java is ahead of number of people asking for help with it. The result is nearly a tie with Javascript only slightly ahead of Java in the combined total.
You can argue with the measurement, and there are others out there (e.g. Tiobe) which give somewhat different rankings. The thing to take away from it though is that it provides some backing for the statement that Java is one of the most widely used languages, and that's what really matters for the purposes of the story.
On the other hand, if someone tries to convince you that F# is hugely popular and you're missing the boat if you don't switch to it now, you can look at the chart and see that it's down in ColdFusion territory. That's not to cast aspersions on either ColdFusion or F# fans, but it's a rather useful reality check to the hyperbole you get from some language fans. .
The first main point about Java was that it was platform independent... by simply coming with its own platform. This allowed you to distribute binary software which could, so the idea, run on any system. However today we have POSIX. You no longer need to port software you can just re-compile it. So it's trivial to just publish your software in source code. And if you want to have unfree software, you can always have web-services.
The second problem with Java is that it fell into the complexity trap. Java, like C++ and similar languages seem to make it easy to write complex software. Now most problems in IT are very trivial, the core of the operation of most companies could just as well be managed by punchcard collators or very simple computer programs, often not even needing an SQL database. However since it seems so easy to write complex software people don't bother having a nice and simple design first. The result often are brittle and inflexible systems.
Your post is, excepting that JAVA's cross-compatibility is a factor in its success, start to end nonsense.
I'll just do the highlights and that alone will take me ten minutes.
>>However today we have POSIX.
POSIX has been around since the late nineties. In fact, the main parts of it were around in the Eighties! First public release of Java was around the same time as the formalization of POSIX. POSIX has been available throughout all the time that Java was establishing itself.
But that's a minor detail in comparison to your suggestion that POSIX obviates the need for Java. POSIX is limited standard focused solely around the UNIX model and very limited in scope. It's never even been revised to deal with Object Orientation which it just pretends doesn't exist. It would be quicker to list the things it does cover than all the things it doesn't. The most modern thing it attempts is a well-intentioned [b]attempt[/b] at ACLs. Which are ignored by most GNU/Linux distributions. And that's another thing. Aside from only being good for writing programs that move a few files around, it's not even fully implemented on all major GNU/Linux distributions! Heck, [b]systemd[/b] isn't even POSIX-compliant and that's everywhere! And I haven't even started on Windows yet! If, and let me emphasize the IF, you install Cygwin on Windows you get the limited capabilities of POSIX on Windows (at a snail's pace and unable to use most of the Windows OS). POSIX is just a set of UNIX standards not even fully adhered to in the GNU/Linux world and you are offering it up as a cross-platform alternative to Java? They're not even the same type of thing. Tell me how I compile a C++ program on GNU/Linux and run it on Windows 7 using "POSIX". Your argument doesn't make any sense.
>>You no longer need to port software you can just re-compile it. So it's trivial to just publish your software in source code.
Well that's just great. Because 99% of the computer users you want to run your program are just great at downloading a C++ compiler appropriate for their platform and then assembling it into executable code and setting that executable up as installed along with any library dependencies, resolving version issues, etc. And you're aware that Security is a thing these days? That with the JVM you can actually handle permissions in a sensible way. Exactly how safe do you think sending people source code to compile would be?
>>Java, like C++ and similar languages seem to make it easy to write complex software
ROFL! No-one has ever, ever sat in front of a C++ compiler and thought, "Oh! Writing complex software is easy now!" Not for more than two minutes, anyway. And I speak as a former C++ programmer who regards the language as very impressive. I mean, Visual Basic might fool (until they get into the second week and realise they've just created a huge unworking mess), but C++? No. And the same for Java.
>>Now most problems in IT are very trivial
Please, you're hurting me.
>>the core of the operation of most companies could just as well be managed by punchcard collators or very simple computer programs, often not even needing an SQL database
I would love to know what you do for a living. Have you ever even seen the inside of an office?
>>"However since it seems so easy to write complex software people don't bother having a nice and simple design first. The result often are brittle and inflexible systems."
Sometimes someone's post is wrong simply in the odd factual detail. Sometimes someone's post is biased and slants facts or omits inconvenient ones. But your post is so lacking in familiarity with the subject matter it is beyond correction, it should just be dismissed wholesale as meaningless.
As usual, the moment a Java article appears on here it is met by a whole slew of ill-informed negative comments So, in spite of the inevitable downvotes I'm going to try and address some of the most commonly expressed opinions. And this is from working for over 15 years as a Java developer and consultant.
1) It's insecure! All you get are constant security problems!
This is true for Java browser plugins. I have Java disabled in my brrowser and my activities are not the least bit affected by it on the web. Over 90% of Java use is on the server side where security is straightforward if you know what you're doing.
2) Java isn't really cross platform!
Yes it is. In 15 years I have never seen or heard of an instance of it not working like this in the course of my work. Of course if you start going off-piste and using niche parts of it like the Java Native Interface that allow you to call non Java, OS specific stuff you may welll get burnt, but generally installation of applications requires nothing more than copying a single file into a directory, then editing a few environment specific prioperties in a text file. Having done C++ work for many years on different platforms, Java is much, much easier and wonderfully free of gotchas as long as you don't try and get too clever with it.
3) Java is verbose!
This is true. And for corporate applications shuffling lots of business data about this is a good thing, as it is very readable. That might make it this century's COBOL, but when it comes to debugging / making changes I'd rather have this than someone's clever, ultra-concise C++ (especially at 1 a.m. in the morning when I'm on call and have to fix a problem)
4) Language xyz is better!
Maybe it is, but pretty much every banking or other major e-commerce site you visit runs on Java. You just don't see that from your browser. This is good because it means I can earn a nice living.
Honestly, Java appllets and client side stuff are such a minor percentage of commercial use that it's really not worth getting your knickers in a twist over them. And modern AJAX frameworks enable rich client functionality to be done easily in the browser these days, so there's little excuse for writing client side Java stuff these days anyway. I kinda feel the same way about most Android stuff written in Java too - a lot of it could be done in the browser, rather than every company feeling that it has to write individual apps for everything, as having so much software to install and manage / update is what Enterprise Java solved in the first place (C++ apps like games are a different thing entirely).
5) It's slow!
No it isn't. It's super fast these days.
Anyway, let the downvoting begin, I'll just keep happily earning a good living from Java for the rest of my career.
Nasdaq super fast stock exchange system Inet (wall street) with sub 100 micro second latency and enormous throughput is written in java. The trick for high performance is to handle memory yourself-> shut down garbage collector. In fact, several super fast stock exchanges are written in java. Or C/c++.
1) It's insecure! All you get are constant security problems!
This is true for Java browser plugins. I have Java disabled in my brrowser and my activities are not the least bit affected by it on the web. Over 90% of Java use is on the server side where security is straightforward if you know what you're doing.
I use Java myself (primarily for research, not work), and I sometimes work on Java products, and I think on the whole it's a decent language. But your statement here is simply not correct. Many of the serious Java security issues of the past several years - in particular, a number of those found by Adam Gowdiak - are in the JVM or core libraries.
They are just as relevant to back-end Java applications, and there are reasonable threat models under which they represent significant security issues. For example, they can be used by an unprivileged developer who can deploy code to the sandbox to elevate and subvert privileged applications.
Those flaws are mostly or entirely due to security-violating mechanisms added to the sandbox for "performance" reasons and inadequately protected against reflection and similar channels. The problem with Java security is the original model has been subverted in the name of features and performance, and Oracle (and to some extent Sun before them) did a poor job of understanding the ramifications of their stovepiping.
Claiming that Java's security problems are solely in browser contexts is dangerously wrong and does the language no favors.
Java started making a big comeback when Google chose to use it as the programming language of choice for Android apps. The best move Oracle ever made was to sue the guys who had rescued their* language from the doldrums </sarcasm>
* Sun's really, but eh, buying something is the same as making it yourself, right? No, I'm not an Oracle fan, why do you ask?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
