What is Reddit's opinion of OpenJDK?

As a Java developer, I don't get why all the hate. :(

Oracle can be a pain with the stupid offers, but it's not like you can't disable them.

(https://www.java.com/en/download/faq/disable_offers.xml)

Or use a different JDK

(http://openjdk.java.net/)

I like my checked exceptions. :(

Pretty much all open source Java work is happening in OpenJDK. This email is by aph, who is a Java maintainer in GCC and also leads several OpenJDK projects.

Protip: Don't use currentTimeMillis() for benchmarks.

Side note: an article about nanoTime() written by one of the OpenJDK devs: https://shipilev.net/blog/2014/nanotrusting-nanotime/

EDIT: He's also the guy that wrote JMH

Probably this:

>When searching a module path for a module of a particular name, the module system takes the first definition of a module of that name. Version strings, if present, are ignored; if an element of a module path contains definitions of multiple modules with the same name then resolution fails and the compiler, linker, or virtual machine will report an error and exit. It is the responsibility of build tools and container applications to configure module paths so as to avoid version conflicts; <strong>it is not a goal of the module system to address the version-selection problem</strong>.

The JLS changed quite a bit for Java 8. One major (overlooked) reason was JEP-101. This meant that early Java 8 compiler versions (including update 45) were full of bugs including:

Rejecting code that should have been fine
Compiling code that should have been rejected

So, yes. Upgrading from 45 to 131 certainly changes compiler behaviour.

For a little history, Raw String Literals was proposed for JDK 12. However, it was was dropped due to a number of limitations that was discovered last December. Discussions were resumed with a renewed focus on on the weak aspects of the original design. The result is this new proposal.

Project Panama is in active development, see http://openjdk.java.net/projects/panama/.

Panama is not yet faster than JNI, but this is to be expected: https://mail.openjdk.java.net/pipermail/panama-dev/2019-March/004834.html

Openjdk is still literally GPLv2 with classpath exception It's in debian main, not contrib or non-free. It's still as open and free and "supported" as linux, gnu coreutils, gcc, emacs (that is to say fuck all "support" other than the community, but turns out that often works fine), as oh, a bunch of other open source / free software stuff that basically everyone uses. It's only accumulated more stuff that used not to be open since the sun takeover, like jmc. And even if you don't like java the language (though it has improved a lot), it's still that mature, fast, jit-compiled bytecode virtual machine thing going on too. You know, the JVM. It's what Kotlin runs on. It's what Scala runs on. It's what Ceylon runs on. While those languages may have other experimental backends, if really using them in anger, chances of you not in fact targetting the JVM with them are tiny. It's everywhere and actually pretty okay. If oracle went completely mental, we can still fork the last free openjdk, and they know that.

Sure, criticise oracle for their evil api-copyright stance in that oracle vs google lawsuit, I sure do. I don't even like java or like or trust oracle particularly, but come on people, get a grip. This is barely even centos/fedora vs rhel level stuff, oracle certainly full-time people officially working on openjdk and basing all their shit on it and have not exactly shown signs of openjdk weirdness even to the extent of redhat and that politely pretending centos doesn't exist nudge nudge wink wink. You can always use openjdk, unless you need "professional support" for corporate-ass-covering, like one might use rhel instead of centos, and even then as the article notes there's other people with commercially-supported jdks if you don't like giving oracle in particular money.

Java has bundled a javascript interpreter (in the standard JSE distribution) since 2006: https://jcp.org/aboutJava/communityprocess/final/jsr223/index.html

The previous interpreter (Rhino) was just replaced by a better-performing (once jitted) and more modern one too: http://openjdk.java.net/jeps/174

To give credit where credit is due, you have to recognize that Compact Strings is the effort that could not be pulled off by one man. Tobias Hartmann did most of the work on JIT compiler side, while Xueming Shen implemented lots of JDK parts, and many others, including but not limited to Charlie Hunt (of "Java Performance" book fame), Brent Christian, Roger Riggs, Vladimir Kozlov, provided support. ^The ^performance ^regressions ^and ^critical ^bugs ^are ^their ^fault ^as ^well!

Honestly, these build numbers don't mean much. Oracle bumps the build number every 2 weeks. The build number doesn't really map to a milestone or anything.

The actual schedule with major milestones is here.

JMH isn't unique to 9. You can use it with older versions right now: http://openjdk.java.net/projects/code-tools/jmh/

You can see the benchmarks running against JDK8 in the JMH author's blog posts in 2014: https://shipilev.net/blog/2014/java-scala-divided-we-fail/

JEP 230 clearly says:

> Add a basic suite of microbenchmarks to the JDK source code, and make it easy for developers to run existing microbenchmarks and create new ones. > > Based on the Java Microbenchmark Harness (JMH)

Nothing says JMH is new.

That title is borderline stupid.

It's a proposal for a formalised no-op GC, and it's insanely useful for testing new GC implementations.
Gives you a nice target to aim for, as the system you're developing a GC on might actually just be terrible, and not inherently the GC you're developing.

As far as I'm aware, it's already implemented in OpenJDK, this is more or less formalising it, to make it standard.
You can already activate it via:
-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

For those that were wondering, it basically just allocates a block, and never reclaims any of it. Memory allocation becomes cheap because bumps.

Another good reason for this, apart from general GC performance tests and improvements, is because Shenandoah is being developed.

EDIT: I'm writing this here, because no one reads the article anymore.

The Hotspot JIT doesn't constant-fold final fields by default, but there are some options to enable it, and there is a JDK-internal annotation @Stable that will enable it in specific cases.

I believe the Azul Zing JIT will constant-fold final fields and will deoptimize if they're changed. See Anna Thomas' talk at JVMLS 2018.

https://www.youtube.com/watch?v=2HfnaXND7-M

According to http://openjdk.java.net/jeps/3, no JEPs will be targeted for release after the end of RDP 1. So yes, if 18 will release in March 2022, we should know by the middle of December 2021. Unless the schedule gets adjusted of course.

I keep confusing the ZGC with JEP-318 which creates a no-op GC called Epsilon, also shipping in 11. Mostly because I think the Z stands for Zero.

But it's good to have more options for GCs, because I suspect no one GC will cover everyone's usage pattern. Just like the Linux kernel has different IO schedulers for different workloads.

Incidentally, we're due a Final RC today.

For people not versed in these terms, [Project Valhalla](https://en.wikipedia.org/wiki/Project_Valhalla_(Java_language\)) is experimental features:

Value Types; highly-efficient small 'objects' without inheritance.
Generic Specialization; List<int> for example
Reified Generics; retaining actual type at runtime.
Improved 'volatile' support.

Project Panama is improving support for calling non-Java libraries. In particular native library calls.

[Graal](https://en.wikipedia.org/wiki/Graal_(compiler\)) is a compiler project.

They are changing the versioning system starting with the next release: http://openjdk.java.net/jeps/223. It will bring the actual version closer to what everyone already calls them.

Java 9 will be "Java 9" (or 9.0.0) and Java 10 will simply be "Java 10" (or 10.0.0). There's no "1.9.0" and "1.10.0" or anything.

> 15 packages are using underscore or enum as a keyword, which hopefully should be easy to fix everywhere.

I think this means to say

"15 packages are using underscore or enum as an identifier, which hopefully should be easy to fix everywhere."

enum became a keyword in Java 1.5 IIRC
_ as an identifier became a warning in Java 8 and disallowed in Java 9. It looks likely that it will be a keyword (or more correctly perhaps, a special identifier) in JDK10.

The whole --source, --target thing has been replaced with a --release mechanism instead. This should be better (compiling against not only the same grammar and to the target class-format but also against the right API) but might trip up, if it can't find the older java version to use, as the JEP reads as though it needs images of the targeted release.

Another avenue for failure might be that some combinations of GC have been dropped so a build might succeed but execution could fail.

Great exercise though. I think a lot of devs will be wondering how easy it will be to move to Java 9 - there are some compelling reasons in development and runtime environments to want to do so.

I'll be curious to see how this compares to the Shenandoah garbage collector. That's another JVM garbage collector with a focus on low latency at a small tradeoff for total throughput. http://openjdk.java.net/jeps/189 - right on that page they state that they look forward to a comparison against ZGC.

The source code was donated to OpenJDK, so, yes, JMC is now free to use.

> The Mission Control source code is made available under the Universal Permissive License (UPL), Version 1.0 or a BSD-style license, alternatively. The full open source license text is available at license/LICENSE.txt in the JMC project

Edit: The JVM 'Flight Recorder' part was already donated a while ago and is targeted at OpenJDK 11: http://openjdk.java.net/jeps/328

Not to nitpick, but from their GitHub:

>Each GraalVM component is licensed: >
> - Truffle and its dependency Graal SDK are licensed under the GPL 2 with Classpath exception. > - Tools project is licensed under the GPL 2 with Classpath exception. > - TRegex project is licensed under the GPL 2 with Classpath exception. > - The Graal compiler is licensed under the GPL 2. > - Substrate VM is licensed under the GPL 2.

For those of us working at big corporations, the specific license can be a big deal. Here's OpenJDK's JEP for Ahead-of-Time Compilation with more information about how to use this if you're an OpenJDK fan.

Java 9 modules should do this. Otherwise as far as I know you have to look at languages like Ada 2005, which has explicit support for hierarchical packages in that sense.

Oracle's HotSpot isn't the only JVM in town.

OpenJDK Upstream
gcj Compiled java
Zulu Azul's build of OpenJDK

Why not just use JMH(http://openjdk.java.net/projects/code-tools/jmh/)? It has a lot of fixes for various benchmarking issues such as test code not using a return value so the JIT can do too much optimizing. It has a BlackHole object you can consume stuff with and it prevents the JVM from doing incorrect optimizations. Also does warmup cycles and generates a nice report in the end.

But the point stands - performance testing and profiling on the JVM is difficult.

Also, as a last point (aside from what has been said already), this is a great time to learn JMH, a tool that makes it very easy to write micro benchmarks as such (that tries to minimize things like GC, JIT warmup, etc)

http://openjdk.java.net/projects/code-tools/jmh/

Meanwhile in Java they are adding <code>var</code> as a keyword.

It's functionally unrelated to this deprecation, but it seemed funny to me that we are deprecating the word and they are trying to add it.

Not a good advice anymore as there is no autoboxing. The improved(Indify string concatenation) implementation means that a methodhandle is created to fill in a string template with parameters. This method signature will consume primitives directly without having to box them. How these parameters are used and later converted to the resulting string depends on the implementation(the JDK ships with a few of them even), but will likely be more performant.

Heck you could even write an implementation that pads ints with spaces so you can allocate the whole char array template first and replace single chars with the actual provided int values.

> Even if this is simply not feasible within the JVM environment

I think String is about to switch its internal representation from to use byte instead of char for its buffer (and maybe even switch to an internal encoding of UTF-8, although that has serious performance implications, so it may not be done). See JEP-254.

There's a prototype JVM by AMD that compiles Java bytecode to their GPUs, and runs parallel streams on the GPU. This is getting integrated into OpenJDK.

The expert group talked through all the remaining issues in the past few weeks, as reflected here: http://openjdk.java.net/projects/jigsaw/spec/issues/

Looks like consensus was (mostly) achieved by clarifying the spec, adding one method to ModuleLayer.Controller and by postponing other features to a next release.

The Android implementation goes one step further - it actually inlines the char[] array into the object (on the VM level), the JDK version still has an embedded "private final char value[]".

The 7u6 change was "pure Java" and just removed the offset/count fields, which saves bytes (and complexity) in the common case but prevents substring sharing.

There is a JEP for more compact strings, but AFAICT this only tries to use byte[] arrays instead of char[] for ASCII strings: http://openjdk.java.net/jeps/254

Of course it has. It is step number zero for anyone who wants to contribute to OpenJDK:

http://openjdk.java.net/contribute/

> Like many other open-source communities, the OpenJDK Community requires Contributors to jointly assign their copyright on contributed code. If you haven't yet signed the Oracle Contributor Agreement (OCA) then please do so, scan it and e-mail the result to oracle-ca_us(at)oracle.com. <...> > > The OCA gives Oracle and the Contributor joint copyright interests in the code. The Contributor retains copyrights while also granting those rights to Oracle as the Community's sponsor.

> Versions can be declared and required - although current early access build does not support them yet.

Any citation for this? My understanding was that the module system would not have any understanding of versions. That was based on this posing (reddit thread) from Mark Reinhold.

The comparison of C++ resource management with GC is not fair.

GC has only one purpose: memory reclamation. It is not for reclaiming resources of any other kind. A good GC language will have some other explicit syntax for reclaiming resources, such as Java try-with-resources.

GC is needed for only one reason: cyclic references. There is no decent way to guarantee that a program doesn't have them, and keeping track of them is potentially error-prone. Non-memory resources, however, don't have references, cyclic or otherwise, so GC is not needed to manage them. Non-memory resources also tend to have well-defined owners, whereas memory may or may not.

GC languages do tend to be more heap-intensive than I'd like, though. Java, notably, does not have pass-by-value for non-primitive types. This has given rise to the ugly practice of “defensive copying”, and no doubt made it considerably harder for the JVM to prove that allocating an object on the stack is safe.

It's being worked on, though, much to my delight. That will take quite a load off the GC, bringing us that much closer to the allocation performance of non-GC systems.

AFAIK, every capturing lambda is a new object when the variable it is capturing changes.

> The Java version went way up to around 800MB of RAM with the GC working tirelessly as expected. The F# version stayed at a nice 35MB.

What is the ram size and initial heap size you have specified?

> could we get similar performance characteristics in future Java version with projects like Valhalla/Loom/... .

Could you post the gist of your code?

There will be definitely be performance improvements from value types.(http://openjdk.java.net/jeps/169)

https://github.com/forax/valuetype-lambda

>To begin I want to make sure we're talking about the right version of Java

Move to OpenJDK of any version. OpenJDK is the java reference implementation and has been for a while.

>Does it include an OpenJRE? Can this be installed and work as a replacement for JRE on our clients?

It comes in both JDK and JRE versions downloadable here.

from the original mailing list post

> There are no unresolved P1 bugs in build 181, so that is our > first JDK 9 Release Candidate. > > Binaries available here, as usual: http://jdk.java.net/9 > > Mark

p.s. see also JEP 283: Enable GTK 3 on Linux

Great question!

An indication, all based on the current Java 9 Jigsaw ea build for OSX:

Full Java 9 JDK ~317mb
Helloworld + just java.base module in a custom jlink image ~31mb
Same as above, with full optimizations on ~21mb

edit: adjusted Full Java 9 JDK from 423mb to 317mb, since it includes all modules in two different formats for convenience of developers to create their own images. No fair to count those towards the total size.

Oracle and AMD are working together to make GPGPU a Java 9 feature.

It will use the Graal JIT compiler.

EDIT: Adding the links for more information

http://openjdk.java.net/projects/sumatra/

Search for GPU related talks on the links below,

http://www.oracle.com/technetwork/java/javase/community/jvmls2013-2013900.html

http://www.oracle.com/technetwork/java/javase/community/jlssessions-2255337.html

Download the SDK/JDK. The Reference Implementation is provided in source form for you, typically in a file called src.jar (or src.zip) in the root directory. (This happens for both Sun/Oracle and IBM's JVM's as far as I'm aware.) http://download.oracle.com/javase/6/docs/technotes/tools/linux/jdkfiles.html#jdk1.6.0_src_jar

Of course, you could also go here: http://openjdk.java.net/ for development versions of the open-source java implementation online in Mercurial.

Or here: http://harmony.apache.org/ for the sadly-on-its-last-legs "free" implementation.

Also, as someone who debugs bad java applications every day, I have to add: You should never base your application on the implementation of a given JVM. There are many ways to implement the specification, and many known implementations exist. The source (of only the public classes, usually) is provided to help you understand performance implications and debug your applications... not to cause later programmers headaches and indigestion. :-)

THIS IS BEING PROPOSED AS A PREVIEW FEATURE FOR JAVA 12.

Sorry to shout, but the title doesn't mention this, and none of the comments seem to discuss it. Being a preview feature means that this can only be used with a special command-line switch that enables it, that it shouldn't be used in production, and that it's subject to incompatible changes in future releases -- including being withdrawn entirely. See JEP 12 for information about preview status.

All languages borrow from each other. Java has had type inference for quite some time now (generics and lambdas), just not local variable type inference. The architects’ primary reason for introducing it was to eliminate boilerplate, not to “compete” with JavaScript. You can read the JEP here.

As for Kotlin, there is no proof that it will “disrupt the industry”. I guess time will tell, though.

In some regards erasure is a feature, not something to be 'fixed': https://olabini.com/blog/2010/07/questioning-the-reality-of-generics/

Value types in Java 10 may tip the scales, though full reification won't be on the table: http://openjdk.java.net/jeps/218

One problem is that many of the packages available for OpenJDK (e.g. Debian) do not have access to Oracle's Technology Compatibility Kit (TCK), which means the test suite has not been run against those builds. They may also be early builds rather than GA versions.

Azul produces Zulu, which are binary builds of OpenJDK that have gone through the TCK test suite. This could be an option for you, inasmuch as you trust Azul.

You can also build from source yourself, but then, you won't have access to the TCK either. You will either need to pay Oracle or be one of those OCTLA Signatories, which isn't an easy process (Debian has been waiting for access for a year or so, from what I hear)

I have seen Java ports of older C++ code be faster.

But when the two languages are coded side by side, Java is still on the order 1.5-2.0x the performance of the C++ code in most normal general purpose programming situations.

Much of this comes not from GC or the JIT being slow, but from more objects being allocated on the heap or inside of object wrappers, when they would have been native, stack-born elements in a C++ program.

Especially arrays and collections -- C++ has a strong advantage here as they can keep the memory contiguous and keep the code/data they need in the CPU caches easier.

They are working on value types for java which will include making memory contiguous collections/arrays possible. It will be a nightmare for the c++ guys, as Java is going to get a fuck of a lot faster when that happens. (http://openjdk.java.net/projects/valhalla/ for details)

I don't know if it's fair to say the JVM performs worse.

When the JVM runs out of memory, it fires up the Garbage Collector. Most GCs are made up of parallel and serial components. Some part of the GC runs in parallel with your application without stopping it. Some part may stop a thread at a time. Some part of the GC is "stop-the-world". This last part will stop your entire program completely while the GC works.

For small applications with multiple threads, the only issue is that your application will pause for small periods of time (a few milliseconds) whenever the stop-the-world phase is run. When you get to applications with large heap sizes (I am talking about >4 GB, but this is more apparent with even larger heap sizes), though, this pause time increases too. For really large heap sizes, you will see pauses that go up to a second.

Does the GC making your application pause for small periouds of time affect performance? It entirely depends: if this is a web service with latency requirements, then I guess you could say this is affecting performance. For longer-running tasks the pauses really don't mean anything at all.

So yeah, large heap sizes introduce latency. However, this may not matter to your particular application at all. Measure before you optimize.

Much of the latest work on GCs is on reducing this pause time:

TLDR: Measure before you optimize.

> Java is full of boilerplate code which obscures the programmers intention

Project Amber is addressing this. Local variable type inference has already been delivered. Switch Expressions and Raw String Literals will be previewed in 12.

AtomicReference/AtomicReferenceFieldUpdater: First appeared in Java 1.5

AtomicReference wraps a complete object in a controlled environment, whereas AtomicReferenceFieldUpdate allows you to use an attribute of an object but does so via reflection. Different functions for different purposes.

sun.misc.Unsafe - there are many internal implementation classes needed to bind Java code with the operating system and none should ever be used.

VarHandle: introduced in Java 9, this is an evolution to a cleaner model that is moving to replace the sun.misc.Unsafe as described in JEP 193. It is being used internally in the AtomicReference class now instead of sun.misc.Unsafe.

So what you're seeing here is not that Java was just throwing in multiple approaches to doing the same thing, they are for different purposes.

With Java 9's modules system you have to explicitly export packages that you want available outside of your module. Check out this OpenJDK site for more info. As such, something marked as public is no longer available outside of your module, and in David M. Lloyd's eyes, no longer "public".

Neither side wants to advocate a new access modifier for the module, so one side is advocating for public to be limited to mean "public within this module, unless the package is exported", while the other side is advocating for public classes to always be exported and for the package-local access modifier to be changed to be the module-local access modifier.

> I am much more interested in changes that extend the language and improve its performance

What do you have in mind? I'd like to have three features for performance:

async/await to write concurrent apps
value types
application isolation (to split huge apps into smaller pieces with independent GC, so GC could work faster with shorter pauses)

Not an expert, but here are some of my early observations

> How much of Java (the language) would I need to know to be a good Clojure programmer?

Clojure has a fairly good ecosystem of idiomatic libraries available. Unless you are interfacing with Java libraries, you really don't need to know any Java. Clojure uses a functional coding style with much more in common with Scheme or Haskell than Java's objet oriented design. Understanding of the Java dev environment does make things easier.

> Do Clojure programmers consult Java documentation for APIs/libraries or do they have the equivalent docs for Clojure?

It depends on what libraries you are using. Clojure's basic data types (lists, vectors, maps, etc) are all purpose-designed for the clojure standard library and can be found on clojuredocs. Like python's help, Clojure provides a doc function that can print out a construct's doc-string on the repl:

user=> (doc +) ------------------------- clojure.core/+ ([] [x] [x y] [x y & more]) Returns the sum of nums. (+) returns 0. Does not auto-promote longs, will throw on overflow. See also: +' nil

> Do I have to deal with Oracle BS for JVM (licensing etc) or do I get to stay open-source and Oracle-free?

OpenJDK is open-source and copyleft(a modified GPL). From what I understand, clojure does work with it.

Yes, but lambdas themselves don't (necessarily) use generics. A lambda of primitive arguments gets translated to a primitive-argument method. Primitive (and value-type) specialized generics are coming in Java 10.

> After the Oracle vs Google trial, it's clear that Java is not an open platform.

OpenJDK is open source. It is very clear that it's a 'open platform'.

Not everything 'java' is open. But the same thing applies to any programming language you care to look at. There are plenty of ways to use C++ or Python that would cause you to end up violating somebody's copyright or patent. Java has some extra complications because it did not start off as open source, but that doesn't mean that Apache is stupid for using it.

As for why somebody would choose to use Java over C++ or Python... well there are plenty of good reasons. But it's rather pointless to go over them.

... and both (actually, Corretto is a build of OpenJDK) are made (primarily) by Oracle. Didn't you notice the logo on the OpenJDK website? Also, look at Corretto's license, issued to you by Oracle, and at its source code -- it's Amazon-packaged Oracle software.

A year-and-a-half ago Oracle open-sourced the entire JDK and made it completely free and open-source for the first time in Java's history. OpenJDK is the name of Oracle's Java implementation project, and other companies -- like Red Hat, SAP, Intel, Google and others -- collaborate with Oracle and contribute code to it. In addition to free builds, Oracle produces commercial builds of OpenJDK for support subscribers, called Oracle JDK, and that's how Oracle funds OpenJDK. Because OpenJDK is open-source, other companies -- Red Hat, SAP, Bellsoft, Azul, IBM, Amazon -- also build and package it, but Oracle does 90% of the work, and all of those builds are released under the same Oracle license. Who did you think makes and funds OpenJDK?

Anyway, if you use Java I'm afraid that you personally touch quite a lot of stuff related to Oracle, and probably benefit quite a bit from Oracle's contribution to you. As one of the hundreds of engineers Oracle pays to work full-time on OpenJDK (and Corretto, I guess -- there aren't many people working on it at Amazon), all I can say is: You're welcome!

Use the keytool:

>jdk-10\bin\keytool -cacerts -list | find "Certificate" /c Enter keystore password: changeit 80

Perhabs this is related:

> Root certificates are stored, by default, in a keystore file called cacerts. Prior to JDK 10, the source code contained an empty cacerts file, disabling the ability to establish trust and effectively rendering many important security protocols unuseable. To work around this shortcoming, developers had to roll their own cacerts keystore by manually populating it with a set of root certificates.

No clue about certificates here. Does it work if you run it with OpenJDK 8?

> In Java, we are still waiting for the new syntax to express collection and map literals. The syntax, which is so natural and handy in many languages.

As of Java 9 you have Convenience Factory Methods for Collections. (They moved away from specific literals as they don't give that much but are less flexible and add more syntax)

So your example becomes:

var carBrands = List.of("Saab", "Volvo")

var johnDoe = Map.of("firstName, "John", "lastName", "Doe")

Another detail:Integer::parseInt might throw NumberFormatException. If you want to handle that case, you'll get ugly syntax dealing with this inside the Optional stream unless you wrap it with something like sneakyThrows.

Yes, that is what Applets are (were) all about, a plugin to run Java inside a browser.

I wonder why you are going down this path, Applets are dead, and they are even scheduled to be removed in a future Java release.

http://openjdk.java.net/jeps/289

Project Panama is a project to help the jvm more easily perform native operations. Included in its scope are things like improved and much easier to use JNI in the vein of JNA or JNR, but with the performance of JNI. Targeting SIMD from within the JVM is also a piece of project panama, and will be the first piece included in jvms as an incubating module!

It won't break old code. Read the proposal:

>The identifier var will not be made into a keyword; instead it will be a reserved type name. This means that code that uses var as a variable, method, or package name will not be affected; code that uses var as a class or interface name will be affected (but these names violate the naming conventions.)

> OpenJDK works significant slower in Linux compared to OracleJDK,

Do you have any numbers to back it up? What versions of OpenJDK and OracleJDK are you comparing?

I know for that's it's true for the graphics stack. It may not be true forever; a new renderer is being designed to replace the existing one. Either way, android uses an entirely different graphics stack.

Are you intentionally ignoring the fact that OpenJDK is the official JDK now?

Edit: and it's not behind anything. OpenJDK 8 went GA more than a year ago source

The problem with java is that true value objects do not exist (yet).

JEP 169 & JEP 218 are still needed for that to work.

I took three Computer Science courses in high school -- Visual Basic, C/C++, and APCS (Java). While I still have to use other languages in my college classes from time to time, I continue to use Java the most in work, school, and play. While I'm sure others will disagree, I think it is very fun to develop with Java. The language lets you focus more on the abstractions you are trying to create, and less on low level details such as memory management.

The language is also not standing still. The architects are continuously looking at ways to evolve and steward it. Some current, popular projects are Project Amber, Project Valhalla, and Project Loom. I think you will find that Java is a great language, and has a great community built around it!

I don't think there's any direct up-voting as such, but since it's part of project Amber, you could check its mailing lists: http://openjdk.java.net/projects/amber/

Judging from past messages on the lists, it's definitely coming sooner or later. Last discussions I've seen have been about what to do with indentation on multi-line raw strings (strip or not, and if yes, how exactly).

This is obviously something people have thought about. Brian Goetz mentioned that it might be concidered in a future jep here: http://openjdk.java.net/jeps/326 What exactly is it that you would like to contribute here? Are you experienced with the java compiler code base? Do you know the ins and outs of the JLS?

You're doing a real disservice to the community by repeating things that are false. The classpath still exists. You don't need to (ever!) use modules. If you find that the JDK's modules (java.base, java.sql,etc.) are too restrictive in their visibility, there are options (add-opens, add-reads, add-exports) you can pass to java.

Please read the JEP (http://openjdk.java.net/jeps/261) or any of the numerous tutorials online.

It seems Java (and C# too) is gradually turning into a bad version of Scala. I've totally lost interest in the language which IMO never will become useful, but any improvements they make to the JVM in the Valhalla project like value types, specialization etc. will of course be good for other, better languages running on the JVM.

Parent post is over selling it. The .so format is specialized for Java. Really the code isn't natively compiled. Just goes though some passes that allows it to injected into the JVM code-cache sooner for JIT passes. And speed up some class loading bits.

You won't be able to link JVM .so's to C/C++ exe/so files.

ref1

ref2

ref3

I'm missing this one little feature in the article. It has big impact for its community: inclusion of the Marlin Renderer. It's a faster and more scalable 2D renderer in pure Java.

Laurent Bourgès, the primary author of Marlin, had a nice talk at FOSDEM 2016. He's an example of how a lone OSS developer can push his code to JDK and have a worldwide impact. That's a cool story.

This has nothing to do with the SDK, it has to do with the application that was compiled by the SDK. So in Android's case, it's the fact they used Oracle's open implementation of the Java API. OpenJDK has it's own (mainly down streamed by Oracle themselves) but has a specific license that guarantee's end users freedom of use and deployment, with the exception that the source code remains open. You can find this in the GPLv2 document. Theoretically, Oracle could stop contributing to OpenJDK but this would essentially be suicide for the company.

So to answer your question, probably nothing will happen to OpenJDK.

> you're probably OK with saving a bit more and just not having object identity at all.

Value objects FTW!

http://openjdk.java.net/jeps/169

(I think there have been other proposals with similar goals; this was just the first one that came up when I Googled.)

I think you do not understand the JCP process well enough. Through JCP anybody can submit a proposal, which will become a JEP. There is no distinction between real hard problems (there is a JEP for value types, for example - 169), trivial ones (such as 117), between broad changes (Jigsaw) and very limited in scope ( http://openjdk.java.net/jeps/177 ).

The fact that there are people working on JEPs that you think are useless does not mean that people do not work on JEPs that are important. It does not even mean that they are working less on them.

If you want to change something in Java, you can submit a proposal to the JCP and go through it.

I was referring to Project Valhalla.
Is it bad that I think the annotated types are too verbose? =(

int processWithNulls (@NonNull List<@Nullable Integer> ints)

It adds a lot of noise to reading code.

Well, for the memory allocation off the heap you can certainly go the JNI route. It won't be pretty but oh well. For the concurrency control - I think Doug Lea is working on slowly migrating away from Unsafe, so we shall see what happens.

You should be right.

There are some new features in Java 7 but since you have 0 experience, a book will suffice.

Once you have read the book (probably pretty quick with C++ and C#), just supplement the knowledge with something like JDK 7 new features

I would use ANTRL to parse the Java to an AST then walk that AST colouring the tokens as as I went.

http://www.antlr.org/

Here's a grammar file for Java written by the OpenJDK team

http://openjdk.java.net/projects/compiler-grammar/antlrworks/Java.g

JMC has already been open sourced as JDK Mission Control and is an OpenJDK project. I don’t know what they’re planning on doing with any binary releases in the future though.

http://openjdk.java.net/projects/jmc/

Source?

I can't find any info about this at http://openjdk.java.net/projects/amber/ or in the mailing list archives.

I did find an old, withdrawn, JEP from before Java 8: http://openjdk.java.net/jeps/154

>Struct MixedData does not have its data aligned. JUnion detects this and realigns the data automatically.

The Jvm/jit does this already. Since java 7.

http://openjdk.java.net/projects/code-tools/jol/

An example of such feature would be value types (structured stack-allocated objects) which would make perfect sense in Kotlin and especially Kotlin/Native. We're looking forward to the Project Valhalla that aims to add support for value types on JVM.

Nice. Reminds me of the recent Epsilon GC for Java - essentially the same thing as this is: http://openjdk.java.net/jeps/8174901. Epsilon was rejected to ship with OpenJDK (other than in debug dev builds), though. Is this Zero GC intended to be integrated into .NET Core?

> JMH is a Java harness for building, running, and analysing nano/micro/milli/macro benchmarks written in Java and other languages targetting the JVM.

Website: http://openjdk.java.net/projects/code-tools/jmh/

Visual Basic GUIs come in handy for things like restoring memes even if only partially: http://i.imgur.com/iVkvJqM.jpg I just forgot that scaling an image in gimp keeps it at relative resolution and the template is potato quality

Seems I need to work on my memeing skills, sorry. And here's the slides I got the dependency diagrams from, reading through Oracle & OpenJDK guys' notes on project jigsaw inspired this because I didn't get much else out of it

> both version should be loadable

Read up on layers. There's support for these types of scenarios, but it won't be as dynamic as for example with OSGi, by design.

I'm not sure the ability to ship a stripped-down version of the JRE is the most important benefit, although what we can say is that it isn't the only one. Project Jigsaw includes six different JEPs and jlink is only one of them, I'm guessing some people will think this JEP is more important than the other five put together, but that depends a lot on your needs.

Even if jlink doesn't ship, you still have the ability to use much better encapsulation thanks to the concept of modules, which should help library creators and consumers manage things in the future. In my opinion, anything that makes life easier to library creators is something that contributes to the health of the ecosystem, which means this would still be a good addition to Java.

What is Reddit's opinion of OpenJDK?
From 3.5 billion Reddit comments

➔ OpenJDK website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

What is Reddit's opinion of OpenJDK? From 3.5 billion Reddit comments

➔ OpenJDK website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

What is Reddit's opinion of OpenJDK?
From 3.5 billion Reddit comments