IBM Open Sources Their Own JVM/JDK As Eclipse OpenJ9 (eclipse.org) 179
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.
OpenJDK no JIT? (Score:5, Insightful)
Are you saying that OpenJDK doesn't have a JIT compiler? That seems untrue.
Re: (Score:3, Informative)
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? (Score:3)
Re: (Score:2)
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: (Score:2)
Spoken like a true English speaker :)
Why Java? (Score:5, Interesting)
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? (Score:5, Insightful)
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? (Score:5, Informative)
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? (Score:2)
Re: Why Java? (Score:5, Informative)
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? (Score:1)
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: (Score:3)
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: (Score:3)
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
Re: (Score:2)
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, ne
Re: (Score:1, Insightful)
C is an abomination designed by an NSA contractor in order to generate lots of buggy software to be subverted by NSA malware.
Re: (Score:3)
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: (Score:2)
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: (Score:3)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3)
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: (Score:2)
See my comment here:
https://slashdot.org/comments.... [slashdot.org]
Re: (Score:3)
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'r
Re: (Score:2)
Re: (Score:1)
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? (Score:2, Informative)
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? (Score:1)
Your srgument is that C++ is better today than Java was 20 years ago?
Re: (Score:1)
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 w
Re: (Score:2)
EJB is probably the most singular reason people hate Java so much. You just ruined my appetite for just mentioning it :)
Re: (Score:2)
Re: (Score:1)
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? (Score:4, Informative)
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: (Score:2)
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: (Score:2)
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: (Score:1)
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: (Score:3)
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, ab
Re: (Score:1)
Re: (Score:2, Insightful)
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: (Score:1)
Re: (Score:1)
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 a
Re: (Score:1)
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? (Score:2)
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, w
Re: (Score:2)
- 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: (Score:2)
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: (Score:2)
Re:Why Java? (Score:5, Informative)
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? (Score:4, Informative)
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? (Score:1)
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: (Score:1)
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
java.io.AutoCloseable (Score:2)
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.
Re: (Score:2)
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 [twitter.com]
(NTTAWT, as long as it doesn't interfere with the quality of the output)
Re:Why Java? (Score:4, Insightful)
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: (Score:3, Insightful)
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.
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
Re: Why Java? (Score:2)
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 thr
Re: (Score:3)
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 et
Re: Why Java? (Score:3)
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: (Score:2)
Re: (Score:2)
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) wa
Re: (Score:2)
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
Re: (Score:2)
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 che
Re: (Score:2)
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, busines
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:3)
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: (Score:2)
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... [equifaxsecurity2017.com]
Re: (Score:2)
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: (Score:2)
Java is an excellent choice for application servers
Yeah, excellent for criminals to breach servers running web applications written with Apache Struts.
Re: (Score:3)
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).
It's not a JDK (Score:5, Informative)
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: (Score:2)
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.
I guess IBM no longer exists as a company (Score:1)
Re: (Score:2)
Eclipse (Score:3, Informative)
The IDE where the startup time is measured in geological time.
I've seen glaciers move several feet while Eclipse started up.
Re: (Score:3)
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'
Re: (Score:2)
10 seconds? WOW! QtCreator starts and is fully loaded in under a second without cache.
Re: (Score:2)
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: (Score:3)
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: (Score:1)
Re: (Score:2)
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: (Score:1)
Re: (Score:2)
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: (Score:1)
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: (Score:2)
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: (Score:1)
Re: (Score:2)
No idea what exactly you are working on but it's clearly designed like shit.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
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.
So, its still GPL (Score:2)
IIRC avian has its own class library or it can use OpenJDK or the Android class library.
F U /. for such a crap summary (Score:5, Informative)
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.
Lost the fox, you have.. (Score:2)