
We're writing in Java 6 with a lot of stuff still in Java 5. It's going to be a while before we get to use any of those new features.
Two years later than planned, Oracle has made Java ready for a multi-core processor world. The database giant has announced general availability of Java 8, calling it a “major new release”. Java 8 is important because it’s the base spec for Java Enterprise Edition, as well as feeding the free and open-source implementation of …
@Destroy All Monsters: In the real world, Mr Monsters, adoption of a new version of a development platform is constrained by the necessity to regression-test what is often a large body of code, and to maintain compatibility with existing libraries and infrastructure. Developer ignorance is rarely a factor. If it was left to developers, most coding would be done on the bleeding edge.
Carrying out a regression test like this is fine if your application is fairly small.
Do this to a massive amount of developers, who could be spread about the globe, then you will need to spend a not insignificant amount of time not only preparing the regression tests but also making changes (if needed) to the unit/FIT test(s) as well.
I don't think anyone would deny that setting up and executing a regression testing system is expensive in time and money. However, it would be hard to think of a better example of Philip Crosby's famous dictum that quality is free - but only to those who invest heavily in it. In other words, quality costs money but saves so much that in the long (or even medium) term you end up better off. Not to mention your customers, and everyone else who benefits from software that works properly and is reliable and secure.
Let me tell you something about the real world.
In the real world programmers who can't move to languages versions that are supported by the companies that released them are the single biggest security threat to the network, the integrity of the business, and possibly the future of the company. With 51 versions of Java 7 behind us, you lot are a bigger problem than IE6 and the coming implosion of Windows XP are.
I work at the user support coal face. Programmers like you who excuse the leads, managers, and CxOs who won't properly support the porting and testing of applications are my single biggest PITA. If I had my druthers, the CIO who hasn't at least moved you off version 5 would be taken to the front of the building and hung until dead while the staff watched. If that didn't motivate people the following month it would be the CEO and whoever reported to the former CIO. And I keep working through the chain until somebody got the message.
seems Oracle's developers need it too..
Installing Oracle 11.2.0.4 on Linux right now and the installer is using Java 1.5.0_51
For something as trivial as a software installer I would of think it would be more up to date..but I am not an Oracle expert I'm sure it's par for the course.
Looks like Java 5 saw it's last public update at least in October 2009.
http://www.webupd8.org/2012/01/install-oracle-java-jdk-7-in-ubuntu-via.html
Works fine in Mint 16, I already have Java 8 and NetBeans 8 (off netbeans site) installed; the proper ones, not the _very_ dated lame junk one the Mint repositories.
If that doesn't work, try this:
http://community.linuxmint.com/tutorial/view/1372
Installing Oracle 11.2.0.4 on Linux right now and the installer is using Java 1.5.0_51
Oracle are pretty awful about updating their own stuff, although if it's only the installer itself using an old version of Java then that's not so bad. If it's *installing* a 1.5 JRE then that's not good - even when Oracle 11 was first released Java 1.6 had been out for ages.
It's not our decision what we program in ninety nine times out of a hundred. There's all sorts of policies and guidelines that have to be followed. As much as we'd like to be programming in more recent versions, it takes time to change our development environments. Especially when the managers have to decide do we spend the money on updating our Java 5 programs to Java 6, setting things up for Java 7 or do we focus on getting all our VB apps rewritten in something that will run on Windows 7 before XP is put down.
"...do we focus on getting all our VB apps rewritten in something that will run on Windows 7 before XP is put down".
It's been a while since I saw a stronger argument for keeping Microsoft out of enterprise software. What kind of supplier makes huge efforts for many years to get developers hooked on a language like VB, only to stop maintaining it and leave them high and dry? Note that the developers have no option, as Microsoft is forcing them to migrate from Windows XP.
I think you'll find real enterprise suppliers like IBM never put customers in such a position. Apart from anything else, it's a loud and clear invitation to quit the Windows platform altogether, and move to something that permits smoother change and greater continuity.
We're writing in Java 6 with a lot of stuff still in Java 5.
Do you mean you're still deploying on Java 5 and 6 runtimes (both of which are no longer supported)? If so, why? Haven't had any issues moving three massive systems to Java 7 - no code changes necessary, and the new features such as "try with resources" are great.
I work for a bank.. We're still using Java 5 and 6 mostly with some brand new bleeding edge code being deployed with Java 7... but that's not standard and not properly approved... Our server builds are all Java 6 by default. But hey, we also still have lots of Windows XP around too. I don't think we'll see any Java 8 until 2020 at least.
"I don't think we'll see any Java 8 until 2020 at least".
By which time it will be obsolescent and, no doubt, insecure. I can well appreciate that it's hard to keep abreast of software versions when you have a huge infrastructure to maintain, but surely a higher priority could be given to keeping up to date? After all, what is the point of software developers working hard to fix problems if their customers aren't going to enjoy the benefits?
It wasn't so bad when our networks weren't all connected to the internet. You could have the known insecure software installed as long as you had decent AV scanning your floppies for the bad stuff and still be reasonably secure. That's not true anymore. Java is even worse. Sure it's secure so long as you aren't running it in a browser. But really, when was the last time that cutting edge app wasn't running in a browser? Or even the kludgey old one that takes forever for the CCB to approve and then QA to test after the coders are done with their bit?
It's tough being in IT at any level without the resources and management backing to do things right. I get that. Problem is, the world has changed around us. We can't get by with slipshod practices anymore. All the best hackers are banging right on the enterprise door and some of them have government sized resources behind them.
Well, yeah. Anonymous delegates.
Provide Oracle don't allow chaining they could actually be a step up on C# for a change. This comment will be downvoted by everyone who hasn't spent ten minutes with a headache trying to figure out exactly what a 2-line chain of lambdas actually does.
Lambdas are also damned useful in fluent APIs, where you can't stop to set properties without breaking the chain. Fair enough they are ripe for abuse (what isn't?) but used well they can create beauty too.
I'm just wondering if they'll be done in as half-arsed a manner as generics were.
It's a Gavin Clarke article. Anything technical can be read as "they wave the magic wand and unicorns appear".
Yes, lambda expressions have many uses besides parallel code, and indeed have occasionally been used on single-core systems - for example in every nontrivial program written in LISP or any other functional language1 that's run on a single-core platform.
And Herb Sutter's 2005 piece isn't about "rewriting multi-threaded applications for multicore". It's about rewriting single-threaded applications to be multi-threaded. He talks a bit about explicit parallelization, but it's mostly about threading.
Oracle seems to be pitching Java 8's lambda expressions as a syntactically-simpler alternative to anonymous inner classes, because they're trying to hop on the C# LINQ bandwagon. They know a lot of developers are afraid of functional programming but OK with result-set filtering and attracted by promises of parallel execution (even when crap algorithms or implementation means overall performance is terrible).
1Except Unlambda, of course.
> It's a Gavin Clarke article. Anything technical can be read as "they wave the magic wand and unicorns appear".
It's not just me who finds it weird that the Reg's software guy - see contacts list - apparently understands less about software than your average government minister, then? That's a relief.
In what magical wonderland has Twitter’s vice president of infrastructure operations engineering come to THAT conclusion?!
Java's performance is abyssmal, as is it's scalability. If performance truly was their goal, C++ or any other fully compiled language would've outperformed Java by miles, while remaining just as, if not more scalable.
So says someone who either hasn't used Java since 2000, or hasn't updated their learning since then. Java's performance is not matter for subjective opinion, it can be measured directly.
Java is not as fast as C++ for bare algorithm implementation comparison. But it is NOT "miles slower" and the difference in speed between Java and Ruby is far greater than the difference between C++ and Java.
I speak not just as a programmer, but one with experience in the world of competitive coding contests where you are given a limited time for your code to process input data and return a result, where language performance is a big deal. Rather than quoting middle-management "I read Java was slow because it's interpreted" levels of misinformation.
You choose a programming language based on multiple criteria, including, performance of resulting code, ease of writing code, IDE support, libraries etc.
A language being the latest fad is not the reason to choose it.
You can read a bit more on Twitter's decision to switch to Java at the back end blog.twitter.com/2011/twitter-search-now-3x-faster
No shit?? Why bother trying to compare the speed of C++ to Java?
Of course Java is going to be slower, C++ is compiled to machine code for the CPU it's running under.. not byte-code ran in a VM that's different to the host CPU!
Compare it to other languages of it's class, like C#, if you want to willy wave over speed - not something that has an obvious advantage.
Whenever there's a mention of some language, there's always those types that whine that whatever language they know is the best.
A free programming lesson for you: Nearly all languages are different. They all have different trade-offs. Pick the one that meets your criteria. If you only know one, then stop comparing known with unknown.
PS; I still think Java is crappy :P
because you're a C++ programmer.
That's not intuitive, that's familiar.
Intuitive isn't what they were going for with C++. I think they were aiming for "ooh, doesn't it look computery and clever" with a side order of "This'll put off the plebs...."
Come back when you understand how modern JVMs work. Wikipedia hint: JIT
ok, I'm back. Did not realise they JITted. I need to get my head out of my fucked-by-Microsoft arse.
So, Java is compiled on the client machine, able to optimise specifically to the host CPU.. unlike C/C++ that has to work on the lowest common denominator. I take back what I said about it ;)
But I might give Java another try, now.
> So, Java is compiled on the client machine, able to optimise specifically to the host CPU..
Near enough but it has to do it quickly and may skip a fair few optimizations that a multipass compiler can do.
> unlike C/C++ that has to work on the lowest common denominator. I take back what I said about it ;)
Not on my machines at the very least. You're thinking of closed source things that have to be backward compatible or *nix distros that want to do the same.
My CFLAGS environment variable on my machines include "-march=native". On the laptop I am typing this means optimize for Haswell G4. I'll bet your system isn't compiled to that degree of ridiculously modern!
So, it is not a failing of C/C++ but merely how the output is intended to be used. MS could release a version of Windows which will only run on the very latest CPU.
Now it's also not that simple either.
You can include multiple code paths that depend on the CPU flags available. Your binary will get commensurately bigger though but it will run on your lowest supported CPU but take advantage of newer stuff.
Put 50 milllion odd records in an Elastic Search database and then see whether Java is slow 8) Try it - its free. Or try out MongoDB (can't remember if that one is Java - think so). While you are at it run up Log Stash and Graylog2. A mass of Java and bloody fast. I ran that lot on my desktop PC for a demo for a few weeks (quad core old Intel processor, 8GB RAM, one SATA disc (with some SMART failings)) with Postgres, MariaDB, Apache, and a Jasper Reporting set up in the background whilst I crack on with work on KDE in rather nice 3D accelerated desktop across multiple monitors.
Whoever above mentioned the installer needing an old JVM may like to notice that it can be installed in a CLI from a .tar.gz or .zip or whatever.
Cheers
Jon
There is more to it than that. Current JVM-s are not just JIT compilers, they are JIT optimizers. They instrument your code at run time to determine what is worth aggressively optimizing, that is what parts of the code are used the most ... this is why it's called "Hotspot". But it goes further than that. A compile time optimizer can only perform a change when it is 100% sure that the semantics are the same in all possible cases. A run time optimizer can make "illegal" changes based on actual usage and undo the change if needed. The most important use of this is with inlining. According to the language semantics (this applies both to Java and C++) a method call cannot normally be inlined, because at run time a class may be loaded which overrides the method (and this should now be called instead of the inlined code). Hotspot happily does the inlining and if the described case arises, it undoes it. In my experience with compilers and optimization, inlining (and for some languages, tail-recursion optimization) are by far the most effective optimizations followed by moving invariants out of loops.
Another point is that it is irrelevant that not all of the code is optimized or even compiled. The execution time of the hotspots completely dominates the total execution time. What is compiled/optimized by Hotspot depends on JVM parameters. In fact there is a client version and a server version. They differ mostly in how much time Hotspot spend observing the code before deciding to optimize. Shorter for the client version for fast startup, but a bit less efficient code and longer for the server version with a reversed trade off.
Near enough but it has to do it quickly and may skip a fair few optimizations that a multipass compiler can do.
Yes, fair enough. 5 minutes on a 'release' build is ok, but not at application start-up.
You're thinking of closed source things
Yes. For now, I'm a Windows developer.
>>Come back when you understand how modern JVMs work. Wikipedia hint: JIT
To be fair, it's still not as fast as C++. The JIT evangelists claim JIT should mean Java/C# runs as fast as C++ or even faster (since it can compile for the exact CPU you're using) but I have never seen this in real life. What I have seen is that the difference in speed is not a big deal. Maybe a factor of 2 rather than a factor of 10, for doing heavy computation in a tight loop.
To be fair, it's still not as fast as C++. The JIT evangelists claim JIT should mean Java/C# runs as fast as C++ or even faster
It doesn't matter if C++ is faster than Java. For what it lacks in speed, it gains in development and maintenance cost, and platform compatibility (post-compile).
Most of the time, the speed isn't a problem. For few times when it does.. C++ can be used for those specific costly algorithms.
The very fact that people are now comparing Java to C++ in terms of speed is itself a compliment to Java.
I think Java has gained a lot of bad press and stigma regarding performance, especially in the early years when compiled languages ruled. Unfortunately, people (like myself) still think today's Java is like 90's Java (and Microsoft's implementation).
I think Java has gained a lot of bad press and stigma regarding performance, especially in the early years
Some of that stigma was deserved in the early days, since assumptions had been made in the design and implementation of Java that turned out to be incorrect and there wasn't yet the experience to know how to code in Java most effectively. Much of this has been sorted out, a simple example being the revised Collections classes that no longer synchronise every method call in the most commonly used classes. The JVM has also evolved to be a technical wonder, and the garbage collection has been reworked to provide optimal performance in most real world scenarios.
"It doesn't matter if C++ is faster than Java. For what it lacks in speed, it gains in development and maintenance cost, and platform compatibility (post-compile)."
Well it makes a little difference if you are doing things like real-time networks and signal analysis although variability is also a big factor here(a.k.a Garbage collectors)
But i generally agree it's horses for courses. Use the different languages where they make sense and join them together. There is the standard maxim in programming -Get it working then get it working faster
"I think Java has gained a lot of bad press and stigma regarding performance, especially in the early years when compiled languages ruled".
This is extremely ironic to those of us who remember the early days of compiled languages. "They'll never generate code that runs a fraction as fast as my hand-optimized assembler," went up the cry. Within five years, the compilers were leaving even the most lovingly crafted assembler in the dust.
Computing: it's what computers are for, you know.
Computing: it's what computers are for, you know.
Indeed.
There is no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself. (Alan Turing)
I am often reminded of this prescient remark. You'd think it would be obvious to anyone who had ever programmed a computer; but sad experience shows otherwise.
I think that C++ is more intuitive to write and easier to debug
You're either trolling or need some heavy medication. The number of books on the gotchas of C++ (the "Effective ..." and "Exceptional ..." ones for example) are an indicator of how unintuitive C++ is. As for debugging, ever tried to debug C++ template code?
The experts here who know how slow Java is are missing a huge opportunity. I bet all the financial institutions that run high-frequency trading applications written in Java would love to hear how they can boost performance by rewriting in a faster language.
And for those arguing about the syntactical merits of this language or another - that's not really the issue. An intelligent developer can get up to speed with any modern language. The great advantage Java has is its massive body of open-source libraries, and the vast ecosystem of Java programming knowledge that is available.
Get real!
Peter Van Der Linden was saying Java's performance was miles better back in 1999! FFS! It fair screams along these days and is easily the match of almost any compiled language. Granted it was shit when we were using for applets ( remember coding those anyone? ) back on basic Pentium boxes around '96.
Can't see that Google would base their entire mobile O/S on a poorly performing language where there are limited resources and almost every CPU cycle counts!
Any decent (not over engineered!) java program will run at about 1 and a half times the speed of the equivalent C++ program.
The difference is the Java will be debugged and in production while the C++ programmer is still trying to sort out his memory leak in between arguing with his colleagues over what Soustrup really meant to say in chapter 13.
"Java's performance is abyssmal, as is it's scalability".
You see, that's a drawback of posting as AC. No one has any idea where you come from, or what your motives are. Your statement is factually untrue, yet it is couched in very decided and forceful language. Why are you so keen to talk Java down? Are you an M$ shill, or just someone who tried Java without sufficient study and preparation?
Without any of that information, we are (alas) likely to draw the worst conclusions.
By the way, there is only one "s" in "abysmal". And Lynne Truss will be calling on you to explain the proper use of apostrophes. I often wonder about the implications for a person's ability to design and write complex code, when they can't even manage the relatively simple task of writing plain English.
"Without any of that information, we are (alas) likely to draw the worst conclusions."
Specious bollocks. You're just guaranteed to use it as an excuse to dismiss anything you don't like.
"By the way, there is only one "s" in "abysmal". And Lynne Truss will be calling on you to explain the proper use of apostrophes. I often wonder about the implications for a person's ability to design and write complex code, when they can't even manage the relatively simple task of writing plain English."
I wonder too, but realise using it as an attempt to discredit someone is even more feeble than the AC bullshit you're pulling.
Different AC, but then you won't want to believe that, will you?
"It's daft to call someone a MS shill for talking down Java, when the exact same ignorant arguments can be levelled at .NET (slow, interpreted, etc)".
Your remarks are not logical. The AC whom I criticized had attacked Java, not .NET. The fact that .NET is, arguably, open to a similar attack has nothing to with it.
If I were to criticize you for being illogical, my comments would not be proved invalid if someone were to show that I, too, was sometimes illogical.
It is illogical to attack a product which competes against your own with arguments which can equally well be levelled at your product by the type of uneducated person who just hears something on the web and parrots it. It increases 'awareness' of criticisms generally. It's not in MS' interest to have people talking about "how interpreted languages are slow".
> Are you an M$ shill
That's against the House Rules, be careful.
Also logically unlikely. MS have a lot invested in JIT-based technology and don't especially pimp their C++ compiler (except, bizarrely, where it's Managed C++ and therefore using JIT anyway).
The "lolz me so superior me no use M$" thing may give you an erection but it's not helping your rational thought much.
NASDAQ's largest stock exchange system called INET, and their largest derivative system called Genium INET are both completely or partly written in Java. Now I am talking about the crucial matching engine which handles all incoming orders. The matching engine needs to be extremely fast, as there are lot of High Frequency Traders capitalizing on speed. The worlds fastest and largest stock exchange systems, are written in Java or C++. NASDAQ claim to have the fastest exchange system in the world, and with greatest capacity with latency downwards 100 microseconds or faster, and throughput of millions of orders. As both systems are written in Java, the secret sauce is to avoid trigger the garbage collector. This is done by preallocating all objects and reuse them, so they will never be garbage collected. With garbage collection out of the way, you can reach extreme performance, suitable to the fastest and largest systems in the world, juggling billions of USD every minute.
So, no, Java is not slow. Exchanges rely on speed, that is how they attract customers. Slow exchanges are not interesting for HFT firms. If the exchanges could rewrite their systems from Java to C++ for faster performance, they would. But they dont. And also, the fastest HFT firms are sometimes using Java in their most critical parts. Others use C++.
Luckily Java has had multi-threaded development capability since day 1, and this isn't the first time it has been made easier to use - the Java Concurrent frameworks are now very old, for example.
What the lambda expressions actually do is allow the programmer to express, concisely (a big problem with Java, previously you would have had a bulky inner class implementing a functional interface) a more functional model of programming that so happens to also make it easily multi-threaded.
Stop right there.
C# does have anonymous functions but those are a different beast (although you can invoke them with lamdas). Lamdas provide support for anonymous delegation.
No, lamdas do not provide automatic multithreading (and I would bet good money that they won't in Java either) but the syntax does make it simple to delegate to another thread.
Fewer!
Stylistically, that would be my preference as well, albeit only due to familiarity; but insisting on the distinction is suspect pedantry. Even prescriptivists have a hard time justifying this particular shibboleth. "Less" applied to countable objects has a long pedigree, and though there is considerable and apparently growing affection for preferring "fewer" for discrete quantities, the former usage is still well-represented. The AUE FAQ has more.
In any case, by far the better change would be to eliminate the redundant and awkward phrase "lines of". Better yet, rephrase the entire clause, and quite possibly the entire sentence it comes from.
Nobody said it didn't support threads. But you had to create and run the threads yourself, make sure they don't fight over the same data dangerously, etc... this is the traditional model of multi-threading very similar to using threading in MFC/Win32. More modern approaches mean parallel logic can be automatically split off to threads without you having to do it, in a similar idea to how Java doesn't make you have to manage memory, but does it for you.
As a non-English speaker I'd welcome it if someone could point me at a plausible differentiator between "use" and "utilize". As far as I'm concerned, it's just used/utilised (I like UK English, hence "s") to make things sound more managerial in places where "use" would do just as well.
Not a grammar nazi, just genuinely curious. I have as yet not been able to figure this one out..
Sorry, "administrate" is simply WRONG. Administrators *administer* things, IT system or not.
Anyone who uses it looks ignorant as hell, frankly.
As to "utilise", yup, 9 times out of 10, it's just management-wank-speak. I don't actually think I've seen it used accurately in an IT brief.
"Utilise" can also mean that you use something for a purpose it's not specifically designed for - you can use a screwdriver to turn a screw, or you can utilise a kitchen knife. Same concept as the "making useful" meaning described above.
'and why "administrate" over "administer" ?'
"Administrate" is a verbal outrage, for which there is no excuse. Although some people tend to write and speak badly, we should never accept it passively. Language is everyone's common possession, and when badly used it smothers and hinders everything we do together.
The mechanism by which such words arise is psychologically simple enough. From "administer" we produce the noun "administration". Then someone ignorant hears that, and produces the back-formation "administrate". Similarly, people have commented on things for centuries. Then a new job appeared: commenting on sports events. Because "commenter" sounds a bit clumsy, these people were called "commentators". And that led to the erroneous back-formation "commentate".
I am not a grammar nazi or an English teacher, but have been told I write well. So as a practical matter, I prefer "use" to talk about a transitional relationship - i.e., "I used the shovel for 5 minutes to dig a hole." I would prefer "utilise" to say that something is more permanently incorporated in a function, i.e., "this new car utilises a huge V8 to get 600hp and fantastic acceleration". It is clear that the car is going to have that V8 under the hood for quite some time. Or, you could more topically say that "this class utilises this subclass to provide transparent multi-threading". Unless you re-write the class, it will always have that utilisation.
Not saying that in practical conversation you can't say "this class uses this subclass". It works, they are synonyms. But I like to differentiate, and I have seen similar uses from other authors.
Just don't get me started on "utilise versus utilize". Please.
Of course, a dictionary is still a useful resource. I like the Oxford English Dictionary, which focuses on British English but usually notes American differences. For "utilize", it says:
utilize or utilise
n verb make practical and effective use of: he was determined to utilize the new technology.
DERIVATIVES
utilizable adjective
utilization noun
utilizer noun
ORIGIN
C19: from French utiliser, from Italian utilizzare, from utile (see utile1).
This post has been deleted by its author
"if someone could point me at a plausible differentiator between "use" and "utilize"."
There isn't one. However one of the laws of the corporate workplace is the more syllables you use/utilise , the more intelligent you sound to your peers. Ergo (and a bit of latin helps too) , some people love using long words where short ones would work just fine.
Non-English-speaking Anonymous Coward, yes, it’s common in some areas to use utilize as an overstuffed synonym for use. The proper meaning of utilize is “to make useful”, e.g. “I finally utilized that chocolate teapot — as an afternoon snack for my co-workers.”, as opposed to trying to use it as a teapot.
"“I finally utilized that chocolate teapot"
Thats no different to saying "I finally used that chocolate teapot". You simply put it in the past tense. There's no difference in meaning.
You're quite wrong, and missing an apostrophe.
"utiliize", as Irony Deficient pointed out, denotes "make useful". Literally it means "cause to have utility". That is very different from "use", which denotes consuming the utility of the object.1 If you're unable to perceive the difference, may I suggest a course in critical thinking?
"Utilize" is often - perhaps most often - used as a bloated synonym for "use", true, but that does not mean there is no denotative distinction between the words.
1This may be "consume" in the non-diminishing sense, as one consumes the text of a book in reading it.
The canonical Dilbert reference is http://search.dilbert.com/comic/Facilitator (the bottom two strips). Note that the PHB insists on longer, more pompous, rather soggy bureaucratese. "Utilize" instead of "use", "implement" instead of "do", even marginal lengthenings such as "object-orientated" instead of the proper "object-oriented". In most of these cases there is a small difference in meaning, but usually that is not the point. Some people just like to sound more important, and believe that using longer and finer-sounding (to them) words will achieve that.
Sir Winston Churchill, generally acknowledged to be a good speaker and writer, put it this way:
"Broadly speaking, short words are best, and the old words, when short, are best of all". (Speech on receiving the London Times Literary Award, November 2, 1949)
See also George Orwell's brilliant essay "Politics and the English Language", every word of which rings as true today as it did when written 70 years ago.
http://en.wikipedia.org/wiki/Politics_and_the_English_Language
Java on the desktop is dead, it's primary use these days seems to be to infect your computer with malware. The best thing to do is deinstall it. I bet about 99% of people will never need it.
Servers and mobiles seem to be a success area, but really it's depressing to see smartphones running Java apps..
Java on the desktop is dead, it's primary use these days seems to be to infect your computer with malware. The best thing to do is deinstall it. I bet about 99% of people will never need it.
Sounds like random shock talking points from one of the "N arguments to make the heads of [some political opponent you want to antagonize today] explode" posts that one can regularly find on confusenik websites, written by people actually unable to develop a coherent train of thought.
Servers and mobiles seem to be a success area, but really it's depressing to see smartphones running Java apps
Which ones run Java?
the Dalvik engine, which is Google's implementation of a Java VM
U wot M8?
> the Dalvik engine, which is Google's implementation of a Java VM.
Yes, except it is not 'Google's'* nor is it a Java VM**.
ART*** is Google's new Dalvik VM.
* """It was originally written by Dan Bornstein"""
** """Unlike Java VMs, which are stack machines, the Dalvik VM uses a register-based architecture."""
*** """a replacement, called Android Runtime (ART), that should improve the performance of Android apps by a huge margin."""
Java on the desktop is dead, it's primary use these days seems to be to infect your computer with malware.
Actually, I suspect its primary use these days is to run the 6th most best selling PC game of all times. Wikipedia says:
By March 2012, Minecraft had become the 6th best-selling PC game of all time. As of February 3, 2014, the game has sold over 14 million copies on PC and over 35 million copies across all platforms.
@Conrad Longmore: citation required.
I'm not aware of much use of Java for locally-hosted desktop applications, but I don't have the advantage of your omniscience.
I can assure you, however, that it's extensively used via applets and Web Start applications. I used to think that applets were just a way of embedding gadgets in web pages, and that they were obsolete when better HTML and client script came along. Since then I've worked on several market-leading trading platforms that are written in Java and delivered over the Web.
Applets? Maybe, but not for much longer. And I say this as someone who develops them - I can not in good conscience recommend them to my clients any more, as we can't guarantee they'll run from one release to the next due to unpredictable changes in the security model. Applets are dead.
Agreed. Anyone claiming that Java is dead on the desktop should visit software houses developing trading platforms for banks.
I use to work on one of those. There was simply no other choice. General observation is Java is flexible enough to allow work-arounds for all its failings at that time.
My only problem is the way articles are scripted here with loop holes that gets so easily picked up.
So you don't have any kids under 16 then? If you did then you'd find that they play Minecraft and sorry to say but that is run on Java. It's something like the 10th best selling game of all time, I believe.
A quick straw poll shows that at least 10 of my colleagues here in the office and roughly 5 friends kids play Minercraft regularly.
No Java, no Minecraft!
In IT we have software we use at my office, UC4 ( Java GUI ) , NetBackup ( Java GUI ) , Oracle SQL Developer ( Java GUI ), Eclipse ( Java GUI ), NetBeans ( Java GUI )...
This stemmed from the fact LinkedIn and Twitter abandoned hipster-choice Ruby for less fashionable Java. As ever, when it comes to Java, the reasons were performance and scale.
Ah no, Twitter went with Scala, i.e. a language running on the/a JVM. Did they move off it? Scala has its own problems, I hear, including major problems in debugging as coders enthusiastically embrace the newness and the ubiquitously overloaded "surprise" operator.
As for multicore, there is always Go.
"Guess the copy editors fell asleep during the earlier parts of this presentation".
What copy editors? I think you'll find this article is exactly as Gavin wrote it. Although I tend to be a stickler for accuracy, perhaps we can forgive a few typos in view of the stimulating content. 8-)
The problem with using concurrent Lambdas is lots of people don't know that concurrency has lots of pitfalls if you have any mutable state and don't know how to manage this; so there will be loads more flaky code from concurrency newbies using Lambdas. There can also be Thread pool starvation issues if you don't know how to get the new APIs to use custom Thread pools.
The cool stuff is not the Lambdas, it is the Stream API, and the other Java language and JVM enhancements; Lambdas just make this easier to use.
Ruby and all the other hipster languages,like Scala, are wannabe mainstream languages, but have been discovered to not be usable in anger, so people went back to reliable Java.
Don't meh the Lambdas, or they will lisp you in a curry.
Ruby and all the other hipster languages,like Scala, are wannabe mainstream languages, but have been discovered to not be usable in anger, so people went back to reliable Java.
This is politspeak for "I don't understand any of this, leave me alone!"
It's great to see this in Java, but when will it actually get to Android?
Java 7 was released in 2011, but Android is stuck on Java 6. Only in late 2013, finally Android could use Java 7 language features, but Android still can't use the Java 7 libraries.
Basically, I think of Android as a fork of Java 6.
"Basically, I think of Android as a fork of Java 6."
NoNoNo! its a completely new thing... with the same API. See Oracle vs Google