String is one that has changed pretty significantly - count and offset have been removed, only fields are hash and value now.
This means String.substring is no longer an O(1) method, but it saves 8 bytes per string which is huge, and also avoids some of the wierd corner case GC/memory issues that substring/StringBuilder caused by hanging on to the reference
Actually it's worse. You're more likely to have hash collisions and if you have enough of them you'll overflow into a red-black tree which has an even higher memory footprint.
If you care about memory footprint use Eclipse Collections.
You are? I know they introduced the tree nodes as fallback if you have a bad hashing algorithm or malicious inputs, but that doesn't mean the hash collision rate got worse by default.
Uhm no. The hash code of my keys may be perfectly distributed but then HashMap#getNode comes along and masks most of my bits away. HashMap#hash(Object) is supposed to make the impact of the masking less bad.
If your hashes are perfectly distributed, as in each bit having a 50% probability of being 1, independent of all other bits, then the low order bits will be just as random as the high order bits, no "making the impact less bad" required.
Tracking a cause of OutOfMemoryError recently (we maintain several applications written in Java at my day job), i've observed that most data-structures have a size very different if empty or not.
Yes, because many of them allocate a zero size array when you call their constructor and then lazily add to it. But that isn't really about object layout as I think of it, so much as what the fields of a particular object are.
I think it depends on the JVM. You can use compressed refs on JRokit with > 32G heaps. Its a bit of "bit twiddling." This article explains it pretty well:
It has to be noted that on HotSpot the object header is only two words not three words like on J9. Basically Flags and Locks fit into one word on HotSpot whereas they use two words on J9.
Only on 32 bit IIRC, headers are 12 byte on 64 bit with CompressedOops (the default for heaps <32gb) and 16 bytes without. The bit layout of the markoop is here:
As someone who used to be a hardware engineer, I found Figure 1 in the first section surprising. All modern OS run processes on independent virtual memory spaces, in order to ensure that processes don't collide with one another, or with the OS itself. But if figure 1 is to be believed, the kernel shares the same address space as the process. Is this a mistake on the part of the writer?
It's pretty common to map the kernel memory address to the same fixed range in the virtual memory address space of every process. Typically the kernel portion resides on the higher range of the memory space. For the 32-bit 2/2 split setup, 0GB-2GB is reserved for user mode and 2GB-4GB for kernel. With 1/3 split, 0GB-3GB for user and 3GB-4GB for kernel.
This makes it easy to work on memory shared between user mode and kernel mode code since it's the same address space. Buffer passed from user mode to kernel mode is just a matter of passing down the virtual memory address pointer, no need to copy. The kernel code accessing it just accesses the lower range of the virtual memory space.
The kernel code mapped to the same fixed range in every process also makes it easy to call kernel routine from user mode. SysCall just elevates privilege to be in kernel mode and jumps to the kernel routine at the exact same address in every process. You can think of the kernel as a special library got "linked" into every process at the exact same location, along with all its data.
Although user mode and kernel mode are in the same memory address space, user mode cannot access kernel mode memory. Memory pages are protected with flags, like R/W (Read/Write), U/S (User/Supervisor). A S-marked page cannot be accessed by user mode code. Protection between kernel and user mode is still in place.
No, it's not a mistake. Each process has it's own virtual address space, but part of that space is typically used to map operating system code and data. The reserved part is anywhere from a quarter to a half on a 4GB 32-bit system (I have no idea on a 64bit). Those pages are marked kernel-only. The upper half to three-quarters will be different for each process.
One reason for this is so that you can easily trap to the kernel (for an interrupt, a system call, an exception, etc.) without changing the page tables at all -- you just change the cpu mode bit.
In my work I rarely find this sort of thing relevant. It's much more important to make sure you don't have object references lying around. I mostly do server stuff now. Maybe this kind of optimization is still important for devices?
As with everything performance related, it depends. I do server-side work as well, but I've seen cases where it matters.
eg, somebody got overly "OO-happy" with a response object and managed to take something that should've been one object with 8 fields and instead made a graph of 8 object with a total of 12 fields (4 of them repeated), wasting ~400 bytes each IIRC. When you're creating one of those for each request and handling 200k requests/sec it adds up to a lot of memory. That means a lot of time spent in the GC, which means a lot of GC pauses, not to mention effects on memory bandwidth, locality, and processor cache usage.
All else equal, using less memory is faster and more scalable than using more memory. Java programmers seem to frequently forget that object references do have a cost associated with them.
Tangentially, those complex object graphs also make (de-)serialization much harder than it needs to be. Requests & responses should be as simple as possible!
What did it save you server-wise and how long did it take to identify and make the change? Also, did you discover this as part of a performance problem investigation or was it something you saw upfront and nipped in the bud before it became a problem. I agree it sounds like poor design. I instinctively simplify whatever info is going to be sent from the server.
Generally when building servers on top of a jvm, it's a good idea to be able to capture eg 1m requests, replay them, and monitor your memory allocation / gc as part of quality tests. If you create nests of objects in java, it quickly gets expensive, both in terms of net memory and gc costs. One common place this happens is parsing json/xml; use thrift or protobufs instead.
If you are eg building an ad server that is supposed to sustain some XX thousand requests per second, you want to also monitor eg eden, survivor, tenured, and promotions. Bump pointer allocation and gc is very fast -- normally faster even than manual memory management -- as long as almost nothing survives. The problem is if some objects start accidentally living past requests, stuff goes boom fast.
It was something written by a different team, so it was committed by the time I saw it. But I thought it looked bad immediately. Profiling later showed that it was a problem spot, and changing it showed decent improvement.
Java is getting lots of new competition from languages that have proper support for value types, have layout control and have AOT available for free on their reference compilers.
On the desktop it already lost to .NET, Qt and HTML 5.
On the mobile it might reign in Android, but Android Java is not 100% Java and I don't see Google improving the language, in case Oracle stops doing it now that they had another setback.
They went silent on future of JEE and IBM is now doing lots of Swift and Go support, while making J9 language agnostic.
Also, what advantages, except existing code bases, does Java provide to Kotlin, Go, Swift, Rust? For about any use case I can imagine a better choice than Java.
Also, concerning the recent events (Google vs. Oracle), I think every new project might want to triple check if they really want to use a product from someone like Oracle.
Kotlin is a JVM language, and doesn't really compete with Java (the two are "friendly"). Rust is a low-level language which is much better suited than the JVM to memory-restricted environments, but JVM languages (including Java) are much easier (therefore cheaper) to develop, so are a better choice for server-side applications. Go and Java are indeed very similar, but I find that Go is better for smaller programs and Java is better for larger ones (due to amazing monitoring, polyglotism, dynamic code loading etc.).
The real adversaries are Objective-C, Go, Swift, .NET Native, C++14, OCaml, Haskell and even node.js.
Monitoring tools similar to VisualVM will come.
Nowadays my Java code is either targeted at Android or maintenance of existing enterprise code. Other than that we aren't using it for greenfield projects.
It seems to me that companies that choose non-JVM languages (with the exception of .NET) for important server-side projects are those that have always opted for the flavor-of-the-month. Most of those using Go/Elixir/OCaml/Haskell today, are those that used PHP, Ruby, Python or Node yesterday, and are likely to pick something new tomorrow. All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. Those problems are sometimes obscured by the novelty and promise of the shiny alternative, and take a while to be felt among those who always opt for the new thing, but they are invariably discovered later on, and by that time something newer comes along, whose problems are yet unapparent. The problems are there because unlike Java and the JVM (and Fortran, COBOL, C and Rust), those platforms were not developed after careful consideration of the industry's needs (Erlang/Elixir is a different story, and, indeed its fundamental problems are more environmental than technical).
In addition, in smaller/less-critical projects, Java was an accidental leader in a short period of time where the competition disappeared and Java itself was novel, but it was never "supposed" to be there to begin with. VB and Delphi were very popular choices early on. I'd estimate that even when Java was the shiny new thing, VB, Delphi and other rapid-development languages had a larger share of the market than Go, Node, Ruby, Python, Haskell and OCaml combined today. And frankly, I don't see companies developing en masse large-scale applications in C++14. Unless you have very specific needs, there's just no reason to go there and pay a higher development cost, and if you do have those needs, you're probably already there.
In large corporations (including trendy ones, like Google, Amazon, Netflix, Twitter and many more, let alone more conservative ones) the JVM still reigns supreme, with competition lagging far, far behind. I'm not saying it won't eat into the JVM's market share -- although they're mostly cannibalizing one another -- but I don't see any potential leader in the pack. It's possible that there won't be one, with many sharing the cake.
So I think that (again, with the notable exception of .NET) the non-JVM market is composed of novelty-seeking organizations and a share that wasn't Java's to begin with, but accidentally was for a short while (the two segments intersect).
>All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM.
The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time.
Programming language history sometimes seems pretty random. If Java hadn't hinted at the fantastic possibilities of the now completely defunct Applet technology, Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that.
It's ironic that Applets failed because of unsolved problems with the JVM that remain largely unsolved to this day (such as insane memory usage and laggy startup).
And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists.
And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity.
I wouldn't dare to predict which flavor-of-the-month will fade and which one will dominate. It seems to be random and largely dependent on fantasies about future platforms unrelated to technological merit.
We could have stuck with Lisp and Fortran and we wouldn't be any worse off than we are today. There is very little progress in our industry when it comes to programming environments.
> The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time.
Perhaps, but they're not solved by any of the languages/platforms mentioned.
> Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that.
Except that they were the same VMs (HotSpot was a Smalltalk VM). Smalltalk didn't lose; it just got repackaged as Java.
> And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists.
With that I agree, but JS has its own issues, and the other languages mentioned don't have it any easier in that regard.
> And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity.
Except that the JVM is by far the leading platform not only in conservative enterprises, but also among the thought-leaders and biggest technological innovators. I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software. As I said, for less-serious/smaller applications, Java and the JVM were not meant to be the first choices. We had VB and Delphi, then Python and Ruby, and now Node and whatever. It's the same market share, and I don't see evidence that the JVM is slipping.
>Perhaps, but they're not solved by any of the languages/platforms mentioned.
Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Go also solves the value type issues that cause the JVMs excessive memory usage. Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).
>Except that they were the same VMs (HotSpot was a Smalltalk VM)
Yes, but HotSpot is from 1999 whereas Java is came out in 1995 if I remember correctly. The initial Java VM was a bit of a throwback.
>I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software.
> Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM.
Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game.
> Go also solves the value type issues that cause the JVMs excessive memory usage
True, but not only is that solvable, it is actually being solved on the JVM as we speak, and will be released long before Go will have caught up. OTOH, Go has some serious issues that are unlikely to ever be solved (its reliance on source-code instrumentation and lack of support for dynamic code manipulation; this has been demonstrated to be of great value for many server software systems).
> Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).
This isn't any worse than any language that isn't JS. On the JVM you have Kotlin, Clojure and Scala, all also compile to JS, and those are just the leading options.
> How do you define "serious"?
Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. .NET is pretty much Java's only serious competition there.
> True, but not only is that solvable, it is actually being solved on the JVM as we speak
I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future.
IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting object layout.
Even the Scala guys are now researching into Scala Native.
>Tooting my own horn here, but Quasar on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game.
If that is so then kudos to you.
>it is actually being solved on the JVM as we speak
Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid.
>This isn't any worse than any language that isn't JS
Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon.
>Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade.
Many platforms have that covered. Your arguments in favor of the most widely used platform seem a bit tautological at times. By that standard, Java could never have gotten to the place it is in now.
> Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid.
Three or four, most likely. That's not a long time at all.
> Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon.
I agree. If I were to pick the biggest threat to the JVM, it wouldn't be .NET or Go, but the JS ecosystem -- including wasm, which, although low-level at this time and more resembling LLVM, may grow to be a universal high-level VM one day.
> Many platforms have that covered.
I think almost none do.
> By that standard, Java could never have gotten to the place it is in now.
Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players, so it pretty much puts OCaml, Haskell and other academic languages out of the race. This leaves JS, Go, Erlang and .NET. Go seems unwilling to really study the market, so it will achieve success among the novelty seekers, who will then move on to the next thing; Erlang -- which has an amazing, inspiring design -- has no advantage over the JVM, and is at such a huge disadvantage in terms of resources, that the chance of it ever catching up is close to zero. This leaves .NET and JS, both with plenty of resources and a lot of industry involvement, and they are the only candidates that at this time appear to be able to unseat Java.
>Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players
I can't detect even the slightest influence of careful analysis on the rise and fall of technologies. If the creators of Java were planning anything, then it certainly wasn't what actually happened. Java failed completely in all areas it was originally built for (at least until Android, which happened very late in the game and is under threat).
If I had to come up with a formula for success, it would look something like this:
10% novelty-seeking and merit + 10% corporate backing and tenacity of the creators + 10% platform advantage + 70% historical accident.
In Java's history, that 70% historical accident was the web. No one planned for that to happen. All careful planners were taken completely off guard by the web.
Looking at my formula, I would say Swift has a shot at going somewhere. But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
> But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
With that I can completely agree. I can't predict when and how the demise of the JVM would come about, but I can see that it's not happening just yet.
I do wonder about one meta-question, though: What effect does the trendy SV tech-marketing-speech has on developer technologies? Ruby was a huge SV hit and now it's ebbing, all without ever leaving a big impact on the software industry at large (sure, it was adopted by the odd "enterprise", but nothing on a grand scale). Now we see something similar (on a smaller scale, I think) with Haskell, Go and Elixir. Will there be a serious impact, or is it a passing SV fashion?
I don't know, but one thing is for sure. All dominant technologies that turned out to have a great impact once started out as something that many thought was a passing fad.
Also, there are some languages that dominate significant niches seemingly forever, like Python as a frontend for math, science and machine learning or R for statistics.
It's very sticky even though I never quite understood why you would want such a huge language barrier between those who implement interesting algorithms in C/C++ and those who use them. I would have thought that there is more overlap between these two groups. I can imagine a similar role for Go in Unix utilities and backend infrastructure.
> All dominant technologies that turned out to have a great impact once started out as something that many thought was a passing fad.
Absolutely, but all fads started out as something many thought was lasting...
> It's very sticky even though I never quite understood why you would want such a huge language barrier between those who implement interesting algorithms in C/C++ and those who use them.
I'm not sure what you mean. My field is distributed/concurrent algorithms, and especially distributed databases, where Java has a significant lead over C/C++ where interesting algorithms are concerned.
I mean things like Theano, Caffe, TensorFlow, torch, mxnet, etc, basically all the leading deep learning frameworks. It's similar in several other math/science related fields. Not that Java doesn't exist in these fields, but it's an also ran.
First of all, that's a very small domain. I can similarly say that C++ is an "also ran" in business server-side applications. Second, I don't think that Watson, Spark and H2O qualify as merely "also ran".
>I can similarly say that C++ is an "also ran" in business server-side applications
Absolutely you can, because it's true. C++ usage has declined dramatically in the last 10 years. It's no longer used as a mainstream language for business applications (something it was never good at).
>Second, I don't think that Watson, Spark and H2O qualify as merely "also ran".
Spark and H2O don't even qualify as also rans in the space I'm talking about. Watson may be an also ran, and significant parts of it are written in C++. I have no inside information, but it's not too difficult to imagine which parts that would be.
It's pretty simple to see what's happening. Just look at Google. Google is a very Java friendly company. They do a lot in Java, just not their core AI stuff. Data shovelling and integration in Java. Core algorithms in C++. That's the pattern.
So yes C++ is used in smaller domains. But these are the most interesting, most innovative and fastest growing domains. Those who really specialize in these areas overwhelmingly use C++.
And it's entirely clear to me why that is the case. I tried to use Java for it (and Go). It doesn't work. I have to be able to load a ton of data into memory without constantly fighting a garbage collector, and I have to be able to specify exactly how that data is laid out in memory.
pjmlp reminded us of IoT. Another up and coming field where Java isn't going to be the first choice. Same with games, video processing, etc. Java is falling back in most new application areas.
Interestingly, web browsers seem to be a pretty good yardstick for many other completely unrelated tasks. Can you write a web browser in it that is up there with the best of them? If the answer is no, then that language is not going to be viable for a lot of other tasks as well.
Well if applications of future are to be developed and delivered as it is today Java will very likely remain primary choice. But with containerized deployment Java solutions looks rather heavyweight. Oracle/IBM/SAP know this. I think that's why work on Java EE 8 is kind of stalled.
Java GC/ memory shortcomings become visible when companies like Netflix push it to limit e.g
> ... The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.
Go's advantage when it comes to GC is very temporary. HotSpot's GCs are more advanced, and Go has the upper hand only thanks to value types, which are coming to Java. Go will not come close to catching up by then. I think that containerized deployment is likely to evolve and change at a much faster pace than development platforms, so it's really hard to tell which approaches would fit where.
Java release cycle is ~3yrs so Java 10 will be roughly expected in 2020/21 time frame. And at that point larger ecosystem like Apache etc will start taking advantage of value type. So it is like 6-8 years from now which I would not characterize as very temporary. Also this is assuming Go committer from now onwards just sit and do nothing about performance improvements which again seems quite unlikely.
Java has 15 year head start on Go and if a newer Go GC beats very mature hotspot GC it could either mean Hotspot advantage is largely in theory or it has reached its peak performance and there is not much scope to improve further.
Go's GC doesn't beat HotSpot's GCs. It just has less work to do, and this is being fixed in Java. In any event, I think the biggest potential threat to Java isn't Go (which has some fundamental issues that are very hard to fix) or .NET, but the JS ecosystem, which may become the universal VM.
Also Go's GC doesn't move objects, which makes the whole problem a lot easier as long as heap fragmentation doesn't end up biting you badly in the end.
You are forgetting about the native desktop, IoT and mobile space, where besides Android's fork of Java, the language has lost its market.
We have zero customers using Java, besides Android and legacy Swing applications on those areas.
Otherwise customers are asking us instead for Qt/C++, .NET, Swift, Objective-C and Cordova/Ionic.
With Microsoft adoption of Docker, and their Go sponsorship on Visual Studio Code, I have started to see some Java consulting companies on my area to add Go on their services list.
Most Java deployments that I have to deal with on server side are still on Java 1.5 - 1.7, RichFaces and the occasional Websphere.
But Java was never "meant" to be a leader on the desktop; VB, Delphi and plenty of others have always had the lead. Whatever market share Java is losing, it is market share that it got due to market failure, and only held briefly. You're absolutely right about mobile, but the fragmentation there is such that no language/platform is the clear winner. Java's uncontested hegemony was short-lived, but even without it, it is an order of magnitude ahead of its closest competitor on the server side (with the exception of .NET). Everything else is just too fragmented to pick out a winner. Go is indeed an interesting challenge, but it has some fundamental issues that are serious roadblocks, while the JVM doesn't.
Let me put it this way: the war on server-side development is the JVM's to lose. Right now, it has some challenges (memory usage etc.) that are all solvable, if the important ones are recognized and addressed. Maybe they won't be, and someone else would step up and grab the lead. Maybe it'll be .NET; maybe it'll be Go; maybe JS. But right now, all alternative platforms are cannibalizing one another and competing for market share that has (almost) never been Java's much more than grabbing significant market share from the JVM.
I am curious to see what Oracle will do after Java 9 gets out of the door, specially now that they lost the case against Google.
In the hypothetical future they do like Sun and let the language stagnate after Java 9, given that Android Java is stealing their revenue, who do you think will bother to pick it up?
We are already seeing them silent on JEE and JavaFX, Kenai and Java.net got closed down, and it wasn't only the JEE evangelists that left Oracle, key JVM people like Monica Beckwith have also left.
I don't see IBM, Red-Hat or Google willing to pick the language and offer the resources and care to design it further.
And the type of research that Java GC and JIT require need deep pockets, not a few weekend pull requests.
> In the hypothetical future they do like Sun and let the language stagnate after Java 9, given that Android Java is stealing their revenue, who do you think will bother to pick it up?
Google (who is heavily invested; Google's OpenJDK team is about as big as their Go team)? IBM? Red Hat?
> We are already seeing them silent on JEE and JavaFX, Kenai and Java.net got closed down
We are seeing the exact same things happening at MS, yet there you interpret these events generously. Oracle is trying, like everyone else, to see where the wind is blowing. Kenai and Java.net are completely useless, and have been effectively abandoned for quite some time (more abandoned than Google Code).
I understand this tendency, though. When you're the leader and change things, you appear desperate. When you're an underdog, you seem visionary. But the fact is that Java isn't just the leader. It's competition (except for .NET on Windows only) is more than an order of magnitude behind. Java has also been eulogized time and again -- Ruby and Python were supposed to kill it last time around -- yet the JVM grows stronger, while the all the rest fiercely compete with one another on the distant second. I agree that JS is real and may actually change things, but there is so much new server-side code being written on the JVM -- significantly more than all other tech combined -- that the weakness on the client may kill it eventually, but it will be a while before the trend changes and we're at peak Java. There are huge companies like EMC that are just now moving projects from C++ to Java, and smaller companies like AirBnB that are moving from Ruby/Python to the JVM.
> I don't see IBM, Red-Hat or Google willing to pick the language and offer the resources and care to design it further.
Why not? Whatever other language/platform they pick will require even more investment than Java. There is no other language with that the industry is similarly invested in (except maybe C). Not even JS, which is still over 95% client-side code.
> And the type of research that Java GC and JIT require need deep pockets, not a few weekend pull requests.
Microsoft has a different problem, the startups of the 21st century rather use UNIX free clones than pay for OS licenses.
Google has proven more than once on Android how "committed" they are to the health of the Java ecosystem and how willing they are to write top performing JIT compilers for Java and keep their implementation up to date.
Where they are putting their language research money is on Go and V8.
IBM is the main company besides Apple now investing in Swift and last year they had a major project to make J9 JVM language agnostic as a portable runtime.
My career has shown me more than once that languages which aren't sponsored by OS vendors eventually fade, regardless how big their user base is at a given moment.
Oracle surely isn't an OS vendor as such, what they made to Solaris and their Unbreakable Linux aren't really things that many still care about.
What I know is that RFPs for Java projects on my little part of the globe are either Android or maintenance related.
I hope to be proven wrong, but I no longer search for Java projects as I used to.
> Google has proven more than once on Android how "committed" they are to the health of the Java ecosystem
Google's Android team and Java team seem to be completely distinct from one another. Throughout most of the trial, Google remained one of the companies most dedicated to OpenJDK.
> Where they are putting their language research money is on Go and V8.
I don't know what you mean by "language research money", but they're putting as much investment into OpenJDK improvement as into Go. Don't know about V8. They certainly wasted a lot of effort over Dart.
> last year they had a major project to make J9 JVM language agnostic as a portable runtime.
Yes, I was at JVMLS where they introduced it. Oracle Labs' Graal is much more "language agnostic" than that, and still very much Java. Graal may show the way to smooth (if not seamless) Java/non-Java interop.
> What I know is that RFPs for Java projects on my little part of the globe are either Android or maintenance related.
In that case, I think that your view may be very skewed. Android appears absolutely minuscule compared to Java where I'm looking. Of course, my view may be skewed as well, as I hardly look at front-end projects at all, and on the backend Java is so huge as to dwarf pretty much everything else.
This makes me wonder if IBM could now (post-Oracle v. Google) take over, or at least bite off a piece of, Java if it introduced value types and other goodies for JVM languages ahead of the official process and made a production version of J9 available at no cost.
A lot of tooling. Eclipse just works. You don't have to use Intellij. Spring makes most things a breeze. Maven handles dependencies and complex builds easily. A lot of the language issues disappear with the right, battle tested tooling.
One benefit is the extremely large set of 3rd party libraries and tools. It's hard to catch up outside the mainstream bread and butter stuff.
Also, finding experienced developers, devops, etc.
While Kotlin is interesting, and can use java code, maybe it's a little too small and have less battle tested toolchains so java probably feels like a slightly safer bet for large projects and conservative organisations.
Android N will use selected parts of the OpenJDK, it isn't 100% Java 8 compliant.
And with Marshmallow having 7.5% market share[1] how long do you think will take for developers even to start caring about Java 8 support on Android N?
It seems really silly to compare the "search/insert/delete performance" of HashSet to HashMap to ArrayList to LinkedList, since the fundamental purpose of each class is different.
Not to mention that "search/insert/delete" are three separate operations with sometimes three different performance characteristics.
For instance it is incorrect to state that the insert/delete performance for LinkedList is O(n) - both are constant-time.
Ah, I was assuming foolishly that we were talking about removing or inserting only at the head or the tail. All the more reason to be more detailed in a writeup than simply "Performance: O(n)" :)
