IBM Open Sources Their Own JVM/JDK As Eclipse OpenJ9 (eclipse.org)

IBM has open sourced a "high performance, scalable virtual machine" with "a great pedigree... [it's] at the core of many IBM enterprise software products." Slashdot reader dxb1230 writes: IBM has open sourced their JDK/JVM implementation named J9 as OpenJ9. The community now has an alternative implementation of Java which has been well tested on enterprise workloads and hardware. This unlike, OpenJDK, has all the bells and whistles like jit.

Comments

OpenJDK no JIT?

[Anonymous Coward]

Are you saying that OpenJDK doesn't have a JIT compiler? That seems untrue.

Re:OpenJDK no JIT?

[Anonymous Coward]

You beat me to asking this very question. OpenJDK most certainly does have JIT (both c1 and c2). I'm all for having an alternative JRE -- but OpenJDK has been great for running my production workloads for a while now.

Re:OpenJDK no JIT?

[Anonymous Coward]

Indeed, they should fix this misleading text.

Re:OpenJDK no JIT?

[Anonymous Coward]

Yeah they better. Because if they don't they'll feel the full wrath of Obese Basement-Dwelling Slashtard #9001.

Re: OpenJDK no JIT?

[red_dragon]

No way an OBDS has a four-digit ID. I'll have you know that I have a two-story residence, thankyouverymuch.

Re: OpenJDK no JIT?

[K. S. Kyosuke]

I'll have you know that I have a two-story residence, thankyouverymuch.

So what's your story, then? And the other story, too.

Re: OpenJDK no JIT?

[GumphMaster]

Spoken like a true English speaker :)

Re: OpenJDK no JIT?

[Anonymous Coward]

Both underground though, I bet.

Why Java?

[Anonymous Coward]

Not intended as a troll, but a sincere question of a C-veteran of soon 20 years: why do people use Java?

To block the only apology I've heard so far - "portability": way back when (10 years or so?) Java-applications were a major PITA to install, as they needed Java version X.Y.Z; every last digit significant. It seems that these days applications have fixed this by shipping the entire Java run-time in the installation package. So the applications are not portable even between the language implementations.

Why not to use Java? The GUI UX seems to be stuck in the 1990's, and language has (at least to me) something offputting in its syntax.

So why do you choose java for your next project?

Re:Why Java?

[MightyMartian]

Most of the Java code out there isn't GUI code, and yes, high portability is one of the major reasons. And honestly, I have compiled code written 15 years ago that still runs on newer JVMs

Re: Why Java?

[guruevi]

Because they don't understand lower languages like C or someone told them that Object Oriented programming is a good paradigm.

Java is indeed a PITA but it abstracts away the complicated stuff and by the time you've come to the conclusion that Java is the wrong choice for pretty much every project beyond a certain complexity, you're in too deep to make the switch.

Re:Why Java?

[Anonymous Coward]

They didn't get taught javascript in college/university.

Re:Why Java?

[Anonymous Coward]

So I do around 80% of my development in C for embedded systems. When doing user interfaces I do JavaScript AJAX-style web interfaces because I find it easy and people already have a browser. But every now and then I need to do a more "IT" type system that involves a database and server (but often talking to my embedded systems software). When I get tasked with something like this I choose Java servlets because there are some good tools in Java for doing this.

So yeah, Java GUI apps are dead. JavaScript web apps have killed them. And despite the warts in JavaScript I'm happy about that. JavaScript has enough good stuff in it (like closures) that make doing a UI easier.

But Java has its niche and it's good at it. A choice in JVMs is good. Since I was curious and am a bit of a compiler guy I took a peek at the J9 JVM code. On the surface it seems a bit messier and less organized than Hotspot. But maybe it's faster.... I guess I'll find out eventually.

Re:Why Java?

[Anonymous Coward]

java is most used on server side, so the outdated gui ux is not really relevant (note that I agree on the bad gui ux)
imho the advantages of using java are:
* the language is somewhat simple to learn
* it is teached in universities, and there is no shortage of developers
* almost all tools and ides are free (also middlewares are free, or available in "community" editon)
* java has a huge library of code (opensource projects and proprietary ones) to achieve almost anything
* the programs are portable: I usually develop on windows and then run the very same code on linux servers (some years ago also on aix and solaris)
* the java technology is mature, stable, tested on enterprise environments, and "boring"... but that's a good thing, I don't want suprises.
* in addition to server side it is used on android too :-)
* if you really don't like java synthax you can use other languages that target the jvm (jpython,scala...)

Re:Why Java?

[Anonymous Coward]

i find well written C code to be easier and more portable than .jar files.

Re: Why Java?

[Lothsahn]

Java developer here...

Easier? Probably, since you know c. For me, Java is definitely easier.

More portable? Doubtful. I work on an Enterprise app with millions of lines of code and the same Jar works fine with essentially no extra work on both the IBM JDK and Sun JDK on Windows, Linux, and HP-UX.

We encounter typically 1-2 issues a year that are OS or JDK dependent issues. This is
If you want to argue c is better than Java, argue on it's strengths... Performance, bare metal control, and platform support (a lot of very small embedded platforms don't have a Java runtime... or it's terrible). Java beats C hands down in portability.

Re: Why Java?

[Lothsahn]

Should have been "This is less than 1% of our development budget".

Re: Why Java?

[Lothsahn]

Only speaking about server apps in Java... Swing/GUI/applets is a hot mess...

Java has very good backwards compatibility. We compile our app for Java 7 and run it with 7, 8 and 9. Very few bugs exist when we do a major upgrade... Typically 1-2. For minor versions within the same major release (updates as they're called in Java), we haven't seen a single backwards compatibility issue in probably 8 years.

Sounds like you're talking about very old versions of Java (version 4 and earlier), or GUI code, which does have these issues.

Re:Why Java?

[cheesybagel]

- Portable binaries across all major OSes and hardware platforms.
- Large standard library which implements nearly everything you need to write a networked application.
- Threading supported natively.
- Decent performance.

A lot of people thus use Java on server-side enterprise apps. The GUI for client apps is abysmal though and some of the APIs are a pointless waste of time. But you can just NOT use those APIs (like EJBs) even if your enterprise clients love them for whatever reason.

Re:Why Java?

[Anonymous Coward]

Apart from Android, almost nobody uses Java for GUI stuff anymore.

Java is mostly a server-side language.
- cross platform
- excellent IDEs (e.g. Intellij IDEA or Eclipse)
- a huge set of libraries
- bounds-checking
- decent support for programming in the large (access controls, fairly strong static checking)
- huge industry support and enormous installed base (many developers) - there is almost never any pushback in choosing Java at large organizations because it is probably the closest thing to any industry standard.

Java syntax is pretty "normal", and not that different from C++ or even C. Very similar to C#, obviously.

That said, there aren't too many situations where somebody should be making a " C vs Java" decision. You can't write low-level stuff in Java, and for many reasons C is probably not the right choice for anything higher level.

Re: Why Java?

[MightyMartian]

Largely my experience now. There are certainly a few incompatibility issues that creep up, after all Java is over 20 years old now, so that's quite a few iterations of both the language and the JVM. But when I consider the complexity of porting C code from, say, Linux to Windows, or in many cases from Linux to BSD or some other *nix flavor, the odd quirk I run up against when popping a JAR file on to a new platform, I'd say Java is as close as anything gets to true cross-platform portability. No one has put more effort into making obscuring the underlying architecture than the JVM teams, and I still get a thrill when I fire up a Java app I've written on Windows on my Linux test machine and it, well, just works. No recompiles, no wild makefiles and compiler redirectives.

C is an awesome language, and truly one of the great inventions of the computer age, but it is fundamentally a different tool than Java, with very different intentions. For me, Java means I'm not locked into any architecture, and not having to fight my way out of the box that the architecture represents. It's not for every task, but for the bulk of problems thrown at me, it does the job very well. Not perfectly, but very well.

Re:Why Java?

[Anonymous Coward]

I don't know how someone could possibly come to that conclusion. The same jar file will run on a Mac, Windows, Linux, and even IBM mainframes running zOS.

At a very minimum, you'll need to recompile your C for each of those platforms.

Also, writing "well-written C code" is also a non-zero effort that every programmer on the team has to be aware of. To a large extent, Java gives you the equivalent for free.

Re:Why Java?

[dshk]

I have used C and mostly C++ for 10 years. Java for 15+ years, full time.

My experience with Java portability is extremely good, during 15 years I guess i have less than 5 cases when I have to modify our own code for portability reasons. I mean binary compatibility, no recompilation is necessary. Upgrades were seamless too. However I know that others has worse experiences. Regarding C, I almost never have been able to compile C programs without issues in a new environment.

As a language, Java has the huge advantage of automatic garbage collection. That not only means that I do not have to destroy object at the end of functions, that is not really important. The big thing is that returning newly allocated objects to the caller is the natural way of doing things. This is an issue in C, because it must be agreed on who will destroy the returned object. Java also has a huge standard library, and - except web applications - there is an obvious candidate for everything.

Java has comprehensive runtime information about anything, so tools and frameworks can do almost anything runtime, including generating new code. And they do this nicely, they do not mess with the code unnecessary. There is a precise stack trace in each and every case. There is no pointer arithmetic, so there are no mysterious memory corruptions, ever.

Also, in contrast to the somewhat popular, moronic thinking, Java is very fast and very secure, it is compiled and recompiled several times dynamically runtime and there are no memory leaks. It usually requires more memory than a well-written C program, and its startup is slower, but that is rarely an issue on modern (i.e. not older than 10 years old) machine.

Overall I am much more productive with Java.

Re:Why Java?

[Anonymous Coward]

> Why not to use Java? The GUI UX seems to be stuck in the 1990

Well, that happens when you use the API from the nineties, not only in Java. Java's current solution for GUI is called JavaFX.

Re: Why Java?

[MightyMartian]

And what "complexity" is that? You're not going to write device drivers in Java, that's for sure, but modern Java is pretty capable whether it's desktop apps or, where it's used more often, in enterprise solutions, which is why the big guys like IBM use it.

And what's wrong with abstracting the architecture. One of C's original intentions was portability, and a lot of that was done by porting over libc to as many platforms as possible so all the system calls of the operating system in question were, well, abstracted. Java's just further down that road.

And OOP has been with us for over thirty years, and while not suitable for every problem, is still a pretty rock solid way to solve a lot of problems. That's why people went out and developed c++ and Objective C, and why most of the other modern iterations of earlier pre-OOP languages have had OOP extensions for a couple of decades now.

Re:Why Java?

[Anonymous Coward]

Who actually uses JavaFX? Honest question. I've worked with Java almost since its inception. Mostly server-side, but with small doses off Applets, Java WebStart, and Swing here and there (all 10+ years ago now). I'm a consultant, so I work in a lot of places but I've never seen JavaFX anywhere.

Re:Why Java?

[AlanObject]

The question of "why this or that language" comes up often and my stock answer is as follows:

To me the specific language is irrelevant. The reason you use a given language is because a given framework, class library, or function library is written in it and that body of proven work is the best for whatever application you are pursuing.

The criteria of what is "best" can vary. However as a project manager I place a high weight on what my team (which may be only myself) is familiar with. So if your boys and girls are crackerjack with Django idea-to-deployment-in-3 days then Python it is. Staid old JavaEE types invariably end up with -- well Java. If you are doing a reactive or SPA web-app you will end up with Javascript. Instrument control? Learn TCL.

Another highly-weighted criteria is what the available frameworks are that are most suitable for the application. I remember back decades where if you wanted to control telescopes for astronomy the choice was FOCAL for some reason. I wonder if that is still the case but I doubt it. And for some bizarre reason MUMPS was the base for many hospital/healthcare based apps.

Too many people dwell over the merits of C vs. C++ vs. C# vs. Java vs. Python vs. Ruby vs. Javascript vs. Swift vs. what-ever-the-cool-thing-is-today. The arguments go on forever repeating the same points over and over and they are meaningless.

Any halfway competent software engineer can pick up a language they have never used before in a few days max. It is the libraries and frameworks that have the real learning curve. So keep on using C if that is what you are used to -- but not if you get a project where you find yourself writing a new framework that has already been done, tested, and deployed in another language. Then just suck it up and learn that language. You might surprise yourself with how enjoyable it is.

Re:Why Java?

[gwjgwj]

One incompetent programmer who overwrites memory in random places does not ruin the entire program. I think this is the main reason.

Re:Why Java?

[Anonymous Coward]

Why Java?

Type safety. Memory safety and garbage collection. No dirty macro preprocessor. Context-free grammar aids code analysis and code refactoring tools. Portability. Data encapsulation (objects data and methods and with public, private, protected visibility). Error handling via exceptions.

I think Java now has lambdas. I think C does not. (I know C++11 does.) I think Java has generics of some form. I suspect Java's generics are inferior to C++'s. C does not have generics (afaik).

I think Java compiles faster than C++. I suspect Java may compile faster than C.

(Of Java, C++ and C, I prefer C++. I avoid using Java due to its bloat. But I recognize the strengths of Java, especially for enterprise projects that find great appeal in Java's safety guarantees.)

Re:Why Java?

[Anonymous Coward]

Java is one of a small handful of languages with good performance and up to date built-in libraries. The only real competitor is C#. Yes C++ is faster and so C++ is a better choice for a game engine or other use cases. There are others with similar features (e.g., unicode is a huge one) such as Swift or Python but those are pretty slow and not considered when you are building out server applications.

Java has a very, very strong third party library ecosystem. If you want to do things like Hadoop or Struts then Java is the answer for you.

User-interface applications are generally not written in Java. (Except on Android.) That initial idea from the 1990s is not where the value of Java was found. It does work well enough for "toy" programs where the portability aspect is a nice bonus.

If you're still developing in C then you are working at a much lower layer than most developers and so I can see why you would not understand why most of the world has moved to other languages.

Re:Why Java?

[Anonymous Coward]

Java is an excellent choice for application servers or other app platforms built to accept third-party plugins in userspace. The JVM will guard against quite a bit of mischief from either incompetence or malevolence on the part of the plugins. And the language provides strong typing and compiled performance (using JIT).

Re:Why Java?

[Anonymous Coward]

Yeah, but look at the other important things which are no longer teached.

Re:Why Java?

[HiThere]

Well, Java's a lot better than C at handling multi-processing. And it's easier to handle most use-cases of unicode strings. It's got a few other minor advantages.

I, personally, don't like it, but I haven't yet found a language that meets all my requirements. D (dmd) comes quite close, and I'm currently investigating Go. (One of my main problems with D is program documentation...not theirs, but mine. The autogenerated documentation is too ugly.)

Re:Why Java?

[Anonymous Coward]

You espoused a clear and concise argument that is logical. As a fellow C/C++/Java programmer who believes in using the right tool for the right job (each tool has its advantages) you don't seem to understand modern "brogrammer millenial culture:" It has nothing to do with being an effective tool to solve a problem and everything to do with popularity and coolness.

Building something that works isn't necessarily the goal anymore; it's "likes" on social media. Or however that stuff work.

Re:Why Java?

[Anonymous Coward]

Because there are more dev jobs than people to take them, at the senior level, at least in my locale?

OK, that explanation is a bit chicken-and-egg... But not all that much facetious.

I've started as a programmer around the same time as you. My first job required our code to compile and run on multiple platforms (various Unixes, Win, OS/2, ...) as well as multiple databases. To achieve that we restricted ourselves to strict ANSI C and had strict conventions for our code (also a way to do some homebrew flavor of Object Orientation in it - yes you read right), makefiles (remember those?) etc. We actually had a common component that abstracted database operations quite a bit - custom written, of course. Oh, and ODBJ... Then again, these projects were command-line/background processes, a far cry from today's GUI or web-frontended applications.

I think at a stage there was a lot of hype around Java that gave it a lot of momentum that is still keeping it rolling today. On the other hand, it's not so much the pure language as it is the "ecosystem" that go with it (libraries, frameworks, web containers, etc.) that still make it a very attractive proposition for businesses.

The other factor that may go hand-in-hand with this is learning curve: learning something completely new and getting experienced in it takes a lot of investment. Much cheaper to stick with something that works and upgrade knowledge in small increments. Now this may not be an issue for people that stuck with C or C++ all these years, but a lot of us jumped ship to Java when it was hot ("similar syntax!"). If I had to do the same work I do today but using C, I wouldn't know were to start to look for some web container, standard that does something similar to JEE, libraries, web frontend frameworks, unit testing frameworks, etc. etc. It may well be that C kept up to date and added new features the same way Java did - things I have difficulty living without these days.

So this is just one perspective, not necessarily a perfect counter-argument, but one does not always have the luxury of finding the most bestest language (probably an endless quest), pragmatism also plays a big role.

Re:Why Java?

[Anonymous Coward]

Don't underestimate the work an incompetent programmer can do in even the most safe languages. I suspect a properly skilled idiot can wreck havoc even in Haskell and Ada programs.

And yes, I understand your point that this is mainly runtime recoverability... But still, if I've learned anything in my 30+ year career doing HW and SW development: Never underestimate the power of an idiot.

Re:Why Java?

[pauljlucas]

Because really good programmers are hard to find.

Re: Why Java?

[Anonymous Coward]

I'd say Java is as close as anything gets to true cross-platform portability.

Why do you ignore languages like Perl, Python, and even Tcl that run on far more platforms than Java does?

You seem to have a very limited understanding of what true portability is. Portability isn't just supporting Windows, macOS, Solaris and Linux.

Re: Why Java?

[Anonymous Coward]

At a very minimum, you'll need to recompile your C for each of those platforms.

You have to do that with Java, too. It's just called a 'virtual machine' instead of a 'compiler' that does it. Regardless of the name, it does the same thing: converts the code to something the CPU can execute.

Re: Why Java?

[MightyMartian]

Because coding in Perl is like having a root canal. Perl may run on more platforms than Java, but I hate programming in Perl. And Python brings nothing to the table that Java doesn't already have, so why should I bother?

Re: Why Java?

[K. S. Kyosuke]

Java beats C hands down in portability.

I think that well-written C code, such as, e.g., Lua, is really portable. It compiles everywhere, even into freestanding environments.

Re: Why Java?

[K. S. Kyosuke]

If you really want OOP, you won't use C++, ObjC or Java anyway.

Re:Why Java?

[K. S. Kyosuke]

Java is one of a small handful of languages with good performance and up to date built-in libraries.

I think that when it comes to built-in libraries, Go has been very decent recently. At least a cursory view of its basic library APIs seemed quite saner than Java's to me. Things with one purpose in one place etc.

If you're still developing in C then you are working at a much lower layer than most developers and so I can see why you would not understand why most of the world has moved to other languages.

To avoid high-performance possibilities of such approaches as DataDraw?

Re:Why Java?

[mark-t]

The big thing is that returning newly allocated objects to the caller is the natural way of doing things. This is an issue in C, because it must be agreed on who will destroy the returned object.

It's also an issue in c because such newly allocated objects are typically allocated on the heap, which is much slower than automatic storage allocation. Java uses the notion of short term storage, analogous to automatic storage in c and c++, when allocating objects (which are migrated to longer term storage as necessary) so performing such allocations in Java is not typically as expensive as heap allocations are in C

Re: Why Java?

[Anonymous Coward]

Can you do us a favor and post this to every /. article that mentions Java in the summary? Or any article about any programming language, for that matter. They all seem to lead to a lenghty discussion on common misconceptions about Java.

Re: Why Java?

[Anonymous Coward]

Uh, ok. If you don't understand the distinction and advantages of platform-independent binaries you might want to do a little remedial research before posting again.

Re:Why Java?

[Anonymous Coward]

> Any halfway competent software engineer can pick up a language they have never used before in a few days max. I

Only a completely INcompetent programmer (or a semi-competent liar) would make that statement.

If you worked for me, you would be fired by now.

Re:Why Java?

[Anonymous Coward]

Security is often put forward as a reason: no buffer, etc., overflows in Java.

Re: Why Java?

[Anonymous Coward]

Have you ever actually used Java or C?

Re:Why Java?

[spiritgreywolf]

The bottom line is that it's picking the right tool for the right job.

MUMPS though still alive in Open Source fashion has been pretty much taken over by Intersystems and re-branded/extended called "Cache" and the language "Cache Objectscript". At it's core it's still an awesome language for manipulating persistent sparse arrays and includes easy methods of exposing pretty much any data hierarchically as well as SQL projections, and has the ability to talk to Java, .NET, C, C# and just about everything else.

At the time of its inception, it was built to "fiscal edge" needs, not "bleeding edge" needs - as MUMPS ran on pretty inexpensive hardware and could do things with massive amounts of clinical data faster than most other languages at the time. It's what Epic (a giant Hospital Information System implementation at most hospitals anymore) runs on, including Indian Health Services RPMS and VA's VistA (not saying much as both of those behemoths could use serious re-engineering - but they work)

You're right though - I couldn't give a rats ass what the framework is - does it fit the job? Is it maintainable? Does it make sense? And if my developers all walked out or committed mass suicide to reach some comet in the sky, could I bring in people that could pick it up and support it?

"Wicked Cool" are not words I ever want to hear with respect to code that is running in production. I want safe, supportable, accurate, responsive. If I get paged at 2AM in the morning to fix something that broke, and that's after I had a couple margaritas celebrating a friends birthday the night before? If I cannot read that code, debug it, figure out what is going on and get it working rapidly, then someone did NOT do their job right and deploy code that is easy to maintain. I do not want to have to jump into stack traces going "What the F**K was this guy trying to do?!" because he thought it was cool and witty at the time. Save that Perl-esqe obfuscating bullshit for your Github-based personal projects. That kind of shit would never pass peer-review.

I used to come across "JavaEE is the answer to EVERYTHING in Healthcare" like bloated engines sitting on top of Glassfish and Tomcat. it was goddamned ridiculous (still is). And when a real-time message went "boom" someplace in the architecture, it took a team of onshore and offshore ass-hats just to find the problem? Your solution sucks ass. Period. I know of a very large healthcare entity that still uses IBM Websphere and ESQL that requires many DOZENS of people to support and has the responsiveness to change like glacier made of tungsten. And of course dropping millions into keeping it going because nobody wants to admit they totally fucked up and didn't keep up with the times? It seems the choice of architecture is sadly more of a political one than one of technical correctness.

Re: Why Java?

[NuShrike]

As a C/C++ veteran of > 20 years, one angle is Android.

That Java mantra got carried into Google at the time and it's locked in now.

Benefits, portably recompiling (not Java) byte code on demand for 32-bit or 64-bit architectures with improved simd optimizations.

Backwards compatibility is kept at the in the runtime-compiler, API level instead of depending on the CPU for legacy compatibility (see Intel).

This predates .NET and only slightly suffers from progressing through the language tweaks from Java 6 through Java 8. It's much more mature than .NET so the changes aren't as drastic.

Library of third-party libraries is vast.

Re:Why Java?

[pkphilip]

Java is excellent for some scenarios such as the development of server-side applications, webservices and so on. For stuff such as desktop GUI development, C/C++/.NET etc may be better options.

Apart from that, Jave has the following advantages:
Excellent portability
Automatic garbage collection
Huge collection of excellent libraries accessible via well-organized central repositories via build tools such as maven, gradle and so on
Dependency management is lot easier if you use build tools such as maven/gradle etc
Huge numbers of competent developers

Re: Why Java?

[Anonymous Coward]

Java bytecode or JAR files are not 'platform independent binaries'. That's why you need a JVM to run them on common CPU architectures like x86, x64 or ARM. They need to be compiled by the JVM into something the target CPU can understand.

Don't forget that the major JVMs are themselves typically written in a mix of C and C++! If C or C++ don't support a given platform, then Java probably won't suport it either, since the production grade JVMs are C and C++ programs!

Java is actually worse in that it requires the Java source code to be compiled to bytecode, and then the bytecode compiled to machine code. Real languages like C, C++, Fortran, Rust, Go and Ada cut this pointless middle step, avoiding the burden of JVM like nonsense.

Re: Why Java?

[MightyMartian]

is this an all or nothing kind of thing? Sure, if I wanted pure OOP, I'd look at Smalltalk. But what I'm looking for is a language built on OOP principals, even if not fully object oriented (ie. possesses non-object primitives), with a large set of libraries. Java and C++ are close enough to that that I can live with them not being pure object oriented languages.

I'm picking a tool set, not a religion.

Re: Why Java?

[Anonymous Coward]

Sure, that's why I understand how obviously wrong the comment "i find well written C code to be easier and more portable than .jar files" is.

Re:Why Java?

[MightyMartian]

There have been plenty of insecure frameworks built in all the major languages, and thus far has anyone proven that Struts was the source of the hack?

Re:Why Java?

[Lunix Nutcase]

Java is an excellent choice for application servers

Yeah, excellent for criminals to breach servers running web applications written with Apache Struts.

Re: Why Java?

[Anonymous Coward]

I just run 'make' on any BSD, any Mac, cygwyn windows, or I could try the ubuntu windows (haven't don that yet), any linux and any other AIX, solaris or other older POSIX system and the code runs. with those .jars I always need the right version of JDK installed by an admin and it always seems tricky to get things running. need to change manifests, security settings on OSes of java installs change all of a sudden. oh and then we have these nice java 3d dependancies that require OS specific binaries installed again.

so I hence my question. really portable java?

Re: Why Java?

[K. S. Kyosuke]

Probably not, but the more complicated problem you're trying to solve, the bigger the chance that your code base will turn into ravioli code instead of having nice source-code-level abstractions, often for the dearth of concepts in the base language. Certainly various knowledge base systems greatly profit from very expressive object systems that Java or C++ don't have. Then you hit abstraction levels like these and not even CLOS may be enough.

Re: Why Java?

[Anonymous Coward]

C is an abomination designed by an NSA contractor in order to generate lots of buggy software to be subverted by NSA malware.

Re: Why Java?

[Anonymous Coward]

A .jar is an archive, typically containing .class files and other resources. .class files are binaries, and they are platform-independent - you can take the same .class file and use it on any platform. They're not platform-independent executables, but nobody claimed that.

A .o file works on the platform it was compiled for, and that's all.

Re: Why Java?

[Anonymous Coward]

C and C++ Code from a seasoned EXPERT (not a junior developer) *can* (if so desired) be highly portable.

And it will be at least two times more RAM-efficient than competing Java code. It *can* (if so desired) be real-time capable, unlike Java code using the standard library or similar libraries (because of heap memory and the garbage collector which stops the entire program for seconds or more).

With C++ you can finely control the allocation and de-allocation of RAM, file handles, buffers, sockets, window resources etc. With Java, you never know when it will be "garbage collected". See the RAII pattern, which is very powerful and elegant.

Java is full of waste and basically a tool for junior people, who would run into "memory cancer" issues with C++ rather quickly.

Re:Why Java?

[Anonymous Coward]

"To a large extent, Java gives you the equivalent for free."

Thats B.S. Sloppy coding will result in buggy and inefficient code. No matter which language. The only difference for sloppy people being that they don't fall as easily into dangerous pits with Java so quickly. But the end result of sluggish, buggy code may be just as worse as a complete failure of the project.

Re: Why Java?

[Anonymous Coward]

You can also use gcj to generate binaries from Java source code, but you must still live with the Garbage Collection inefficiency. And the inefficiency of the entire Java memory model (everything complex is allocated on the heap etc)

Re:Why Java?

[Anonymous Coward]

Java has a stronghold on something which could be called "enterprise transaction apps with some sort of database behind". Plus something we could call "configuration apps by large corporations, often painful".

As soon as you get out of these two fields, Java is almost never used. Just check your Word Processor, your graphics manipulation program, your browser, your database server, your web server.

Java is a slug, a resource waster and it is not even soft-realtime. High-quality software demands high quality approaches: C++, Objective-C, Swift, Rust, Ada etc.

Re:Why Java?

[Anonymous Coward]

Properly coded C++( Qt, wxwidget, ...) apps deliver all your listed goodies, but at much better performance and efficiency. Except you need to recompile on each platform. They are generally much snappier than the Java stuff.

Re:Why Java?

[Lunix Nutcase]

and thus far has anyone proven that Struts was the source of the hack?

Yes, Equifax has.

Questions Regarding Apache Struts

The attack vector used in this incident occurred through a vulnerability in Apache Struts (CVE-2017-5638), an open-source application framework that supports the Equifax online dispute portal web application.
Based on the company’s investigation, Equifax believes the unauthorized accesses to certain files containing personal information occurred from May 13 through July 30, 2017.
The particular vulnerability in Apache Struts was identified and disclosed by U.S. CERT in early March 2017.
Equifax’s Security organization was aware of this vulnerability at that time, and took efforts to identify and to patch any vulnerable systems in the company’s IT infrastructure.
While Equifax fully understands the intense focus on patching efforts, the company’s review of the facts is still ongoing. The company will release additional information when available.

https://www.equifaxsecurity201...

Re:Why Java?

[Anonymous Coward]

Huh?

Any "well-written" cross-platform C program has a whole bunch of stuff in it to make it cross platform. Preprocessor macros and the like to define types, configure pointer sizes, what system calls to use, etc. Java takes care of a lot of that for you.

Re:Why Java?

[Anonymous Coward]

Java is first and foremost a tool for selling "bigger servers". Especially if used with these monstrous "frameworks" which devour RAM like popcorn.

Even the most efficient Java programs will consume 2x more RAM than the equivalent C++ program. The reason is the garbage collection system of Java.

Now, factor in junior developers and you will have 10x or 100x the RAM consumption.

Re:Why Java?

[HarrySquatter]

Hilarious goalpost shifting.

Security exploit is found in C software - "That's because C is insecure by design!"

Security exploit is found Java software despite numerous people touting how "secure" Java is - "Well, you know, insecure software can be written in any language!"

Re:Why Java?

[Anonymous Coward]

Who compiles Java? Don't most just use the jvm.

Re:Why Java?

[hackus]

Portability is a sorta of a half truth, and doesn't do JAVA justice.

It is portable INFRASTRUCTURE.

If you have a JVM you have all sorts of infrastructure available that goes way beyond the language. So for example in the definition you describe portability is limited to the language and compiler output of the binaries for different processors.

Java goes a couple of steps further, besides a binary its environment defines a consistent portable computer that includes not just portability, but security sandboxing. It insures that the environment is consistently portable.

So if you can port the Java VM, you port ALL software. Thats not true if you port a C program, even though C is immensely portable you just ported one program written in C.

There are other fascinating aspects to JAVA which will more than likely last even longer than C has due to just this on example. But as you can see, it is a huge advance in protecting ones investment and insuring software written today will only require ONE port of a VM to run on new hardware tomorrow.

Giga quantities of money saved actually.

Re: Why Java?

[Anonymous Coward]

C/C++: spend 1000 hours debugging malloc/free and generally wasting time with strncpy/memcpy/etc.
Java: spend 1000 hours debugging GC pauses but generally accomplishing something.

Re: Why Java?

[Anonymous Coward]

Java is actually worse in that it requires the Java source code to be compiled to bytecode, and then the bytecode compiled to machine code. Real languages like C, C++, Fortran, Rust, Go and Ada cut this pointless middle step, avoiding the burden of JVM like nonsense.

Hand in your geek card. Every language gets transformed into an intermediate AST or some such. That's been true for *decades*.

The difference between Java/C# and C/FORTRAN/etc. is when the transformation from AST to machine code happens. And, quite frankly, there's nothing technical stopping anyone from writing software where the Java is transformed to machine code prior to the first invocation the program and nothing technical stopping anyone from writing a virtual machine to execute C/FORTRAN AST format.

Re: Why Java?

[Anonymous Coward]

I am old C and C++ developer. I swithed to Java about 4 years ago and I really don't want to back to C or C++. Woth Eclipse you have many nice refactoring tools. The standard library covers most of your needs like graphics, threads, networking etc. And with maven you can easily use 3rd party libraries. Exception handling is really good once you learn how it should be used. It has good tools for debugging. JUnit is really nice for unit testing. It is fast to write code and it is easy to test it. Performance is good enough for any server software I written.

Re:Why Java?

[Anonymous Coward]

Its also a significant part of Google's infrastructure, and Amazon's, and Apple's. And there's Android.

Is it used for Word? No. But I'd bet its used in Google Docs.
You're totally wrong on web servers - tomcat, jetty, websphere, etc are all written in Java.

Re: Why Java?

[Anonymous Coward]

You clearly don't know C++. These days we use smart pointers, which have almost no overhead, and easily avoid memory leaks and memory management. We also use the STL data structures and algorithms, which have excellent performance. C++14 and C++17 are better than Java in pretty much every way.

Re:Why Java?

[jgfenix]

You can write 90% of the applications with only the standard libraries. In most other languages you would need to use various third party ones to accomplish the same.

Re: Why Java?

[Anonymous Coward]

Some JAVA code might run slightly as fast as C but definetly is never bare metal; Some JAVA code might run faster tweaking the VM but that only proves that JAVA is not that reliable and some code might run different in some platforms or with different configurations; I know this because I used a very expensive and ugly commercial grade FEA software that implemented all its computation in JAVA and there were some very specific packages that needed tweaking the VM in order to get the results.

Sometimes I need to remember that JAVA is just like a VirtualPC for a virtual processor.

Re:Why Java?

[Anonymous Coward]

I have not yet seen any major product shipping its own jdk as a required component. They have option for embedded jdk as a convenience but mostly it will work with any java version (except that the programs written with major jdk versions may not be compatible with older jdk). I run large enterprise software all the time with generic jdk downloaded from Oracle. "GUI/UX stuck to be in 1990s", most likely you are not paying attention. 95% of Java programs are not GUI. Java has large number of built in library and if anyone develops a new one, I just download jar and I am done. Can you do that in C? If I have a C windows dll and put it on website and you have Mac or Linux or Solaris, will it work? Even across the same OS but with different versions, you might have issues. This is for portability. But beyond that, the java language itself is far more richer than c/c++. Debugging in c/c++ is hell compared to java.
BTW, I program in c and java both and have been doing for the past 20+ years.

Re: Why Java?

[Anonymous Coward]

Run on more platform? I doubt. Take a random 100 line perl program from internet and try to run on Linux and Window and see if it does what is intended. I ported 800 Perl/Python scripts from Unix and Windows and telling you from my personal experience. It took us months to debug it. Python is better. I don't about Tcl. Only ported small programs and not sure if you can even write major enterprise software in it. I have seen 100k+ line of Perl code, millions of line of Python code, 10 million+line of Java code but never seen even 10k+ line of Tcl code in single product.

Re:Why Java?

[Anonymous Coward]

No goalpost shifting.

There's a class of security problems that affect C and C++ that Java is immune to by design.
I don't think anyone is claiming that Java (or any language) is impervious to all security issues.

Re: Why Java?

[Anonymous Coward]

Lol, I suppose some things are supposed to be teached to you before college level

Re:Why Java?

[Beeftopia]

Because object oriented languages FORCE a measure of readability and organization and preliminary design on the developer, which improves maintainability. It's not just Java, but also C# (the interpreted object oriented languages) as well as C++ (which executes cpu-native code).

With C, a developer can just start hacking away. "I need a function to do this, lemme write it." Put it in some file, update the makefile, done. Object-oriented languages add the "class" data structure, which is just a (required) way to group code. One is forced to stop and think what class a function should go in, and why. It's not much but it is a brake on a lazy or hurried developer, a brake which improves maintainability and readability.

As far as Java in particular... what is the benefit relative to its closest relative C#? If one goes with the whole enterprise IBM solution (Websphere), it has more out-of-the-box support for failover support and data replication. C# is easier to get started with because one doesn't have to do all the configuration required with an enterprise IBM Java setup, because much of the configuration is already done since C# is integrated with Windows.

Re: Why Java?

[Gr8Apes]

Why do you ignore languages like Perl, Python, and even Tcl

Because Perl doesn't even consistently compile itself in different versions on the same platform, and writing anything interesting in it beyond a mere utility script would be like performing your own root canal. Python I've never actually seen used in the enterprise, hence 0 reason to use it. Maybe smaller projects use it, I don't know, nothing I'm paid for utilizes it. TCL, people still use it? Haven't seen any development in that in more than 15 years. Might as well ask about fortran or SQL. Oh, right, neither of those are portable either unless you meet a bunch of criteria both in your coding and in your platform/compiler selections.

Re: Why Java?

[Anonymous Coward]

Your srgument is that C++ is better today than Java was 20 years ago?

Re: Why Java?

[Gr8Apes]

We also use the STL data structures and algorithms, which have excellent performance. C++14 and C++17 are better than Java in pretty much every way.

The STL, and the horrid namespaces as implemented in C++. The 2 truly terrible decisions that made Java, even with its lower performance look like eden in comparison. Now, it's been a a while, obviously, but a pure algorithm written in C++ utilizing linkages across 3 libraries with STL is what made me decide C++ just wasn't up to snuff. Why? Because when you compile the algorithm on NT or OS/2 (yes, it was a while ago) it worked fine, but compile it on Solaris or Irix, you'd get different results. Now why was this? Because the length of the pointer name in the compiler exceeded the maximum length by 1 byte in certain link orders on Solaris and Irix and you wound up with some interesting pointer ambiguity. There were no errors thrown. It was absolutely wonderful to try to figure out why that happened, and the hap-hazard inconsistent results with exact same starting data occurred in what should have been a constrained algorithm. OTOH, helping someone else out with a similar issue with fortran later on was cake.

I had the distinct nausea of having to deal with the STL relatively recently and what it reminds me of is that other pile of crap I won't touch: EJBs

Re: Why Java?

[Anonymous Coward]

gcj is a dead end: it has been removed from gcc8.

Re:Why Java?

[jeremyp]

Well, let's be honest, the whole C language is stuck in the 1980's. There's no automatic memory management. There's no bounds checking. The type system is primitive. There's no introspection. It's GUI UX is not stuck in any decade because it does not have one, nor, in fact, a proper string type.

Granted, C is more portable at the source level than almost any other language (as long as you have one of those horrible kludges like the GNU autoconf system and you avoid all the undefined an implementation defined behaviour), whereas Java is only portable to architectures with a conforming JVM available, but it is binary compatible with all of those architectures so that I can distribute the compiled byte code. And yes, for at least releases 7, 8 and 9 there are rarely any issues sensitive to the point release number of the JVM.

I don't know why you re complaining about the syntax because Java's syntax is lifted directly from C via C++.

Why would I choose Java for my next project? Well, I wouldn't by choice, I admit. I'm usually mandated to use it by the target environment or customer. But nobody has asked me to write a C program for a decade.

Re:Why Java?

[Gr8Apes]

Is it used for Word?

If it was, it might work in less than 4GB and save empty documents of less than 100KB.

Re:Why Java?

[bugs2squash]

I like C. I used it exclusively during the first part of my career and I still use it from time to time. but now I mostly use Java. I like the environment surrounding java (eg maven, JMX, even the stack traces), and the programs are written in java itself, which seems like a strange thing to say, but much of the C code was written in a macro language rather than C per se.

The verbosity of java is not the problem I thought it would be (maybe I just got used to it) and in general I like the amount of error checking the compiler can do, about the only thing I really don't like is the way it handles primitive types, I miss the C unsigned integer types and find unpacking network data structures to be un-necessarily irksome in java, but then only a small part of what I do is so low-level any more

Re:Why Java?

[jeremyp]

Properly coded C++( Qt, wxwidget, ...) apps deliver all your listed goodies

So you need to add external dependencies like Qt to get the same functionality as the Java standard library.

And one of the listed goodies was portable binaries. No, you don't get that with C++.

but at much better performance and efficiency. Except you need to recompile on each platform. They are generally much snappier than the Java stuff.

On the other hand, you have to program in C++ which is a bloated mess of a language.

Re: Why Java?

[Zero__Kelvin]

You just contradicted yourself. Java can't beat C for portability, and be unavailable on a vast number of systems. C is FAR more portable than Java. The Linux kernel supports more than 30 hardware architectures, for example. What you mean is that Java ships with Middleware (i.e. the JVM) that makes it run unmodified on a few different Operating Systems. It isn't more portable by any stretch of the imagination.

Re:Why Java?

[Zero__Kelvin]

"As a language, Java has the huge advantage of automatic garbage collection."

You spelled disadvantage wrong.

Re:Why Java?

[Beeftopia]

You espoused a clear and concise argument that is logical. As a fellow C/C++/Java programmer who believes in using the right tool for the right job (each tool has its advantages) you don't seem to understand modern "brogrammer millenial culture:" It has nothing to do with being an effective tool to solve a problem and everything to do with popularity and coolness.

Building something that works isn't necessarily the goal anymore; it's "likes" on social media. Or however that stuff work.

Relevant: Resume Driven Development

(NTTAWT, as long as it doesn't interfere with the quality of the output)

Re:Why Java?

[Anonymous Coward]

Java has the huge advantage of automatic garbage collection.

That may be an advantage over C, or older C++. In Modern C++ this is mostly a non-issue - assuming you use smart pointers (in the standard library) judiciously and follow the Coding Guidelines. Explicit memory allocations is essentially gone and you don't have to worry about it. No garbage, no leaks. Of course, you could be keeping to much stuff alive, but that's just as much of a problem with Java, since that memory doesn't get GCed.

So Java garbage collection is more of a hindrance than a benefit relative to Modern C++.

Re:Why Java?

[StormReaver]

Not intended as a troll, but a sincere question of a C-veteran of soon 20 years: why do people use Java?

I have been programming in Java since 1997, C since 1985, and C++ since 1999. I have never run into the Java versioning issue you described -- ever -- as long as I have had the highest required Java major version installed.

As for portability, Java reigns supreme. I have Java binaries I compiled in 1997 that still run, unmodified on all supported operating systems. I write major applications in Java that run in Linux, Windows, and (probably) anything else with a conformant JVM. This includes GUI, business logic, networking, mouse and keyboard, etc. I have never run into a situation where my Java program didn't work perfectly across platforms. There is very little that isn't completely portable and standardized in Java, something which doesn't exist in C, C++, and 99.9999999999999999999999% of all other platforms.

Re:Why Java?

[Anonymous Coward]

The syntax is a simplified C++ syntax, so if you find that offputting, you are shutting out a whole family of the world's most popular languages that are derived from the same syntax.

Re: Why Java?

[xski]

I just run 'make' on any BSD, any Mac, cygwyn windows, or I could try the ubuntu windows (haven't don that yet), any linux and any other AIX, solaris or other older POSIX system and the code runs. with those .jars I always need the right version of JDK installed by an admin and it always seems tricky to get things running. need to change manifests, security settings on OSes of java installs change all of a sudden. oh and then we have these nice java 3d dependancies that require OS specific binaries installed again.

so I hence my question. really portable java?

Yeah, yeah, yeah, now show me your build script, tool chain and dependencies.

I have a JDK and ANT and while the scripts can get complex, this is due tot he complexity of the app, not the complexity of how to compile this particular bit of code on this particular host for some particular target.

I grant you that a solid, mature portability ecosystem has grown around C (several, in fact), but those things don't make C more portable.

They make it easier to port C.

There is a big difference.

Re: Why Java?

[Anonymous Coward]

The story is not that simple. Even with smart pointers, you can't just blindly use them without thought. You always have to think about ownership and some gotchas like circular dependencies (which you probably need to solve with weak pointers). But the other thing that most people don't think about is that construction and destruction of objects is expensive and when you reference count goes to zero, it might not necessarily be a good time (performance wise) to de-allocate. That is why we have to think a step further and do things like object pooling to avoid constantly allocating/de-allocating and also think carefully about using move operations.

The thing about Java's garbage collector is it almost acts like an object pool and thus avoids the performance penalty of de-allocating at the wrong time. what most people don't know is that there are 4 built in garbage collectors you can choose from, and the STW (stop-the-world) one everyone is familiar with is the default one, but you are free to choose something that makes more sense in your application if you want something that considers realtime systems better. The idea is that you've delegated memory management to the JVM and it decides when it is optimal to deallocate (yes, the memory footprint is larger, but it's a balancing act to get the best CPU/memory performance).

At the end of the day, if you are building a server-side application where IO (e.g database) is the bottleneck, then it doesn't make sense fussing too much about the last ounce of CPU performance. In other words, it's like running to get to the bus stop only to realise the next bus is 5 hours away. Java has it's place (and obviously C++ and C does too) just don't let this GroupThink phenomenon of what's trendy/lame affect your decisions what tool is right for the job. These languages were properly engineered by brilliant people and not hacked up by some no-it-all like some other languages

Re: Why Java?

[Anonymous Coward]

C and C++ Code from a seasoned EXPERT (not a junior developer) *can* (if so desired) be highly portable.

And it will be at least two times more RAM-efficient than competing Java code. ...

I work for a guy who refuses anything but c++, even though it is fundamentally a data management problem, and SQL/Java/C# is going to be way less pain, easier to maintain, and more than likely quicker.

Basically if your using C for performance, then I first have to ask, have you looked at your algorithms and such? A good algorithm is worth way more than a lower level language. If you have looked at the algorithm and done all the other checks, then still need the performance (or from experiences knew you would from the start), then go for C/C++.

Of course if you just need spot extra performance, a library works for the trouble spots. Both Java and C# can integrate C that way, and C# can even share memory back and forth, allowing you to use the best of both.

Finally, ram usage is seldom a consideration, at least for low volume software. Yes, you still have to have some care, regardless of language, but installing 16GB or more of ram is not a big deal anymore. Now if your making something used by thousands, that is another matter.

It is all about cost vs benefit. Java/C# is going to be far easier to maintain and use, with fewer engineers working on it for less time. Yes, it may not execute quite as fast as if you went all out with a fully optimized solution in C++, but, realistically, are you being paid for that?

Re: Why Java?

[Espectr0]

If you want to argue c is better than Java, argue on it's strengths... Performance, bare metal control, and platform support (a lot of very small embedded platforms don't have a Java runtime... or it's terrible). Java beats C hands down in portability.,

Having C available on every platform is portability for some people. Regarding that metric, C beats Java easily.

Re:Why Java?

[Anonymous Coward]

Pretty much everything you told yourself you heard is wrong.

The biggest reason to use Java is that there is a library for just about everything already available. Even if you wind up not using one, people can throw up prototypes quickly. Especially with some of the other, boutique languages that also run on the JVM and can call those libraries.

Re: Why Java?

[Anonymous Coward]

"Java beats C hands down in portability."

What non-sense.

I'm very sure you will find more machine architectures out there for which a C compilers is available than a JVM.

Besides, the JVM is written in C/C++ so C/C++ so Java cannot be more portable than C/C++.
 

Re:Why Java?

[tigersha]

Java is a crummy language (which did not stop meusi g it for 10 years) but the real key here is the JVM. There are many other good languages running on a very stable and tested server platform.

As for GUIs in Java, just no. Bad.however, 15 years ago it was a viable choice.

Re: Why Java?

[tigersha]

It also takes 10 times the amount of effort than Java to get to that point because you restrict yourself to the point that you have to reinvent all the wheels.

Funny you should mention Lua as example here. Inventing. new Language to make C useful is a proof that C is problematic, yes?

Re: Why Java?

[tigersha]

EJB is probably the most singular reason people hate Java so much. You just ruined my appetite for just mentioning it :)

Re: Why Java?

[Anonymous Coward]

Fast-forward 20 years to today and there are dozens of cross-platform interpreted languages. The web went JS+CSS+HTML, not Java. LLVM have brought many compiled cross-platform languages too (Swift, Rust). Then there's Go. Even Microsoft C# is as portable as Java nowadays.

(former J9 dev)

Re:Why Java?

[Anonymous Coward]

UX? Are you referring to Swing? It is somewhat deprecated these days. I use a Swing GUI all day long as a developer, but most Java code doesn't have a user interface, or it is HTML5.

That aside, the ecosystem is for me the most important reason to use Java/JVM. Besides that; The platform has a wide selection of other languages for those who feel Java is to "dated".

Re: Why Java?

[TheRaven64]

Some JAVA code might run slightly as fast as C but definetly is never bare metal

You might look at Java Card. It's a fairly restrictive subset of Java, but it is one of the most widely deployed instances of any language ever. For example, it's present in all SIM cards, many door-access cards, and so on. A number of Java Card implementations have the bytecode decoder implemented in hardware and so run the Java directly.

Re: Why Java?

[TheRaven64]

Java beats C hands down in portability.

That's not really a fair comparison. The C specification defines a language and a very small standard library. The Java specification defines a language and a huge standard library. For anything where Java is an appropriate choice, you're not going to be writing C and relying on just the C standard library, you're going to be using some third-party toolkit that, like the Java standard library, abstracts away a lot of platform independence.

Even then, I'd disagree. Java is good for portability if you're using one of the common platforms, but the further you get from that, the more patchy it becomes. Try running Java on OpenBSD / MIPS (actually, try running Java on any OS on 64-bit MIPS - the only implementation that mostly works is JamVM, and it's a simple interpreter that doesn't support the latest version of Java) and you'll find that the portability isn't quite as good as you might think.

Java is portable to any platform that the JVM and standard library have been ported, but the same is true of most languages: they'll run on any platform where the compiler and the libraries that you're using have been ported. The difference with Java is that it tends to be an all-or-nothing proposition. You aren't allowed to ship partial implementations of Java (the patent grant on the various bits of Java only extends to fully conforming implementations) and so you're unlikely to find a subset of Java that does everything (or almost everything) your program needs working on a platform, whereas you often will with other languages.

Re: Why Java?

[TheRaven64]

C++17 is pretty much my go-to language these days, but this is just plain wrong:

These days we use smart pointers, which have almost no overhead, and easily avoid memory leaks and memory management

The C++ standard library provides two kinds of smart pointers (ignoring weak ones for now): std::unique_ptr and std::shared_ptr. The former doesn't have 'almost no overhead', it has exactly no overhead, because the entire implementation is optimised away. The latter; however, can have significant overhead. C++ relies on deterministic destruction and so none of the techniques that are normally used to optimise reference counting can be used: as soon as the last std::shared_ptr to an object is destroyed, the object must be destroyed. This means that every copy of a shared_ptr is an atomic increment and every destruction is an atomic decrement. If the object is not shared between threads, then this is very cheap, but if it is (even if the object itself is immutable) then each pointer copy and each pointer destruction can have around a 300-cycle cost (plus the cost of the branch in the destroy case). This can add up quite quickly. In contrast, a language with a tracking collector can make most pointer manipulations as cheap as bare pointers. In terms of throughput, tracing GCs scale a lot better to multiple cores than this kind of atomic reference counting, though they trade some worst-case latency for this (which can be a problem in distributed systems).

Re:Why Java?

[TheRaven64]

No dirty macro preprocessor

Unfortunately, no macro preprocessor or templating system at all which means that everyone invents their own. I've seen Java code that had sed, awk, Perl, Python, and Ruby as preprocessing steps (and a few projects that used more than one).

Re: Why Java?

[pkphilip]

You are arguing that java should not be used because one of the dozens of mvc libraries had a security issue? That is similar to saying operating systems should not be written in C because operating systems written in C have had security vulnerabilities in the past

Re: Why Java?

[Anonymous Coward]

If you want to argue c is better than Java, argue on it's strengths... Performance, bare metal control, and platform support (a lot of very small embedded platforms don't have a Java runtime... or it's terrible). Java beats C hands down in portability.,

Having C available on every platform is portability for some people. Regarding that metric, C beats Java easily.

C more portable?

How about you post a portable, standard-conforming way to get the size of a file in C?

Hint: you CAN'T.

Re: Why Java?

[Anonymous Coward]

Because coding in Perl is like having a root canal.

I feel the same way about Java...

Re: Why Java?

[drinkypoo]

For example, it's present in all SIM cards, many door-access cards, and so on. A number of Java Card implementations have the bytecode decoder implemented in hardware and so run the Java directly.

Sure, you can even get a Java iButton. But these implementations don't have to be fast, which is a good thing, because they are not. They have small, simple jobs to do.

Re:Why Java?

[Anonymous Coward]

C can absolutely be portable so long as there is an available C compiler on the target system or a C cross compiler for the target system and you maintained compiled binaries for each target system. It has been many years since I've seen an issue with Java class files not working correctly on any machines with a certified JVM regardless of the OS used to build the class files.

Re: Why Java?

[Anonymous Coward]

I've always been a big fan of Tcl so I agree with you there, but why leave out a major portable player - Pascal?

p-code interpreters were frequently one of the first tools ported to new operating systems so that a Pascal application could run to boot-strap the creation of a native compiler for the new host OS.

Re:Why Java?

[Anonymous Coward]

It's going to be difficult to explain to someone who doesn't use Java why people use Java. Java really isn't a front-end application language, despite a few attempts to relaunch this (JavaFX, for example), and a few oddities (Minecraft PC), it is primarily used in enterprise application middleware development.

Hardly anyone uses it for portability - although Minecraft is a fairly good example of a Java application with dependencies that can run on multiple systems that have a full JVM without issues.

People use it because the infrastructure around Java is extremely mature, in particular for managing and writing enterprise applications. In addition, the JVM platform means that Java isn't the only language you are limited to, giving some freedom to developers to use, e.g., Scala or Clojure or Kotlin, yet still deploy on their business' JVM infrastructure (usually an application container).

In addition, it doesn't have the unnecessary complexity of C or C++. Unnecessary for this level of development, that is.

You won't find many Java developers prepared to eulogise the language itself as being particularly brilliant in any way. Usually you will get "about time" for new features that finally cut down on the boilerplate required (although as the IDE will manage all this anyway people don't care either).

Re: Why Java?

[Anonymous Coward]

So writes the person who clearly hasn't used Java in a decade and simply doesn't understand why people use Java.

RAM doesn't matter (it's cheap compared to developer time), and most Java apps run on servers, not clients.
Real-time doesn't matter in the Java ecosystem, you wouldn't pick it for the real-time aspects of a system. That's why wages for real-time embedded stuff are higher.
Nobody wants to be fiddling with allocation and deallocation - that is valuable developer time, valuable debugging time.

Re: Why Java?

[Anonymous Coward]

Luckily any decent enterprise Java shop moved on from EJB a long time ago.

Re: Why Java?

[Gr8Apes]

EJB is probably the most singular reason people hate Java so much. You just ruined my appetite for just mentioning it :)

That's like hating C because of Windows. EJBs are an abomination in implementation, although the concept itself is egalitarian. I'm just not sure it can be handled in Java, at least not with the loose constraints they used. CORBA is a much better implementation as it succeeds where EJBs fail, in providing usable service APIs behind which you can do what's needed. It's no panacea, but at least it is serviceable.

Re:Why Java?

[Anonymous Coward]

Java apps may have minimum versions, typically just to the major number e.g. Java 7. Byte-code and JRE/JDK APIs do not undergo breaking method signature changes on smaller level upgrades. The major number takes years to change. You may be thinking of ruby or python that are so version specific tools like rvm are basically a requirement to deploying.

The GUI does suck. Most java applications are web-services or headless processes, minecraft is the most popular exception.

The frameworks however are very mature, readily available, and cover a wide spread of many tasks. (all libraries have vulnerabilities found periodically, native, java, etc).

Re: Why Java?

[K. S. Kyosuke]

Designing a new language to solve a particular problem domain is the ultimate technique in programming and isn't generally shunned.

Re:Why Java?

[Shirley Marquez]

Java remains popular in programming classes because of that portability. It means that the TAs will be able to run student code, whether it was developed on Windows, Mac, or Linux. (Universities generally don't mandate ownership of a specific type of computer.) Most programming classes (except for ones that are specifically about developing GUI applications) don't use a GUI so that's not a factor.

Re: Why Java?

[Anonymous Coward]

The difference between Java/C# and C/FORTRAN/etc. is when the transformation from AST to machine code happens.

unless you are using Chrome's PNaCl, and then it happens at the same place, even for C++.

Re:Why Java?

[Anonymous Coward]

Honestly, the development environment is pretty nice. I didn't have nearly the amount of library conflicts and "why the fuck doesn't this work" moments I have when working in C or even .NET. I could write the project once and the resulting jar would run on every desktop platform as long as it had a JVM, and I could bundle the JVM if I felt like it. dependencies were relatively minimal because the classpath already bundled so much.

C libraries and build environments are a god-awful mess, you can tell because of how many tools exist to manage builds.

Is Java verbose? Does the GC cause issues? Is SWING ugly? Yes. So what. It worked and I spent most of my time on code problems, not build environment problems or deployment problems.

Re: Why Java?

[Anonymous Coward]

Frankly I run a Java shop .... enterprise server based systems and have never ever ported java .... not once in 20 years from a Dev till making Tech Director. While my shop is mainly Java, I am well versed in half a dozen dozen languages.

The types of systems Java has its sweet spot on actually doesn't need porting.... they just run for 10 years before the hardware is obsolete and the cost to reinvest in hardware make sense to do a re-development.

Really the early days of performance bad name is not really relevant anymore.... still not as fast as C, but unless you are pushing performance boundaries decent Java code really isn't noticeably slower. And the infamous pauses for garbage collection are no longer an issue for any server deployment.

The over engineered And slow days of J2EE was also over and Java evolved slowly to be a little more nimble.... still not as much as some others but making up in other ways.

Java also still has the largest Eco system for its sweet spot.... enterprise systems.... endless libraries to do any shit you want in an enterprise setting that's pretty much why it survived.

Java, C and C++ have been the longest surviving languages (apart from
  Assembly) and all have adapted to survive. I think that is a testament to their greatness. I don't see why we should not give it the credit it deserves.

I would always recommend our Analytics and Machine Learning teams run Python, but so what? Just choose the right tools for the right job and balance your niches well with a few sustainable languages.... not everything have to be perfect. Developer skill is always... I dare say... ALWAYS superior to what ever language is being used.

What I don't get is why these "which language is better" conversations have to sound like comparing dick sizes.

If we need to compare dick sizes I would propose using coding skill is way superior. At least you are comparing dick sizes and not the brand of fabric you use to cover your dick.

Re: Why Java?

[Beezlebub33]

As a java developer, I have found that python libraries for machine learning, scientific computing, and numerical processing are much better. Numpy / scipy, scikit-learn, and the like are truly amazing, blazingly fast, and the ability to do terse matrix slicing and dicing is so much more efficient. And Jupyter makes it into a live web-based analysis and visualization tool. Almost like magic.

I still do most of my development in java, I understand the ecosystem better, can control the dependencies better (gradle FTW), can make a much larger application, better unit and integration testing, code coverage, can throw it into Tomcat and manage it, can do auth/auth in standard ways, etc. But if you are doing math, python beats its pants off.

Re: Why Java?

[The Evil Atheist]

I have no idea what you're doing wrong, since I've never encountered anything you're talking about.

Re:Why Java?

[The Evil Atheist]

The language is large, but I wouldn't call it a bloated mess. It's not bloated because it doesn't cost anything to not use a feature. In Java, you pay for things because you have no alternative. eg, you have to pay for virtual dispatch whether or not you need it. In C++, if you want polymorphism, you can achieve it without virtual dispatch. Most of the advanced language features are there for authors of generic libraries. It allows the complexity of the implementation to be truly hidden from the client code, unlike in Java where enforced inheritance hierarchies as a design pattern is leaked across API boundaries.

And what's wrong with external dependencies? You don't want external dependencies, yet you don't like C++ because it is a "bloated mess". What criticism do you want? C++ is too big or C++ is too small? You can only choose one. You can't talk out of both sides of your mouth.

Re: Why Java?

[Lothsahn]

What I meant by "it's more portable" is that my code runs on any supported system without modifications or with extremely minor modifications.

What you're talking about I called "platform support", which I explicitly called out in my post. C wins against Java for platform support.

In general, C runs on far more platforms than Java code, but it takes more work to support each platform. It also depends on if you want or need to target small, embedded, or niche platforms. The main CPU architectures and OS's have good quality JVM's available.

Re: Why Java?

[Lothsahn]

Agreed. I called that platform support. I admit my terminology was somewhat ambiguous.

See my comment here:
https://slashdot.org/comments....

Re: Why Java?

[Lothsahn]

Good points.

It's not a JDK

[klingens]

The summary is wrong in several counts.
It's not a JDK but simply a JVM. A JDK would comprise at least a JVM, a java compiler and the needed class libraries. As the linked FAQ in the first entry says:
"Is Eclipse OpenJ9 a replacement for OpenJDK?
No. Eclipse OpenJ9 is a Java virtual machine (JVM), the engine that runs Java applications, whereas OpenJDK is a complete development kit that contains other components, like the Java class libraries, as well as a JVM. By default, OpenJDK builds with a JVM called Hotspot."

The "unlike OpenJDK also has all the bells and whistles like jit" is also wrong.
Hotspot almost 20 years ago replaced the JVM of that age which was a JIT compiling virtual machine, as was standard quite some time before. Hotspot however has JIT too but also does adaptive optimization on the fly which was the new cool thing back then. As wikipedia says:
" It features improved performance via methods such as just-in-time compilation and adaptive optimization." What it does and why it is called Hotspot is, it constantly checks what parts of the code are used the most often and it then optimizes those parts over time further if possible.
However it always uses JIT compilation like almost every other VM software does. Maybe IBM has some secret sauce JIT that Hotspot lacks, but the summary doesn't tell which or gives any other indication why IBM JIT is better than old Sun JIT

Re:It's not a JDK

[cheesybagel]

I think IBM used to be a contributor to Apache Harmony? So they basically should have given away all the class libraries they used to have. AFAIK IBM switched to the OpenJDK class libraries after that was open sourced.

Re:It's not a JDK

[TheRaven64]

Entirely correct, though it's worth noting that J9 does look pretty interesting as a JIT. I've reviewed quite a few paper from IBM recently about it that mostly ended up being rejected on the grounds that J9 was an internal IBM thing and there wasn't much reproduceable science in them. IBM seems to be doing quite a lot of research on top of J9. Hopefully, open sourcing it will encourage other researchers to look at it.

Eclipse

[Anonymous Coward]

The IDE where the startup time is measured in geological time.

I've seen glaciers move several feet while Eclipse started up.

Re:Eclipse

[ledow]

Start... Run... Programming... Eclipse... Eclipse
(Yes, I use classic shell and old-fashioned start menus categorised and in alphabetical order).

1...
2...
3...
4...
5... (Splashscreen)
6...
7... (loading huge default-open project)
8...
9...

Loaded.

That's from a REALLY cold filesystem cache for it, I doubt it was in there at all.

Libreoffice comes up in 4, admittedly.

But Steam takes longer, as does a game called Factorio (to get to the MENU!) as does anything complex.

I wouldn't call it "long". And if it worried me, I'd just leave it in the background - I already never log off because... what's the point?

And that's on Windows. On Linux, it's so much faster.

Re:Eclipse

[Anonymous Coward]

Too bad you're still using a 90's Celeron for doing programming things. People has been using machines with quad-core and several gigabytes of memory for the last years. You should tell your boss to upgrade.

Re:Eclipse

[Anonymous Coward]

I have a dual octo core workstation and 24 GB of RAM and yet Eclipse is still a slow, bloated pig.

Re:Eclipse

[Anonymous Coward]

Well, I'm sorry you have spent so much money into that machine only to have the performance of a workstation from 20 years ago. Definitely something is wrong with your setup, mine is 1/4th of what you have yet eclipse or any other modern IDE fly.

Re:Eclipse

[alvinrod]

If it really takes that long, go grab a cup of coffee, run to the restroom, or do any other number of small mundane tasks that are going to occupy your time at some point in the day while the IDE starts. If stating the IDE truly takes that long on your machine and you're not just being hyperbolic, compiling is going to eat up even more time in which case you probably need a new machine.

Re:Eclipse

[Anonymous Coward]

Doesn't square with my experience... I use a notebook with 16GB and its fine, even when I'm running a couple different variants plus a all my other regular tools plus a Windows VM.

But in any case, slow compared to what? IDEA is a great tool, but also very resource-intensive. Most other languages don't even have IDEs that provide all the functionality that Eclipse and IDEA do (yes, I'm talking about you XCode).

Re:Eclipse

[Anonymous Coward]

Slow compared to even bloated shit like Visual Studio 2015 or Adobe products.

Re:Eclipse

[Anonymous Coward]

Maybe he doesn't have an SSD. I once worked with a guy who bought one of those huge Dell portable workstations, but he didn't put an SSD in it. Net result: I think Eclipse was faster on the MacBook Air I had at the time.

Re:Eclipse

[Anonymous Coward]

I'm sure your fart apps must load really fast, but some of us right real software not little toys.

Re:Eclipse

[Gravis Zero]

10 seconds? WOW! QtCreator starts and is fully loaded in under a second without cache.

Re:Eclipse

[ledow]

My virtual-speed-penis is obviously not as big as yours.

However, 10 seconds with a HUGE list of active and open projects in it is barely even noticeable, especially if that's the "uncached, hasn't run once yet this session, from nothing" speed on Windows.

On Linux (even a VM with identical projects and versions), it's half that at least, from cold.

Neither are "oh my gosh" slow. The times for anything like SQL Server Manager, or Visual Studio are no better.

Re:Eclipse

[Gravis Zero]

My virtual-speed-penis is obviously not as big as yours.

Whoa there buddy. I was just pointing out that 10 seconds is a really long time for software to start in 2017.

The times for anything like SQL Server Manager, or Visual Studio are no better.

Yeah, Microsoft has always been slow at everything. Desktop computers are lightning fast, so 10 seconds is far too long an amount of time to launch any program.

Re:Eclipse

[Gr8Apes]

I'll bet that QtCreator opening up in < 1s has maybe 1000 lines of code, not 5+ million across multiple cross-dependent projects.

Re:Eclipse

[MightyMartian]

I have an eight core notebook with an SSD drive and 8gb of RAM, and eclipse comes up very quickly. Very sorry you have such a badly configured system.

Re:Eclipse

[Gravis Zero]

LOL @ 1000 LoC. Whoever writes an IDE in 1000 LoC deserves either an award for their brilliance or a new keyboard so that they have a working "Enter" button. ;)

Re:Eclipse

[Anonymous Coward]

Where I (used to) work, all files being opened on the workstation were scanned by the slow virus scanner. Starting any program that opened a lot of files (DLLs, jar files, etc) was quite painful. Eclipse was just one that was particularly slow. Compiling a large project (using maven) could be horrendous due to this company policy. YMMV

Re:Eclipse

[Gr8Apes]

ROFL... 1000 LoC in the project code it's loading up at startup.

Re: Eclipse

[Anonymous Coward]

No you don't have an 8-core notebook.
At best, you have a 4-core plus hyperthreading enabled (4 more virtual cores).

Re:Eclipse

[Gravis Zero]

QtCreator makes no assumptions about what you will work on, so there are no open projects when launched. Btw, having 5M LoC of interdependent projects open automatically isn't a feature I want.

Re:Eclipse

[Gr8Apes]

QtCreator makes no assumptions about what you will work on, so there are no open projects when launched. Btw, having 5M LoC of interdependent projects open automatically isn't a feature I want.

It may be something you need to work efficiently. So you're really comparing apples and oranges there. How long when you open QtCreator does it take to open your project, be able to view the opened codebase for errors, and have it running a debug test session? With Eclipse, generally, once its done with its 10s opening, you're good to go with 1 click. And remember, you have a lot of code open, static analysis done, toolsets initialized, etc, it's not just a "open project now please" state.

Re:Eclipse

[Gravis Zero]

It would be trivial to implement via plugin but that seems like a terrible feature. Why would you need so many projects open all at once upon starting?

Re:Eclipse

[Gr8Apes]

Work on enterprise software. The details I can share involve past system projects which included up to 60 library and component projects which built out up to 10 separate servers, clients, and web applications. These were usually installed on sets of servers in HA/HR/HP configurations. When you're working across such projects and need to re-architect some base service definitions and functionality, yes, you absolutely do want that many projects open at once.

Re:Eclipse

[Gravis Zero]

No idea what exactly you are working on but it's clearly designed like shit.

Re:Eclipse

[Gr8Apes]

It's obvious you lack the experience and vocabulary to speak in this domain, and are only concerned with your own niche, much like a JS web developer calling themselves "fullstack" yet having no clue how to handle continuous levels of 20K transactions a second in a secure guaranteed fashion. (it's irrelevant whether you do, btw) When/if you graduate to large distributed heterogeneous enterprise systems, we may talk again. You won't be running QtCreator then.

So, its still GPL

[technosaurus]

If you want an ISC licensed jvm, there is https://github.com/ReadyTalk/a....
IIRC avian has its own class library or it can use OpenJDK or the Android class library.

I guess IBM no longer exists as a company

[cpurdy]

The original posting is so wrong in so many ways that I am now forced to question whether IBM the company actually exists, since the posting seems to indicate that it does.

Fuck u Larry.

[Anonymous Coward]

nt

F U /. for such a crap summary

[kwerle]

Is Eclipse OpenJ9 a replacement for OpenJDK?

No. Eclipse OpenJ9 is a Java virtual machine (JVM), the engine that runs Java applications, whereas OpenJDK is a complete development kit that contains other components, like the Java class libraries, as well as a JVM. By default, OpenJDK builds with a JVM called Hotspot. Put simply, OpenJ9 is an alternative JVM that you can include as part of an OpenJDK binary.

Is Eclipse OpenJ9 the same as Hotspot?

Hotspot and Eclipse OpenJ9 are both Java virtual machines that can be included in an OpenJDK build, but each has different capabilities. Depending on the build process you follow, you can build an OpenJDK binary that includes either Eclipse OpenJ9 or Hotspot.

Why use Eclipse OpenJ9 instead of the default JVM?

If you are looking for an enterprise class runtime environment for your application, build OpenJDK with Eclipse OpenJ9. This high performance, scalable virtual machine is at the core of many IBM enterprise software products, so it has a great pedigree.
You can also tune OpenJ9 to further improve the performance of Java applications for specific scenarios. For example, you can switch garbage collection policies to manage memory for different types of workload.

Why did IBM contribute their J9 virtual machine to the Eclipse Foundation?

IBM is publicly committed to bringing innovation into the open source development community. Contributing the J9 virtual machine, which has been at the core of IBM SDK, Java Technology Edition for many years, demonstrates that commitment. The OpenJ9 virtual machine is itself based upon core technology components of the Eclipse OMR project, which was contributed by IBM to the Eclipse Foundation in 2016. IBM continues to invest resources in both Eclipse OpenJ9 and Eclipse OMR to ensure that their enterprise products can take advantage of the latest hardware technologies.

Well

[Anonymous Coward]

Having read about security issues during the last 15 years or so, I have to conclude

* free and open source stuff might have less, but definitely not zero security risks
* there are boatloads of insecure FOSS stuff out there
* some FOSS is outright dangerous, such as the OpenSSL pile of $hit. Hundreds of exploitable bugs in "security" software.
* even core FOSS software such as the Linux kernel is far from watertight. See the gethostbyname() Linux kernel bug

java.io.AutoCloseable

[tepples]

As a language, Java has the huge advantage of automatic garbage collection.

Except for objects that represent a resource other than memory, which the owner must close() explicitly.

This is an issue in C, because it must be agreed on who will destroy the returned object.

Likewise in Java for instances of classes that implement java.io.AutoCloseable.

Lost the fox, you have..

[LesserWeevil]

When IBM out-maneuvers you on one of your core technologies, you've lost the fox. Hey Larry, what part of Sun have you not pissed away?

Domo Says

[Anonymous Coward]

This just in.... Nobody gives a f&$k

https://new1.fjcdn.com/pictures/This_6ac5f9_1668599.jpg