Slashdot Mirror
Everything About Java 8
New submitter reygahnci writes "I found a comprehensive summary of the developer-facing changes coming in Java 8 including: improvements to interfaces, functional interfaces, lambdas, functions, streams, parallels, date/time improvements, and more. The article includes example code with realistic examples of use as well as explaining the reasoning behind some of the choices made by the developers who are working on Java 8."
I can't wait!
After all the security vulnerabilities patched this year, I would think they're feeling the pressure to make sure there isn't a repeat.
The Blade Itself
This is about Java the language, not Java the browser plugin. You should know the difference by now...
Or I guess it could be considered relatively important also not to allow drive-by downloads of malicious software from webpages that you didn't even click anything on
This is about Java the language, not Java the browser plugin. You should know the difference by now...
I've been misinformed then, I thought the security vulnerabilities in the java plugin were inherited from vulnerabilties in the way the language itself handled data. Someone mod up the guy above.
The Blade Itself
Highlights of Java 8 include
Green solutions. Advanced power management features, and automatic tracking of each thread's carbon footprint. An console allows users to see the carbon footprint of each thread in real time.
Social networking. Users can share jar files on social networks, and like their friends jar files.
Cloud computing. Java 8 will be the first VM built for the cloud.
Summaries: I like them. Even such as we get around here.
I say we start a pool on how many zero days will be availible by the time it launches or even if we want to be generous, within the first week.
I will start it off with 7
For non trivial programs Java does not use more memory than an equivalent C++ program.
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
After all: it gets compiled down to the same machine code ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Get your head our of your ass. Java is one of the most widely used programming languages. Just because you don't notice it on your desktop doesn't mean it isn't used.
And these features need to be supported in the JVM, creating a larger attack surface.
I'd think that deficiencies in intermediate forms can be handled. That aside, you can add as much syntactic sugar as you wish without compromising anything. (Well, the sanity of the developers, sometimes, I guess. :))
Ezekiel 23:20
For non trivial programs Java does not use more memory than an equivalent C++ program.
Only if the large majority of your data is in non-object arrays, or in very large objects so that the headers and overhead are small enough.
Ezekiel 23:20
No, it doesn't. C++ gets compiled into machine code. Java gets compiled into bytecode that is run on the Java Virtual Machine. Also Java uses garbage collection, which can slow things down.
Its shrinking the say way as say the browser Silverlight plugin, the Adobe Flash plugin or the abomination called "Active X"
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
After all: it gets compiled down to the same machine code ...
Not exactly. Java is unable to vectorize floating point operations now (might change with java8 though), which is very common in any multimedia application. So it remains a lot slower than what you get by default in C/C++ with a decent compiler.
Video of some good progressive thrash music
Java does not use more memory than an equivalent C++ program.
In an exclusively garbage-collected language with no deterministic finalization, it isn't possible to do something like C++ RAII, where non-memory resources are closed as soon as an object is destroyed, in Java.
After all: it gets compiled down to the same machine code
But you still have to keep the bytecode and the VM in memory at all times, which hurts especially on a mobile device.
Why do you think IBM built SWT?
I don't (and wouldn't) have a JVM installed so that probably explains why I don't notice it on my desktop. It used to be useful on the server side, but every month that goes by it falls further behind. Java 8 is not going to be significant enough to change that. At this point, the only reason to use Java is because that's what you've always used.
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
That's funny since those contrived benchmarks are the only ones Java can actually win. Usually because the C++ code is also set to no optimizations. If this were really true why are all the high-performance multimedia, mathematics, etc. libraries all still written in C, C++ or Fortran? That's because Java is still magnitudes slower.
And these features need to be supported in the JVM
As far as I can tell, none of these features have anything to do with the JVM. They're all library and compiler changes. None of them are directly related to security or sand-boxing. It also seems like there will be no significant changes to class verification either. Only to allow annotations in more places, maybe lambas, but I dare say they'll be implemented as regular anonymous classes by the compiler.
In the next few years we will probably run a little experiment of moving from sun java 6 to oracle java 7. Perhaps the attempt will fail at first and we will postpone the upgrade for another year or so, and then try again. But Java 8 ? Let me call you back in 5 years... or maybe 7.
There is a real, major benefit of using Java over other languages, such as C or Haskell or Smalltalk, which is this: it lets you work with other mediocre programmers, and has limitations that prevents them from doing anything too crazy. That is, even if they write horrible code, it won't be so bad that you can't work with it (I'm sorry fellow Java programmers if that offends you, but think of where Java is used most).
That said, I'm somewhat concerned about some of these changes. Lambda functions are great, but one of the benefits of functional programming is the lack of side effects. Under the Java 8 design, lambda functions allow you to modify member variables, which means that benefit is completely gone. This means lousy programmers will be able to write incredibly complex code, with strange side effects, that is hard to use.
The new streams functionality is fine, but did they really have to call it streams? When there are already Streams in Java?
String.join() is great. Finally.
The new Date library looks fine. It better be good enough, because do you really want yet another Date system added into Java?
"First they came for the slanderers and i said nothing."
it isn't possible to do something like C++ RAII, where non-memory resources are closed as soon as an object is destroyed,
Like allocating and deallocating the c_buff buffer each time a "std:string" gets created on the stack? And you think this is fast?
After all: it gets compiled down to the same machine code
But you still have to keep the bytecode and the VM in memory at all times, which hurts especially on a mobile device.
I doubt that APK (that is: an Android Package, not the hosts-file dead-horse) requires more than one JIT compilation (which is cached afterwards) and the GC in memory.
Questions raise, answers kill. Raise questions to stay alive.
Probably. Server side Java (where it is used mainly) is pretty much reasonable security wise.
Why would anyone enable Java in a browser is beyond me.
Actually, once you get used to Swing it is pretty hard to go back to any other toolkit. Swing is amazingly powerful, and ever since Java 1.6.0u10 also very performant (since it is based on Java2D which is DirectX accelerated on Windows and OpenGL accelerated everywhere else). One thing you do have to be aware of with Swing is not to block the "Event Dispatch Thread". Once you learn that, and how to use GrdiBagLayout properly then you are 'away laughing'.
With the Nimbus Look & Feel the look of Swing is pretty awesome. Of course, many Swing developers have or are transitioning to Swing;'s successor, JavaFX 2. JavaFX 2 looks amazing (lots of special effects, gradients, transparency, reflections, animations etc that can be switched on very easily). JavaFX 2 does have a slightly different model for properties than Swing, so there is a bit of an impedance mismatch when you embed Swing into a JavaFX 2 UI or vice versa.
I understand many don't like the learning curve of Swing, and some of the overheads (eg. TableModels) - but it turns out these abstractions are necessary for users to be able to make custom controls (which is easier, IMHO, than other toolkits as you get a lot of control on how your custom will work exactly how you want it to).
The best thing about Swing, IMHO is not even the enormous capability for extensions. For me the best features is not only to have pixel-precise layout, but also you can make the UI resize *exactly* the way you want. While I like GWT and CSV for web stuff when I use them I always miss Swing as the later us able to work out the correct size of controls itself, and resizes exactly the way I want it (that's due to a problem in browsers computing layout [which the GWT guys called "intractable" in the browser; but Swing shows this is not the case on the desktop]).
There is a lot of life left in Java desktop technologies. I'm having a great time using OpenGL (via JoGL) in Swing to produce a modern jet combat flight sim. The ability to mix Java controls and 3D saves a lot of work (most 3D apps have to implement UI controls themselves - so end up behaving non-conventionally and looking a little odd).
How exactly does it screw with compatibility? Old code will still compile. Old compiled classes will still load.
They're adding new stuff. Nothing old is being changed or removed.
You don't *have* to re-write anything. If someone tells you so, its because they want to.
It only screws with IT departments because they fear change. They also seem to not want to install security updates either.
The only JVM upgrade problems I've experienced in the last 10 years was with legacy code written for IBM's 1.3 JVM because the developers at the time thought it was a good idea to refer to com.ibm classes.
No Java itself is used in so many places. Your phone probably uses it for a start. From the cheapest old fashion Nokia candybars to the latest Android smartphones to a whole host of embedded systems around the place and various webservers. They all use Java extensively and they never have an issue with the language.
Unfortunately there's a particular Java plugin from Oracles version of the Java VM that insists on running every Java program your browser comes across. You wouldn't run a plugin that runs every compiled executable you come across would you? Well Oracles Java plugin tries to run every Java applet it comes across. That's where these security flaws you hear about come from.
So Java as a whole is having its name tainted by one particular plugin.
C++ is unable to perform comprehensive escape analysis (good for optimising multi-threaded code). C++ also lacks the ability to optimise virtual method calls.
Java can inline non-final methods and undo it if required.
There is a *lot* of stuff you can do when you have runtime optimisations as well as compile time.
You're technically correct in the Java is not compiled to machine code. The JVM does the bytecode to machine code compilation.
That's because Java is still magnitudes slower.
I'm afraid I have to disagree. I'm writing a modern jet combat simulator in Java and the runtime speed is fine. The bottleneck is never the CPU, it is always the GPU. I also have to say that Java's performance in terms of latency is very good. The reason for this is because I'm able to create a lot of threads very easily and Java manages resource sharing very well, plus use of the language features for synchronization threads and I get to use around 20% of each of the eight cores on my machine. When I use an excellent product in a similar niche called DCS:World I do notice that it's speed is somewhat hampered by the C++ running on a single core. Now yes, multi-threading in C++ is of course possible, but it is much tricker than Java, especially the resource management.
So I think your comment is not correct. Java is comparable to C++ (sometimes faster, sometimes slower) on a single thread. When it comes to overall performance I find Java is faster overall because it is much easier to utilize all the cores in a machine with Java. In terms of gaming the performance of programming language used is nearly irrelevant - it is all down to how well you use the GPU (especially GPU memory; if you can keep stuff in VRAM then your performance is awesome).
Finally, let's move from the speed that is not that relevant (runtime) to the speed that actually matters (development time). Java is much much faster to develop in. You do have to spend some time profiling and tuning a Java program, but since you spend far far less time debugging than C++ you are still winning. I also love the JVisualVM that comes with the Sun/Oracle JDK and OpenJDK. While C++ has profilers they are a hassle to use, you have to compile your program each time you want to profile and recompile to measure different metrics. With JVisualVM you can profile any Java program without source and without recompilation since the monitors are built into the JVM (in exactly the same way as performance counters are built into operating systems these days, accessible by dtrace, strace, truss etc).
So, I think C++ is best used in niche programs where the host environment measures its memory in kilobytes. For other applications Java is more than fast enough on a single thread, has better throughput on multi-core machines, and is *much* faster to develop in (saves money, and also means something gets delivered sooner, as in, "faster time to market"). That's why Java kicks ass on the Tiobe Index - even if users only know about it from Minecraft and browser plugin issues.
You don't need to wait till an object is garbage collected for non-memory resources to be closed. You call the close method (in a finally block, or use the try-with-resources introduced in Java 7)
The C++ compiler doesn't manage resources entirely for you. You need to do that yourself in your destructor.
If keeping bytecode in memory was really a deal breaker, there is nothing stopping the use of memory mapped files.
as all it seems to be doing now is playing catchup to something like Scala which has at least thought out the functional stuff maybe a bit more
My IT department is still running Java 6 update 5 from 2008. They're too scared to upgrade to any later update levels because no one is going to give them the money to regression test every piece of Java code we've got.
The only saving grace is there is no browser plugin installed.
There has been well over 200 security issues fixed since 2008. As a bonus there has been significant performance improvements.
Oh, and good luck with XP in 12 months time when there are no more security updates.
First, the compiler algorithms are virtually identical in both cases, save for the expansion of method calls (vtables vs. multiple types of inline caches). Second, GC hardly affects overall speed if it's good enough (Azul Zing). The problem with Java's memory model is more about the lack of developer-controlled locality - if everything is an object accessed by reference, you end up with a lot of tiny pieces scattered around your memory. There's both size and speed overhead to that, no matter whether the whole thing got malloc()ed or allocated by a bump-a-pointer allocator with GC.
Ezekiel 23:20
You're technically correct in the Java is not compiled to machine code. The JVM does the bytecode to machine code compilation.
That's like saying that it wasn't me who wrote this sentence, but instead I caused my fingers to move with the power of my will and my fingers wrote it instead. Java *is* compiled to native code. The last time I checked, the present simple tense was used for statements with general validity, and the general truth is that the majority of installed Java runtimes on PCs run the majority of opcodes executed *after* compiling them to native code. I don't see how you can make a more general statement than that.
Ezekiel 23:20
The C++ compiler doesn't manage resources entirely for you. You need to do that yourself in your destructor.
The destructor needs to be written once and only once, and for an object not created with new, the destructor automatically gets called once the object falls out of scope. In Java, you have to remember to finally { something.close() } or to try-with-resource every single time. Python is somewhere in the middle on this: because CPython's garbage collection uses reference counting, destructors get called automatically for anything that isn't held by a cyclic data structure, but Python also has with that acts somewhat like Java 7's try-with-resource.
Yeah, it's basically true... most of the major feature additions in the last couple releases really do seem to be to catch up to C# (and other, more dynamic scripting languages). C# as a language is great - it's major problem is being so tightly associated with .NET/Sliverlight/etc.
At least Java has one thing going for it - a highly responsive owner/maintainer that listens carefully to all complaints and patches security vulnerabilities almost instantly!
After all the security vulnerabilities patched this year, I would think they're feeling the pressure to make sure there isn't a repeat.
Normally one would think that, but this is Oracle we're talking about.
In an exclusively garbage-collected language with no deterministic finalization, it isn't possible to do something like C++ RAII, where non-memory resources are closed as soon as an object is destroyed, in Java.
If only we had something like dynamic-wind to deallocate resource we don't need anymore in GC'd languages... Oh, wait, we do!
Ezekiel 23:20
I once built a large rich UI client in Swing, once you embrace GridBagLayout it all works really well.
Swing just has a steep learning curve, and (at least at the time) kind of ugly controls. But it's very functional and not difficult once you understand the system.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
> Has it stopped being an overly-verbose, memory-hogging, slow, insecure pain the ass?
FTFY
Sounds like you got screwed.
I'm a good cook. I'm a fantastic eater. - Steven Brust
You wouldn't run a plugin that runs every compiled executable you come across would you?
Sadly, I have Flash installed. I think its track record is almost as awesome.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Project Lambda from what I have gleaned has as its goal not necessarily feature parity with other programming languages, but instead speeding up certain multicore computations. It is therefore an experiment, and as its coding is not done yet, no one can be sure whether the experiment will be a success. What if the speed-ups simply don't happen once the implementation is finished? Given that Project Lambda may already be delaying some of Java 8, even though it was supposed to be the focus of Java 8, why couldn't Project Lambda be dropped if the experiment fails? There already seem to be so many compromises with the syntax compared to other languages that usage of Project Lambda may not be intended for general programming. Face it, the time to put in the equivalent of Project Lambda was near the dawn of Java, not trying to retrofit it at such a late stage. Perhaps it would be better to shelve it indefinitely as the community never had its heart in the concept.
try something like // would be better a "computed value" here, based on an outer cycle index
{
std::string aux="Dummy message: ";
aux=aux+" hello buddy";
std::cout << aux.c_str() << std::endln;
}
and see how RAII goes.
Questions raise, answers kill. Raise questions to stay alive.
Java has one feature that C# doesn't. This one feature makes up for all the nice-to-have little C# features. That one feature is "portability", not only of the language, but even more importantly, *all* the standard libraries. Mono goes some way to alleviating this but there are some significant libraries that Mono haven't developed and also state (according to their own pages) that they will never develop. I don't know if you have noticed it yet, but the Microsoft is just one platform in the World - and the number of platforms is burgeoning. Apart from a few platforms Java is locked out of deliberately (iOS, Xbox) Java runs pretty much whereever you need to be - with very very little porting necessary (eg. through judicious use of libraries, like JoGL,JOAL, JInput a jet combat simulator I'm developing runs not only with unmodified source on Windows+Mac+Linux+[and some tweaks for Android]; but actually runs without needing a recompile ! [I know it is not true for everyone, but for me, "Write Once, Run Anywhere" really works - even for a very complex multithreaded OpenGL/GLSL real-time application]).
I hope that sheds some light on why some of the Java devs still use it. The nice features of C# don't necessarily make up for Java's awesome portability of *all* its libraries.
I don't (and wouldn't) have a JVM installed so that probably explains why I don't notice it on my desktop. It used to be useful on the server side, but every month that goes by it falls further behind. Java 8 is not going to be significant enough to change that. At this point, the only reason to use Java is because that's what you've always used.
What do you think has replaced Java on the server side? I would love to start using it!
Ever since autoboxing was added, it's already implicitly overloading operators for all of the object wrappers around atomic types anyways, and it's always implicitly overloaded the + operator for the String object, so the objection that it adds complexity should not be an issue. The only real remaining objection about unreadability that always seems to arise when the subject of operator overloading on user-defined classes is raised is actually entirely isomorphic to complaints about function or variable naming practices where the identifer's name doesn't effectively convey any sense of what the identifier's real purpose is... Java doesn't stop a programmer from using global class name like qxj, for instance, so it makes no sense to prohibit operator overloading merely on the suggestion that the resulting program is harder to read or maintain (and even then, such an identifier may even have a legitimate purpose in certain contexts.... but then, so can operator overloading, which is my point)
File under 'M' for 'Manic ranting'
Java 1.6 is the engine for java ee servers such as IBM websphere and tc server. there are still patches for 1.6 coming out, we just installed some at work recently for both the IBM and "Sun" (oracle) jdk
in fact, java 7 is optional add-on for websphree 8.5
No, the vulnerabilities are in Java, not the plug-in. (In Oracles JVM, the Android JVM will have its own, disjoint set of vulnerabilities).
It's just most places Java runs don't have an exposed surface to attack. Server-side Java has had tons of vulnerabilities patched so far - but it was rarely urgent to apply the patches, since there's no access to that JVM from off the box.
The browser plug-in was the way the JVM flaws were eposed, but it was the JVM that had the flaws (OK, the plug-in also has its own set of flaws, as well, but not so many).
Socialism: a lie told by totalitarians and believed by fools.
I'd like to see a Date that can be missing some fields, such as "early january", or "2013" and have the objects be Comparable and yet not forget that their actual value is not exact. For instance, "early" in a month might mean the 5th in terms of comparison, but its toString() would say "early January", and a year without further specification might compare as June 30th.
These sorts of things are helpful when you're recording researched data and don't want the persnickety exactness of the representation to hide the fact that you don't know all the fields.
tone
Probably. Server side Java (where it is used mainly) is pretty much reasonable security wise.
No, most of the Java security flaws apply to server side Java as well. It's just that you usually don't care, because an attacker has no way to exploit the JVM unless he's already running arbitrary code on the box.
Why would anyone enable Java in a browser is beyond me.
Remember all those crappy intranet apps that used to require IE6 and ActiveX? Many were replaced by crappy intranet apps that require Java in the browser. Same stupid, different toolset.
Socialism: a lie told by totalitarians and believed by fools.
IMO, there's no problem with adding language features, but there's a big problem in that new JVM versions aren't always safe to move to! (And you can't use the new language features without the new JVM, of course).
There have been JVM point releases with memory leaks, and with serious performance degradations, in oddball corner cases. If your software happened to live in one of those oddball corners, and you moved to the latest JVM without full regression testing, you were hating life.
So simply moving to a JVM that supports new language features means you need a full regression cycle, which is just not a problem that I've faced with other languages. I've seen builds break when moving to the latest C++ compiler, but never performance or memory leak issues when doing so!
Socialism: a lie told by totalitarians and believed by fools.
Java has one feature that C# doesn't. This one feature makes up for all the nice-to-have little C# features. That one feature is "portability", not only of the language, but even more importantly, *all* the standard libraries.
Uh... yeah, I completely agree, and said so in my previous post in a lot fewer words ;) C# language = great. Platform = sucks.
[Though of course my maintainer comment was complete sarcasm... Oracle seems to be very good at buying companies with popular, often open source products and fucking them up.]
does it break backwards compatibliity with 7, like 7 did with 6?
that's been one of my major gripes about Java, write once, run anywhere until the jvm version changes, then you can be screwed.
I've used both, and I find it much easier to manage threads on C++ than Java. They both offer thread management, it's just a matter of what libraries you're used to.
Similar to "what language is faster to develop in". The language you know well is faster. I spend far less time debugging in C++ (and no time at all chasing leaks, thanks to RAII and Scoped Objects), and much less time worrying about resource management. Once again, because of what tools I'm familiar with.
The one place where C++ is just structurally weak is in making GUIs-coupled-tightly-to-Databases. Static typing and the lack of reflection or an Object class just make Hibernate/Rails/other GUI+ORM development unworkable. Which is one firm reason C++ is better: GUI+ORM development is the most boring and poorly paid area to work in!
Socialism: a lie told by totalitarians and believed by fools.
The only platform that matters is the one your customers run. Portability matters so rarely in business it's almost a non-issue. Now, skills-portability is a different matter, but unfortunately while Java the language is learn-once-code-anywhere, actual Java coding is as much about what libraries/frameworks you've learned as anything else.
Socialism: a lie told by totalitarians and believed by fools.
Apparently something about the one makes the other absolutely impossible to fix. That, or Oracle simply doesnt care.
Either way, "a JRE plugin that wont ruin your network security" might be the most substantial feature ever, if they could hit it. Its all well and good to add new features to the language unless IT security everywhere are working on phasing out java (the client bits) because of its abysmal record...
It used to be useful on the server side, but every month that goes by it falls further behind.
every major programming index shows java at the top. oops. i'll let you google for "programming index" and click on the links.
At this point, the only reason to use Java is because that's what you've always used.
another reason to stick with it is because you like money and having a job. even if java was declining, you'd have steady employment in that space for the rest of your life.
An even more fun game is taking a stab at what Java version your computer has updated to at any one time. I thought I was on JRE 7u12, but I checked and we were up to u17 after a week.
You could probably make a pretty decent calendar out of JRE versions; year = 2006 + $MajorVersion, Week = $updateLevel.
[Though of course my maintainer comment was complete sarcasm... Oracle seems to be very good at buying companies with popular, often open source products and fucking them up.]
but the language is progressing nicely. java 8 has a lot of cool, requested features.
They're adding new stuff. Nothing old is being changed or removed.
Oh, ok, we'll tell that to all the apps that broke with JRE > 1.4.2u9 (ie, Cisco ASA crap). Or the apps that broke with JRE >1.5. Or >1.6u9.
If you havent seen incompatibilities due to java upgrades, be thankful: it means that you havent seen much of java.
Thanks for the clarification. Fortunately with Java there are multiple implementations. OpenJDK is pretty much the same as Oracle (same 'DNA'), but is fully GPL and maintained by the community.
I'm afraid I have to disagree.
And yet your anecdote doesn't really answer my question. If Java was so fast why do all the high performance libraries for things like multimedia not use it? Even the multimedia classes in Java's own stabdard library use native code libraries under the covers because pure Java would be too slow.
Now yes, multi-threading in C++ is of course possible, but it is much tricker than Java, especially the resource management.
I write multithreaded C++ code with Qt all the time. It is absolutely trivial. What is supposed to be tricky?
Then it's a good thing that all code everywhere is written for "customers" in a "business" environment, isn't it?
Well, it's a good approach to earning a living writing code. For a hobby, do whatever - sometimes doing it the hard way is the point of a hobby!
Socialism: a lie told by totalitarians and believed by fools.
I've used both, and I find it much easier to manage threads on C++ than Java.
Same here. Too many people extrapolate their own subjective experiences in using different languages as if they were a universally shared thing. Hell I know plenty of Python and Ruby programmers who find Java to be far less productive in their work.
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
Based on what? Java is rather fast but I have to see any other area of performance where it exceeds C/C++ and quite a few it is well slower than C/C++. The way it handles code is too similar. So by what metric is it "just as fast"?
And no it doesn't get compiled down to the same machine code. Abstraction adds complexity in machine code. That's why Fortran, C and Assembly consistently outperform higher level languages.
If Java was so fast why do all the high performance libraries for things like multimedia not use it?
There are pure Java codecs. They work fine. It is not the C++ that is necessarily fast, but the inline assembler you can put in. In fact, the perfect analogy of using native libraries in Java is when C++ is too slow and you use inline assembler. In both cases you use a higher level abstraction for the huge productivity boost and switch to the lower level abstraction only when you really have to (which is become more and more rare these days) - when you are prepared to sacrifice portability for performance (on a single target). After doing C++ for nearly two decades I hate going back. Java is always my first choice unless I have some other reason (which is getting more and more rare these days).
I write multithreaded C++ code with Qt all the time. It is absolutely trivial. What is supposed to be tricky?
Resource management in a non-deterministic program. Releasing resources neither too early nor too late is problematic. For large data sets this is a problem (I don't know whether you are near the memory limits of your machine, or have smaller programmes) and is why very many modern environments use garbage collection to take the burden of the developer (especially as programs go from large, where any technique can work, to huge).
Once you learn that, and how to use GrdiBagLayout properly then you are 'away laughing'
heh ... laughing from insanity? I think this sums up my experience with Gridbag. I ended up switching to Mig Layout which was a paradise compare to Gridbag. It actually made Swing work fun.
Definitely, and that's a great thing. Though Oracle still has a lot of control over the language - and suing Google for Android wasn't an encouraging move...
I understand many don't like the learning curve of Swing
I've always thought that Swing's learning curve was pretty easy compared to other GUI toolkits. I've got some experience Win32 MFC, wxWidgets, Qt, GTK, Ext JS, Carbon, and Cocoa, and honestly I thought Swing was the easiest one of them to just pick up and start churning out GUIs. But, maybe that's just me. I don't consider learning curve to be an important factor when picking a toolkit unless your goal is to get newbie programmers to just crank out GUIs as fast as you can.
On the other hand, the two things I really hate about it are how it has its own look & feel -- even if you're using the "native" look & feel styles, they're still very obviously not really native GUIs -- and the fact that you need to take advantage of pixel-perfect positioning. I don't want to futz around with that; I want to just be able to drop a bunch of widgets into a window and have them look like they ought to look on that OS.
and some of the overheads (eg. TableModels)
And oh man, I wish I could punch the person who designed TableModel. It's terrible and makes me curse any time I have to make a table in a Swing GUI. Ext JS's Grid / View / Store / Model setup is so much more logical and flexible.
Karma: Terrifying (mostly affected by atrocities you've committed)
When people talk about benchmarks in terms of faster they mean performance not development. In terms of development time, Java gets crushed by much higher level languages. As for projects that aren't CPU constrained but constrained by something else, you are just saying you don't care about performance. That's wholly different than Java having C like performance.
As for multithreaded, C++ is obviously faster. If you want non tricky multithreaded languages like Haskell or Eiffel crush both of them.
And no on a single thread Java is not comparable. It generally is in the range of 1.5-5x slower. Which ain't bad at all, but I have yet to see any situation in which it is faster.
Let me try to explain it:
Java (The language and vm) does in general allow code to do anything. Mess up the system, call native methods and so on. In this it is no different from other languages such as c++ and php, which is why no one are running c++ og php directly in a browser*.
But sun wanted to be able to run Java code in the browser, so they made an security manager, which in principle allow you to specify exactly what parts of the java standard library a program should have access to. So you can restrict file access, to specific sub directories. Control thread and process control, class loading and so on.
So each call to a potential dangerous method first goes to the system manager to ask for permission, and if permission is granted the rest of the method is executed. And here is part of the problem: Default for all methods is access granted if there is no call to the security manager.
So for every method in the Java library, they had to determine if it could me misused, and it it could be misused, they had to insert call to the security manager to verify that the user have access to use this method in this way based on the arguments to the method.
And just one method which don't verify its argument as good as it should is enough to grant access.
The problem is made far worse by the combination of the java class loader which loads classes dynamicly, and the java reflection api which allows dynamic class loading and method calling. Verifying that code can't use the reflection and class loader to bypass the security system is really difficult, as proved by the many security problems.
So when people say the problem is in the java browser plugin, they are not exactly right. The problems are in the java security manager, but I think the browser plugin is the only component which uses the security manager. Our server code for example don't need a security manager to control exactly what our code have access to, because the code is written by guys we trust, and the rest of the security is handled by the system.
*Or at least should not. Active X is Microsofts version of the "Try to run untrusted general purpose code in the browser project". And its security record is as bad as javas.
Well you can't say Java has flaws and then detail one particular set of flaws in one product. Even then your claims that the flaw is in the JVM is doubtful. I can right now load up a Java program in Oracles JVM and delete my files off my hard drive. I can also straight up spin up 100000 busy threads and bring my machine to a crawl. Are these flaws? Of course not. I can do the same thing in C++.
The flaw is allowing the browser plug-in to do things it shouldn't. The JVM itself is supposed to allow you full functionality including the ability to shoot yourself in the foot. The flaw is the fact you've exposed the JVM to the outside world. The Applet Plug-in tries to limit this functionality but fails. That is not the fault of the JVM.
Cool. Thanks for the tip on MigLayout. If I can't ever get GridBagLayout to work for me I'll definitely take a look at MigLayout.
Funny video. I guess changing things at random is what most GUI coders do, right? That's not my workflow - but I can see how GBL would suck until you learn all the aspects that make a layout work and resize properly.
At least you seem to be in the camp that Java on the desktop still has some uses :)
and suing Google for Android wasn't an encouraging move...
Fortunately the suit is over and Oracle pretty much learned their lesson. OpenJDK is safe to use and rely on (no vendor can kill it).
Well said. I tend to make a bunch of mutable classes (eg. a MutableTableModel) that I use as a base class. It's still stinky that in order to create a decent table you need some custom classes. But for me the degree of control is worth it. I like what you can do with styling with JXTable too.
Yummy, yummy!
Bro, your 1.5-5x is just not true unless the Java was written by idiots (and as we old timers remember the chestnut, "You can write bad FORTRAN in any language"). Even in 2008 Java was beating C++ and approaching FORTRAN for speed, citation follows. Now you can cherry pick whatever benchmark you want and it will show C++ as faster, and I'll choose another benchmark and that will show Java as faster. That means they are about on par with regard to performance (that wasn't true in the past, but is true today).
Here's the citation about the "Current State of Java for High Performance Computing", written in 2008 (the JVM has got *much* faster since then):
http://blogs.oracle.com/jag/entry/current_state_of_java_for
Please note that the report was written by INRIA, the French Scientific Supercomputing outfit - it is not a fluff whitepaper from a vendor (who will lie to make sales). If you can flaw the INRIA paper I'd be very interested to hear why you are right and they are wrong.
When people talk about benchmarks in terms of faster they mean performance not development
If your development time is so long the project stakeholders may cancel it. That is the major cause of software development failure. If you time to develop is long your time to market is also long. That can mean missed opportunity and even business death. So the long development time might be appropriate for the toy QT programs you develop, but it completely blows for large commercial projects where you have a big team and the set of people who start a project may not be the set of people who finish (people get pregnant, get sick, get promoted, all sorts of stuff). Once you start looking past just the purely technical stuff you have quite a different view of technology. That's why few people choose C++ to start a project these days.
In terms of development time, Java gets crushed by much higher level languages.
I find that most of those higher level languages tend to be fairly good at one domain. They are faster to develop in, if you are doing the problem they were designed to solve, and then they suck. The runtime performance of higher-level language blows. eg, Groovy, Ruby, Python are not in the same league as C++/C/Java/C# etc. For most modern applications it simply doesn't matter anymore, because you are waiting for a database, or the network, or user input (**slow**), or the GPU, or the memory bus, etc etc. It is only if you are stuck doing batch operations that it really matters. Now I'm waiting for you to say, "but, but, multimedia!". The reality is that multimedia should be done in hardware. I use Java+JoGL+OpenGL for this. This destroys C++ (or any other software implementation) for performance. Horses for courses my friend. That's why few people use C++ anymore - we understand it well (used it for decades) - but realise that implementing a new commercial application with it is just duh stooopidd.
FUD:)
Not over yet, actually. If Oracle had really learned their lesson they wouldn't have appealed. I doubt they will win, but as I said it's still not an encouraging move.
But yeah, OpenJDK is not going anywhere, and the support behind it dwarfs even Google's resources...
Hmm...
Gridbag layout is simple, once you learn it and are _DISCIPLINED_.
I would hate to try and devise an alternative.
I have made major use of it in at least 2 commercial project.
Gridbag layout is great for some GUI problems, I would be more than happy to use it again.
Of the top of my head:
I like Java as much as the next Java programmer, but the picture isn't that rosy when it comes to things needing real performance. C++ provides quite a few tools that can blow Java out of the water, purely because there's no runtime overhead and you have deterministic overhead. Add in the ability to manage cache line access and C++ will quickly run away with the title.
C++ doesn't make you pay for anything you aren't using and offers quite a few tools that allow micro-management of performance in a way Java simply cannot.
It means I haven't seen that much bad Java code.
Java is *not* compiled to native code unless the JVM decides it should be.Not all byte codes are compiled, it is faster to run it as interpreted code if you're only going to run the code a few times.
Also, not all JVM's have a JIT compiler.
Most bytecode is not compiled since it is not run frequently. Why do you think the JIT compiler is called HotSpot? It compiles hot spots of code in to machine code.
The code also isn't necessarily compiled in the same thread that the code runs it. A larger large loop will probably run quite a few iterations in the interpreter while the code is being compiled to machine code, once that has finished, the machine code is run instead. The last thing you want is more unpredictable latency in your application. You also don't want one thread stalling while it waits for code to compile when there may be other cpu's sitting idle.
* Java's GUI toolkit (swing) allocates memory all over the place meaning all the hard work you put into a no-allocation loop in your code is wasted when using a JTabbedPane allocates massive amounts of memory just by moving your mouse over it.
This is true if you are dealing with smartphones. In that case GCJ is an alternative, or C++. However, it is hard to find a *current* system that is so memory limited that this is an issue.
* Related to the point above - in code with strict scheduling deadlines, you can't use dynamic memory allocation (this goes for C++ as well as Java), but using any of the standard Java libraries and/or objects allocates memory all over the place. You can use things like the Javolution collections to get around these issues.
Multimedia is soft realtime. You simply spend memory to read ahead. If you are talking about controlling stepping motors in software (which I've done in the past), then it is a problem. If you are controlling stepping motor device driver hardware then it is not a problem. Sorry, I just can't see a case where you need a hard realtime requirement and C++ would make a difference compared to Java. You would always do any hard realtime in hardware when you are worried about microsecond jitter (since it is the *operating system* that screws your jitter up, the difference in userspace Java vs C++ is neglible if you have idle cores ready to respond to work)
But let us suppose for a moment you do have a hard-realtime requirement in your software. Then I would say, "Go ahead and use C++ if you think it would make a difference". It turns out that the amount of software that would fit this niche is small and getting smaller. But again I will remind you that the difference in determinism between C++ and Java is negligible if you have ever cared to measure them on a modern desktop O/S. It is the O/S that is the major source of jitter that will break your realtime requirements, not the software stack you are using.
* Java suffers from predictability problems. Jitter introduced by the system management threads and mutexes causes stalls to threads that you have no control over. There is a realtime Java VM, but it's not really "Java" as you can't use standard Java libraries and classes.
All multi-threading systems suffer this, do they not? This is one of the reasons that increasing the number of threads does not increase performance linearly (in general) even if you have one core per thread. However, the efficiency loss of multi-threading doesn't matter because total throughput increases. As I mentioned in my earlier post, having 8 cores at 20% utilization has vastly better jitter than the comparable single threaded C++ program in the same niche (DCS:World). I would assume that there are plans to add threads to the C++ codebase of that product, but I would imagine it is so complex to do (retrofit to an existing C++ program) that even after several years it has not yet happened. One cannot simply dismiss the superior language constructs for synchronization when it comes to development effort. By having these (portable) language constructs it makes it easier to get massive multi-threading working correctly in Java relative to C++, and hence the jitter goes down and total throughout goes up. Conclusion, for less effort you get better total throughput with Java (assuming your problem can be parallelized; as most complex applications can).
* Java doesn't allow management of packed arrays of structs. This means you can't do things like cache optimization of data structures. You can kind of get there by using nio buffers and ugly map to offset style things, but it's just ugly and unwieldy. Cost for no reason.
I'm glad you concede that NIO can solve the problem. Yes, they are slightly unnatural compared with the simplicity of most of Java. However, I would argue that they are a lot more safer and portable than fudging around with poi
When first reading your comment I though wtf?! After the second time I knew it must be sarcasm.
Please login to access my lawn
The Applet Plug-in tries to limit this functionality but fails. That is not the fault of the JVM.
Except that it is running the standard JVM security sandbox, which explicitly does not perform as it is supposed to, when it did in previous versions. The thing that changed is the new extensions to the reflection APIs, and those changes are definitely in the JVM / Java language / standard library realm. They are not peculiar to the plug-in, which is simply a consumer of the sandbox security model.
C++ objects also have an header/overhead. Where do you think the VTAB (virtual function table) is referenced?
With more I mean ofc significantly more. If I have a million objects and each of them has 4 extra bytes, that is 4 mega byte ... not much imho.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Unnecessary memory allocations increase the cache pressure on the CPU introducing extra memory stalls and forcing the VM to interrupt threads.
You seem to neglect the importance of low jitter - and you're writing a game? I write audio applications and have my prototyping in Java, but the real application in C++. I've measured the difference, and it's night and day. Java introduces another jitter source (VM stalls due to signals for housekeeping) that dwarf OS level jitter. It's not just a case of turning on the parallel garbage collector, either. Your threads still are interrupted. No such interruption occurs with native threads - even on a non-realtime OS.
I have measured it. Lowest audio output latency with Java in no-allocation loop is around 40 ms on a core2 2.4Ghz - same machine with C++ and I'm down in the sub-milliseconds. It's that big a difference.
You seem to have the idea that C++ is "C with objects". Threads in modern C++ are no more difficult to use or pool that in Java. But C++ threads won't get blocked unless you choose. Modern C++ has better granularity with synchronisation primitives too - with varying levels of relaxation for atomics. In C++ you get to deal with the actual primitive - not an abstracted Java Object that's increasing the pressure on the CPU cache.
Again, you've missed how modern C++ deals with packed array structures. Us
You seem not to know what the word magnitude means. ...
It means: by a factor of ten.
The libraries you mentioned are written in the languages you mentioned because they are used by said languages.
E.g. see colt: http://acs.lbl.gov/software/colt/
The rest of the stuff like 'multimedia' makes no much sense as this is all build in into the Java environment and if younuse it you are calling the C functions implementimg it
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Unnecessary memory allocations increase the cache pressure on the CPU introducing extra memory stalls and forcing the VM to interrupt threads.
I intend my processes to be interruptable. That gives me low jitter.
Lowest audio output latency with Java in no-allocation loop is around 40 ms on a core2 2.4Ghz - same machine with C++ and I'm down in the sub-milliseconds. It's that big a difference.
That is a big difference indeed. Is it possible for you to go into a little more detail of why you get 40 ms in Java? How granular are your units of work.
Well, I'm sure it's good enough for you, but when you start putting some actual logic into your flight sim for your fluid dynamics and attempt to do this with low latency you'll start to see the jitter problems with Java.
Nobody solves the Navier Stokes equations in real time. Flight models are surprisingly light weight (in runtime use, not in complexity) in fact there used to be a demo using the NASA F-16 flight model in very old versions of Java that ran very smoothly (one of the old JoGL demos on an old JVM and old machines, and ran beautifully). Again, I think you are buying into a myth that C++ is required for even something as heavy as a flight sim (where a lot more than mere flight modelling goes on).
Where I see jitter is in the IEEE 1278.1 comms. The jitter is caused by the network - and this is vastly below the latency across the intertubes. I also use a dead reckoning algorithm to compensate for dropouts, latency/jitter spikes. Please also note that at a 60 Hz frame rate a human cannot distinguish any visual activity that occurs faster than 17 ms. In general, most people are ok to around 40 ms. It is only when you get spikes much longer than this that people notice. So that is why your result seems surprising. Another interesting metric is that to render a quarter-million triangle F-16C Block 52 model and a GLSL shader physics based atmospheric transmission model with a Intel 2600k chip and a Radeon 5970 (dual-GPU, but quite old) I can get over 700 fps (limited by the GPU, not Java and not the CPU). The CPU core responsible is mostly twiddling its thumbs during this activity. The other cores have more work doing the network protocol and aerodynamics, but it is all pretty light weight (all AI activity is performed on the server, so the client machine doesn't have much to do).
There's a reason that modern games are still written in C++ rather than a managed language - when you need to extract performance in a predictable way you want determinism. Managed languages can't provide that guarantee.
The IL-2 Sturmovik simulator was mostly written in Java. It did use C++ for heavy lifting because the JVMs of the era were slow. That is simply not the case anymore. Minecraft is a very popular multiplayer game written in Java. Bohemia Interactive's Take On Helicopters and Armed Assault III have Java APIs for modding, so at least some parts must be in Java (even if an integration layer) - which means when you attach Java it still runs with acceptable jitter (because of course, the jitter is determined by the 'weakest link' not the average of components). And as I will repeat, my *experience* with using Java for a game is that the CPU-components run as smooth as silk and I have low jitter. The CPU is always waiting for the GPU (in fact, some of my synchronization is doing deliberate yields [introducing jitter] while waiting for the GPU to be ready for the next frame).
So, the fact that you are having *huge* 40 ms latencies sounds *extremely* fishy to me. So I'm curious about what you are doing that makes the latency so enormous. I'm saying latency here based on the word you used. You do know that jitter is variation in latency yes? It is jitter that is the killer, not latency. Both jitter and latency can be compensated for by proper buffering, of course. Are you streaming from disk without any buffering or a
One thing I forgot to mention. You've seen the JOAL library, yes? That's what I'm using for audio. Works great. I get to stay with the niceness of Java, get 3D sound effects, and its portable. As I mentioned in an earlier post, the strength of Java is in its vast wealth of libraries.
All the games you mention bar Minecraft have a native core engine that isn't written in Java.
Minecraft itself isn't exactly a good advertisement for Java performance in games - and I'm not blaming Notch for that. Most of the bad press it gets performance wise is due to VM stalls.
I suspect the jitter is below your perception level since the GPU is doing the heavy lifting.
In my case I have Java DSP code generating audio samples - no filesystem reads / writes. Floats are generated as a block into the NIO buffer.
I'm using JavaJack as the audio connector to Jack - the standard Java audio engine is terrible.
Basically Jack DSP thread makes a callback that provides NIO buffers to do the DSP calculations and place the result in (simply generating a 440hz sine wave, for example). The lowest output latency I can get with Java without jitter causing pops and clicks is about 40ms (1024 samples * 2 periods) as I mentioned. I've verified zero memory allocations and turned off UsePerfData too (UsePerfData can cause VM stalls due to the mutex around writing the performance data).
When tracing the VM using sysprof I can see the VM is trapping a signal to do it's housekeeping every X iterations which halts all running threads. This is on both OpenJDK1.8 and Suns JDK 1.8.
Using latencytop on the machine at the same time shows the VM spending time in userspace lock contention and waiting for events (timeouts for the housekeeping threads).
I notice you didn't mention realtime Java. I'll ask again - if the Java VM doesn't have jitter - why do the realtime specification and VM's exist? (since realtime is all about predictability).
Funny you mention that - as the DSP isn't happening in Java.
But that's not a java library - it's a java veneer on top of a native library.
They're adding new stuff. Nothing old is being changed or removed.
Actually the old JavaScript engine is being removed and replaced with a completely new implementation.
Given how many undocumented hoops you had to jump through to do anything useful with the last one, I'm really not looking forward to this.
The Oracle HPC paper put the overhead at 1-1.5 (i.e. Java at 40-50% of the gcc Fortran version). They used Fortran as a benchmark for Java. There were no areas of outperformance and that was with a rather mediocre Fortran compiler. Your own paper doesn't support your theory. Choose a benchmark favorable to Java and in many areas it does well.
If your development time is so long the project stakeholders may cancel it.
I'm not arguing development time isn't important. I'm arguing what the word "fast language" is not about development time. Cars are important, refrigerators are important. The fact that a fridge is important does not make it a car.
The runtime performance of higher-level language blows. eg, Groovy, Ruby, Python are not in the same league as C++/C/Java/C# etc.
Of course not. But this is you conflating measures again. Your point was about development speed. If you are saying that Java is a good compromise: you get development speed faster than C++ without taking order of magnitude performance hits and pick up mostly cross platform; I'd agree with you. If you claim that Java code is as fast as C++ then I disagree. If you claim that Java is fast to develop in compared to most languages I'd disagree.
if you are doing the problem they were designed to solve, and then they suck.
Now that being said all languages are stronger in some areas than others. Languages to survive have to find niches where they are particularly well suited, which means such niches exist. The things that make Java safer than C/C++ for commercial development are the things that knock it out of the game for systems programming. The things that give Java performance within an order of magnitude of C/C++ are the lack of abstractions that can kick development times up by almost an order of magnitude over high level languages.
Just to pick a simple example where Java is a problem... C++ is far better at dealing casually with data structures at the bit level where the packing / unpacking needs to happen fast. I wouldn't want to try and write a router in Java.
With the exception of pretty good cross platform, Java is a compromise. There is a lot of advantage in the standard language being pretty good at a lot of things and not fantastic at any of them. But let's not pretend this tradeoffs aren't happening.
In theory, yes. In practice I've had problems with java programs being very picky about which runtime they need.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I remember writing my own subclasses of borderlayout and flowlayout to get more sane cooperation between the two. It worked very nicely but was a bit ugly because there is no good way to extend the interface between nested layoutmanagers and getprefferedsize is too limiting an API to do what I wanted.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The thing is that applets should die. I am a java dev. But i don't understand this big deployment on the web push. C/C++ don't have it and do just fine. I have applets/ws disabled long before this list of security issues.
If information wants to be free, why does my internet connection cost so much?
Great argument guys ... It's a pleasure to read two very intelligent people discuss the pros and cons of languages without devolving into feces tossing. It's kind of rarity these days.
Hats off to both of you!
Well, you got a +5 :) but your assumptions about a security manager works and how amd where it is used: are completely wrong.
It is trivial to write a Java Application thatbuses a security manager and thus, e.g. restricting it from accessing the internet or certain parts of the file system.
Your idea that dangerous methods call the security manager is completely wrong. The VM calls the security manager before said method is executed.
Your assumption that the VM inserts the security manager code is wrong. See, for instance, the source code for java.io.FileInputStream(File). You can clearly see starting at line 128 and continuing to line 131 that this check is performed by the library, not the VM. Similar code is present throughout the Java standard library.
The VM will need an update to perform the linking of default methods in interfaces. Other than that I think you're right; it certainly looks as though the lambda function stuff is implementable from a purely compiler perspective (although whether that's how it has actually been done, I don't know).
My IT department is still running Java 6 update 5 from 2008. They're too scared to upgrade to any later update levels because no one is going to give them the money to regression test every piece of Java code we've got.
If they'd demanded automated tests of every functional requirement (which has been a standard best practice since some time around the mid 90s, so they aren't likely to have any Java code hanging around from before the industry woke up and realised how important it was), it would be less than a day's work to perform those regression tests, and would likely not take more than a few more days to fix any problems found. The new features would probably make the effort pay back in less than a month.
But they clearly ignored industry practice, presumably in the name of economy and getting the job done quickly, so you're stuck with an unmaintainable obsolete code base. And are probably still writing legacy code today.
The per-object overhead for Java's Hotspot VM (at least the 32-bit version) is 8 bytes. The per-object overhead for C++ objects compiled with most common C++ compilers for a 32-bit architecture and using virtual methods with public inheritance is also 8 bytes (1 vtable pointer, 1 vftable pointer).
From a quick read it seems they are putting in all the hip new shit while still leaving out basics like structures without implicit pointers, parameter pass by reference/multiple results (no allocating an object on the heap only to throw it in the garbage immediately doesn't count), operator overloading, Unsigned primitive types (other than char) and so-on. Properties (no some stupid convention doesn't count) and so-on that have been in languages like object pascal for years.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
If this were really true why are all the high-performance multimedia, mathematics, etc. libraries all still written in C, C++ or Fortran? That's because Java is still magnitudes slower.
Java is slower for these applications because of a few choices made early in the language design that cannot now be undone. One of them is that portability of code is more important than performance, and that therefore mathematical operations must have exactly specified results -- with the result that Java cannot use processor integrated implementations of transcendental functions, among other issues, meaning any code using exponential functions, trig functions, or logarithms runs about 10-100 times slower than native implementations. But you will get the same result on any platform...
But for general purpose logical data manipulation, like 90%+ of real world code, Java is just as good as any other language.
And from the programmer's point of view, it requires constant education
Boo hoo hoo.
Anyone who finds an incremental addition of a handful of new language features every 4 years to be too hard should honestly go into another profession. If you went into computer programming, you signed up for learning new things at least a couple times a decade. If you don't want to learn new things and you insist on programming, I guess teach yourself COBOL and you should be in good shape.
Though there are 7 major versions of Java, only two of them added any language features to the source code (5 and 7). The rest of the releases did nothing more than add standard libraries, garbage collector fixes, other jvm optimizations, etc. And every single change to date has been backwards compatible. You can take code you wrote in 1997, compile it today, and it will run at least as well as it did then
I would say it differently. For all programs, Java has a memory overhead of tens of MB that a comparable C++ program would not have. It's got to run that JVM, and there's no way around that.
The difference is that a C++ program that's 2MB in memory might use 50MB in Java, but a 300MB C++ program might be a 350MB Java program. Java will always use more memory. It's just that overhead is fixed and becomes less meaningful on larger programs.
You're still talking about implementation details. The point is that the overwhelming majority of run time of Java applications is spent in native code (two levels of optimization, C1 and C2, in the dominant implementation), a minority (10%?) in interpreted code, and less than 1% in memory management routines. The major deficiencies of extant runtime environments for Java are: 1) native code being thrown away when the process is terminated, increasing the startup time, which mostly hurts short-running processes, 2) latencies in memory management, which is fixed by the use of efficient GC strategies like Azul's C4.
The actual reason why multimedia applications in C++ are faster is the hand-written assembly routines or C/C++ routines written using CPU intrinsics being used all over the low-level libraries (codecs, image processing and signal processing code etc.). No compiler is going to help you there, although an extension of Java for writing intrinsics in Java code isn't inconceivable.
Ezekiel 23:20
But that's not a java library - it's a java veneer on top of a native library.
Unless you're using an extended version of Java that supports the constructs you'd need to communicate directly with the hardware, i.e. pointers to arbitrarily-allocated memory blocks, and I/O instructions, so are you. Java isn't designed as a hardware interface, so you have to use a native hardware interface for such tasks. Is this really a surprise?
I actually think all the C# language features are starting to be a problem, and one that will only increase over time. First, let me say that I see C# as being too quick to adopt language features. They often seem to throw things in for no other reason than because one other language they saw does it, and they don't always fully think through the ramifications of the language feature.
Here's an example. Properties. I get why they are popular, after all if you've had it rammed into your skull a hundred times that you should not make member variables public (an overused trope in my mind) you'll love a one line statement that is both getter, setter, and member variable. Great. Except, Properties are neither methods nor member variables. I can't pass a property by reference into another function. I also can't pass a property around as a function pointer either. Sure, you can work around this using lambda expressions, but that doesn't change the fact that a property is actually disfunctional and worse in many ways than either of the two language features it's supposed to replace. Worse yet, as soon as you need to customize it, the resulting code ends up just as wordy as the getter/setter code would have been in the first place.
My rub with C# is that today all these poorly considered features are manageable. But I see a time maybe 10-15 years out when the language will just be bloated with features that no longer fit together well enough for anyone to want to use it. Which, is of course not an argument to avoid C# today. rather it's an argument that C#'s model of rapid adoption migh not be ideal for other languages out there.
You've listed some languages that mediocre programmers use; now would you please share your opinion on what languages great and exceptional programmers use?
That that is is that that that that is not is not.
You are right in tis case. Hm, uncertain now if this is so because that code is very old, or if I was completely mistaken myself.
I have to check that again ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
That is, what I said: for non trivial programs. And the difference is not 50MB it is far less.
The smallest Java process I had so far was a tomcat running in 16MB memory. Ran just fine. However that was Java 1.4 and an early tomcat.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I notice you didn't mention realtime Java. I'll ask again - if the Java VM doesn't have jitter - why do the realtime specification and VM's exist? (since realtime is all about predictability).
Yes, realtime is all about predictability - not throughput. The VM has jitter, just like the operating system. The JVM spec is so you don't miss deadlines, no matter what you scheduled period is.
Did you perchance use JVisualVM to look at what your program was doing? what was it doing when spending time? sometimes the hotspot will become obvious (eg. a library call that you can use a faster alternative to).
When tracing the VM using sysprof I can see the VM is trapping a signal to do it's housekeeping every X iterations which halts all running threads. This is on both OpenJDK1.8 and Suns JDK 1.8.
What was the delay? It should have been sub-millisecond. It is definitely not the source of the 40 ms delay that you see.
I'm not sure whether you are aware of this, but to get low jitter you must yield. Otherwise you get a thread hogging the VM and it doesn't get a chance to do its housekeeping. You can get better performance by putting a try { Thread.sleep(1) } catch(InterruptedException ex) { // Ignore the interruption } in you main loop. That yields and lets the VM, other apps, operating system do their housekeeping periodically. If you don't do this it appears the VM will give you more CPU but then pulls the rug out from under you when it can no longer wait to process all the things it has accumulated. By introducing a little jitter you stave off large pauses. This worked for me, at least, and I couldn't believe how simple it was to do.
But that's not a java library - it's a java veneer on top of a native library.
And C++ is a veneer on top of some hand-crafted assembly in its library. And all are a veneer over whatever was used to build the operating system. The argument is not particularly relevant. The reason it is a veneer over a native library is that the native libraries already exist and are being re-used - this is common pattern for all application level languages.
The Oracle HPC paper put the overhead at 1-1.5 (i.e. Java at 40-50% of the gcc Fortran version). They used Fortran as a benchmark for Java. There were no areas of outperformance and that was with a rather mediocre Fortran compiler. Your own paper doesn't support your theory. Choose a benchmark favorable to Java and in many areas it does well.
I believe the debate was whether Java was faster than C++. In some areas Java is faster than C++. Nothing is faster than FORTRAN (which is the reason it is still used for time critical applications). This is due to FORTRAN's lack of things like pointer-aliasing that prevent some optimizations in C++. The paper supports my point :) ... and the JVM has only gotten faster in the last five years.
I'm not arguing development time isn't important. I'm arguing what the word "fast language" is not about development time. Cars are important, refrigerators are important. The fact that a fridge is important does not make it a car.
Sorry man, I don't grok the intent of the last sentence. Could you please clarify?
you get development speed faster than C++ without taking order of magnitude performance hits and pick up mostly cross platform; I'd agree with you.
That was my point. So, happily, we agree. For enterprise work the speed to develop is usually more important than the runtime performance (although that can't suck too much).
The things that make Java safer than C/C++ for commercial development are the things that knock it out of the game for systems programming.
Not really. The reason Java is not used for systems programming is that there are good enough languages already in systems programming and an enormous legacy codebase that you would need to integrate with. In theory you could write an operating system in Java (with a sprinkling of C/assembler for register access; just as the Linux kernel has a sprinkling of ASM, IIRC). The reason Java is not used is not because of performance, it is because replacing the millions of lines of C just to change development language is not sufficient.
Just to pick a simple example where Java is a problem... C++ is far better at dealing casually with data structures at the bit level where the packing / unpacking needs to happen fast. I wouldn't want to try and write a router in Java.
I've done lots of device control in Java where I had to do bit-level packing and unpacking (eg. controlling traffic speed radars, shift-register based LED signs, NTCIP signs, control the timing registers and readout of astronomically priced astronomical CCD cameras, control GPS clocks, etc). Java was perfectly fine and perfectly performant at this. You can't write any old Java and have it perform well. You do have to use the profiler to check you are not slowing anything down (fortunately the awesome JVisualVM comes free with the JDK, or can be downloaded separately from http://visualvm.java.net/).
With the exception of pretty good cross platform, Java is a compromise. There is a lot of advantage in the standard language being pretty good at a lot of things and not fantastic at any of them. But let's not pretend this tradeoffs aren't happening.
All engineering is about compromise. I'm not saying Java is the perfect language in any domain. I'm saying that it is a good-enough language for any domain that makes it sensible as a first 'go to' choice. IMHO you should won't go wrong if in your solution architecture you select Java as your choice of development language and only then consider other languages if Java is inadequate. The benefits of re-use of your existing Java code, and re-use of the huge number of libraries (for just about any problem domain) outweigh (IMHO) many of the alternatives. In my work I have never encountered a performance problem with Java
Many thanks :)
I believe the debate was whether Java was faster than C++. In some areas Java is faster than C++.
The original claim was more broad. If you want to limit to C++ then the issue comes down to speed of libraries. C++ libraries can emulate the efficiencies of Java libraries but the reverse isn't always true.
Sorry man, I don't grok the intent of the last sentence. Could you please clarify?
The intent was that the term "faster language" or "better performance" applies only to runtime performance. That doesn't mean that only runtime performance is important, but the meaning of language is specific.
For enterprise work the speed to develop is usually more important than the runtime performance (although that can't suck too much).
I agree. For enterprise work most of the time the system is I/O constrained and runtime performance may not matter much at all. Further hardware costs are low relative to development and maintenance costs. Java is no question a better choice than C++ all other things being equal. Though I'd go much higher level than either one for enterprise applications.
I'm saying that it is a good-enough language for any domain that makes it sensible as a first 'go to' choice.
I would agree with that if you replace "any domain" with most domains. I think the lack of abstraction and isolation of state in Java is a serious problem for things like big data work or massive parallelism. It is far too difficult in Java in practice to see which operations are by nature associative. I think the lack of void pointers is a serious problem for low level hardware code, as I mentioned in the last post. I think the complexity of writing a Java compiler makes it a terrible choice for constructing DSLs.
etc...
I think the complexity of writing a Java compiler makes it a terrible choice for constructing DSLs.
Well, you have a choice of Groovy or one of the other languages if you must invent a DSL for yourself. The performance hit of those generally is noticeable.
Groovy isn't bad like most dynamic languages. Generally though for a DSL you want custom primitives on top of some sort of complex primitives hiding them. Ease of constructing the compiler, and the apply/eval loop, i.e. a Scheme. is more important than almost anything else.
What would be a highly desirable feature in a browser is a way for the user to have to approve any plugins which are installed from outside of the browser. Absolutely *ANY* plugin installed from outside of the browser should, by default, be disabled until the user manually enables it from inside the browser's own plugin manager tool.
File under 'M' for 'Manic ranting'
Or as someone else put it: "one of Java's biggest strengths is that it limits how badly mediocre programmers can screw up the code" ;)
You're still talking about what happens in benchmarks, not real applications.
Most code is *not* compiled by the JIT compiler.
Some code may be compiled several times in different ways.
Java is an application language. You build applications with it.
C is a system language. It was designed to build operating systems.
Use the right tool for the job. Gold makes a poor quality, easily broken hammer.
No C++ compiler will produce code that takes advantage of technology that hasn't been built yet. A runtime compiler can. It also won't provide guarantees that the code I design and develop and test on my PC will run on a mainframe.
As long as you used the ScriptEngine interfaces correctly, you'll be fine. Nothing stopping you from continuing to include Rhino though. It's built and maintained by Mozilla.
You're right, I am still writing code for a system that was built in the late 90's. It pays very well too.
As far as I'm aware though, there have been no issues with upgrading all the way from Java2, 1.3, 1.4 and 1.6
As for fully automated testing, yes it is a best-practise. It also seems to be one that is never applied.
The last from-scratch project I worked on did start writing automated tests. They had one tester allocated to that.
They had ~30 testers at one point doing manual testing.
While the automated tests did end up covering a fair portion of the system, it would still take a week of a half a dozen testers to run the manual tests.
This is something I've seen over and over. Why do you think it's true?
I don't expect some sort of mathematical proof, but I haven't even seen an *argument*. One day I read some comments on the internet and suddenly it had been declared: developing in Java is slow. What happened? I missed the part where we all figured this out.
I've written web applications in Java and Ruby on Rails, among several other platforms. Ruby on Rails was *beautiful*! I had to type far fewer characters to implement simple web application behaviors in RoR than I had in Java. Its elegance was the cause of several changes in my employer's own internal Java-based web framework.
But although I had to type fewer characters using RoR than in the Java framework I was used to, typing characters had never been the pain point. I know how to define simple value objects that represent rows of a database table. No problem. I know how to do SQL migrations. No problem. I know how to validate form submissions. No problem.
And so on it went for every supposed advantage that Rails gave me. I had already solved that problem; I haven't spent significant development time on that problem for years. The real *meat* of the application (what separates it from CRUD apps) and *maintenance* were the pain points for every application. Rails didn't help me there at all. I've worked with other supposed "higher level" languages, and they didn't help with the meat or maintenance either. They all seem weirdly focused on saving characters.
In the process of saving characters, many "higher level" languages sacrifice things like static typing that an IDE would have been otherwise been able to capitalize on. With a Java IDE I usually type a single character before it figures out what I meant (based on the context, which it could only infer because of static typing) and then I click my mouse or press some key to accept the auto-completion. Or maybe I wanted to define getters and setters for some fields, or do some other mundane task that's supposedly verbose in Java... it's most likely that the IDE has a keyboard shortcut for that.
I'm pretty tired of hearing the "faster development time" argument. Put up some proof, or evidence, or anything.
> Did you perchance use JVisualVM to look at what your program was doing? what was it doing when spending time? sometimes the hotspot will become obvious
Yeah with various tools (jprofiler, visualVM, sysprof, strace, latencytop etc).
The problem with running Java profiling tools is that you have to leave UsePerfData on - and it's a cause of jitter in the VM itself.
The code is as optimised as you can get - I'm bypassing the "helper" classes included with JavaJack and using the raw mapping to Jack C API.
When running the program is at about 2% of CPU - so it's not a CPU starvation problem. I've run it under both regular and realtime linux - the linux thread priority is set by Jack itself as high - and I've tried setting the other threads in the VM to lower priority by native C calls. No dice.
> What was the delay? It should have been sub-millisecond. It is definitely not the source of the 40 ms delay that you see.
The problem I think is that it's competing with the compilation / profiling and housekeeping threads for CPU, and the VM can halt your thread whenever it feels like the profiling data or other things need updating.
I should mention that I'm outputting two periods of 1024 samples - so Java is in effect failing to meet a 20 millisecond deadline every now and then.
> I'm not sure whether you are aware of this, but to get low jitter you must yield.
I'm not very happy with this being a solution - if anything it shows the model is broken itself.
I can't even try this - the callback thread is created inside the Jack shared library - and "enters" the VM when it needs to do a callback. I can't block or do anything other than simply try and return the data needed by Jack in this thread.
It's been an entertaining discussion - but I think we're at an impasse - I think I've demonstrated some scenarios in which Java either lacks expressive tools or fails to offer the same guarantees that native C++ can offer.
Please don't forget - I am a Java developer - I'm not poo-pooing the language with bias - but realising the limitations of the tools we use is important in being able to identify the situations in which the tools are appropriate.
Cheers
This is something I've seen over and over. Why do you think it's true?
Originally this came from early studies from IBM in the late 1950 and early 1960s. What they measured over and over is that developer productivity in teams, on average, was in lines of code almost regardless of language. The less lines of code needed to express a problem the faster developers were able to solve problems. That's why they went from advocating Fortran & COBOL for limited classes of programmers to instead advocating them for most programs regardless of class of programmer.
There still are performance shootouts happen regularly, and people still see the same effects. The functional languages crush Java / C / C++. The dynamic languages crush Java / C / C++ in writing programs. There have been studies of developer productivity you see this all the time. I can start citing articles but people believe it because there is over 50 years of research repeated again and again showing it. What you are calling "less characters" really really matters.
You wanted some evidence so just to pick an example, and you google and find dozens: http://sequoia.cs.byu.edu/lab/files/pubs/Delorey2007a.pdf
They tested 19,000 code based from Sourceforge in 2000-7. And found the typical result statistically that programmers were more or less producing roughly the same amount of lines of code per programmer per month.
And so on it went for every supposed advantage that Rails gave me.
Rails isn't designed to make solving hard problems easier. It is designed to make solving easy problems easier. Where Rails makes solving hard problems is because of Ruby not because of anything particular to Rails.
I've worked with other supposed "higher level" languages, and they didn't help with the meat or maintenance either. They all seem weirdly focused on saving characters.
I think you need to separate those two issues out.
Static typed variable languages are far easier better in terms of maintenance. The research here is clear cut, that there is a substantial long term maintenance penalty for dynamic. If you want to do a comparison for static, high level look at something like Haskell, OCaml / F#, Scala, Clojure...
Now in terms of meat... here I would say Ruby is likely to be helpful providing the "meat" falls into Ruby's sweet spots. That is "meat" where the abstractions in the program work well with Ruby's abstractions. If they don't then of course Ruby isn't going to help. Worse, Rails pulls against this because it brings with it, its own set of abstractions that often limit Ruby. Rails is a bad fit for most complex projects.
In terms of your personal experience, programmer experience matters. If you are much more experienced in Java your lines productivity will go way down at first in a new language. Moreover your productivity might take years to reach the same level in dynamic languages because your Java skills are well developed. Saying that programmer productivity is improved by a language is not the same your personal productivity will be improved. Productive programmers are something like 10x as productive as low productive programmers, on average. So I don't find it hard to believe you are able to generate 10 lines of Java in the time it takes you to generate one line of Ruby. And that's an average given individually it might be closer to 30 to 1, in which case something like Ruby's 4 to 1 lines advantage would be swamped easily.
For you to see a difference you might have to try it in an area you are unfamiliar with. A type of program using abstractions you've never had to use.
Because memory is special. It's isolated from other processes.
How does that make memory any more special than file handles or network connections? Other processes can't see those either. The GUI is likewise isolated, as an application generally can't scribble over another application's windows.
Let's go deeper: In a growing number of operating environments, the file system is isolated from other processes. At least four operating systems that I'm aware of create the equivalent of a separate user account for each application's private files: IOS on Wii, Sugar on OLPC, iOS on Apple devices, and Android. HTML5 likewise separates local storage and IndexedDB access per origin, and it is up to each origin how much cross-document messaging it will allow. When the device's owner chooses to uninstall an application, the user can choose to uninstall its private files as well.
It's been an entertaining discussion - but I think we're at an impasse - I think I've demonstrated some scenarios in which Java either lacks expressive tools or fails to offer the same guarantees that native C++ can offer.
... and I agree with you. For low latency applications there is clearly an issue. While you are correct in saying Java is not good for everything, and have provided an example, it usually happens that most Slashdotters take the specialized requirements you describe and then decide Java is junk and C++ should be the first choice for modern development. In that way many developers do themselves as disservice.
Next time I'll try and state more clearly that Java isn't good for everything, just most things IMHO (I believed I stated that up front, but will have to be more explicit).
Thanks for your clear explanations and pleasant style. Well met Mr Thinly Sliced!
pointless, since you'll never know whether a bug was fixed, and you'd have no way of getting the fix, except you pay oracle $$$$.
maybe use another language and platform?
I'm blown away by how reasonable and thorough that response was. Thank you.
Glad it was helpful.