Java 11 released
infoq.com
infoq.com
I imagine the main target customer are the large enterprises and the like that want full support contracts for everything.
OpenJDK will be updated much more rarely, on a quarterly cadence only, including for security patches. So if you go the OpenJDK route, be ready to do some JDK-level patching yourself if you want to mitigate any zero-days that surface.
Fixes will also only be applied to the latest versions, so you'll need to be prepared to live on the bleeding edge and accept all the risks that come with that.
For those who weren't there to remember, the concept of Applets, or applications that ran in a web browser and didn't need an operating system to run, was apparently terrifying to Microsoft. Sun's senior management exploited that terror blunt the invasion of Windows desktops in Sun's enterprise accounts. So many complex technical issues resolved with the test "will it scare/attenuate Microsoft?" rather than "Is this what the language/system should be?"
[1] https://stuff.mit.edu/afs/sipb/user/marc/hotjava/doc/people....
Huh? The web browser/JVM certainly needed an operating system to run, and by extension the applets did too.
I wonder if any significant amount of money was ever made from selling Java applets. I can't remember the last time I saw one in the wild.
I'm pretty sure it's safe to say that Java applets on bare metal never took off. As has been pointed out in another response, "running Java applets without an OS or browser" was not exactly the intent of the OP's words in any instance.
The ones that never had any issue with either Sun or Oracle, because they always played by the license rules.
The conversation was about applets, running in a web browser, and how a browser AND the the JVM's available at Java's release, did or didn't require an operating system to run.
Embedded Java is not "applets". Nobody is denying that there is billions of devices running client side Java code.
https://www.v3.co.uk/v3-uk/news/2443810/oracle-signals-the-e...
Not moving goal post at all "JVM certainly needed an operating system to run".
JavaOS wasn't released until later (1996). And Wikipedia classifies it as an "operating system with a Java virtual machine as a fundamental component". The clue is in the name.
Circa 1997 I put a JRE on a brandable installer CD for a client that used JNI to call Win32 API to write Windows registry entries, make shortcuts and a desktop shortcut basically as an "InstallAnywhere" before it existed.
A couple of years later, I wrote a Java to MIPS direct compiler for a compiler course... in both C++90 and Java 1.3.
I've been in presentations showing all kinds of things being rewritten in Java just because apparently that was something that needed to be done. I particularly remembers seeing a NIS (YP) server and and NFS server in Java. When I asked why they did that, and particularly why they didn't go for NIS+ (which was many years old at the time) or event LDAP, they had no answer.
That's a pity because both Adobe Flash as well as Java Applets were interesting pieces of software for certain applications. However, due to their availablity they were abused anywhere. I remember some 90s DHTML sites having one Java applet per navigation bar button just because the effect was looking nicely. This was the same kind of bloat we experience with huge JavaScript libraries today. Probably the browser plugins were even easier to control (i.e. disable as a user) as an ubiquitous JavaScript is :-/
OracleJDK is 99% OpenJDK since 8 or 7. OracleJDK comes with some minor performance improvements, used to contain WebStart (removed in 11), Rhino and MissionControl (now GPL2 included in OpenJDK), some build tricks. Not sure what are differences between OracleJDK11 and OpenJDK11, but pretty sure it's really minor and 99.9% of developers won't need them. Oracle actually wants us to use OpenJDK. Remember that OpenJDK has been "forked" a few times already, by Azul, more recently Amazon and RedHat.
Has anyone recently looked into what it takes to distribute a closed, compiled Java app/appliance?
Not that I don't prefer foss - just trying to figure out if that is a diffferentiator?
Yes.
So many applications, including JetBrains ones, did not look that good on FOSS/OS X platforms with many rendering issues.
Hence why JetBrains started bundling their own version of OpenJDK for those not willing to install Oracle JDK.
- they speed up development, by effectively offloading legacy support to others.
- they increase immediate licensing revenues, since many businesses will pay up to stay on "Oracle-supported Java" for production deployments, at least for a while.
- they provide yet another incentive to leave behind all this "old world of installers" and embrace their underwhelming cloud offerings, where you don't have to worry about any license headache (and you can be milked more effectively).
From their point of view, what is there not to like?
Not really, no. They maintain Java 8 until 2025 and Java 11 until 2026 [1]. If you pay enough they will maintain it literally forever.
[1] https://www.oracle.com/technetwork/java/javase/eol-135779.ht...
But what I meant is that now they can drop support for any non-LTS Java release immediately, and limit LTS support to shorter periods if they want, because when you call them crying that you need a fix, they can simply point to someone else.
On a different note my personal experience with Premier Support could best be described as war of attrition. If we won that and got lucky after waiting a few months we got "it's fixed in the next major release". That is the best case. That was with Oracle database, not Java. In general the process is so annoying we won't report a bug unless we absolutely have to. I assume that was the goal behind the design of the process.
I don’t expect higher kinded types any time soon, though.
[1]: http://openjdk.java.net/jeps/325 [2]: http://openjdk.java.net/jeps/305 [3]: http://openjdk.java.net/jeps/309
Personally I rather not be in the bleeding edge and not having to deal with interop issues, or missing tooling.
Also in 2018 interop issues or missing tooling problems are long gone.
Only Scala shops can make effective use of them, and I am yet to do a project where Scala libraries were even considered.
Also, Scala compiler slowness is virtually not a problem any more since introduction of Zinc 1.0. During development, I get repeatedly compile times around 2-5 seconds on Scala 2.11, and recent Scala 2.12.x / 2.13.x showed to be typically 30%-100% faster than 2.11.x.
print(fetch("https://winterbe.com"))
is still this behemoth:
var request = HttpRequest.newBuilder() .uri(URI.create("https://winterbe.com")) .GET() .build(); var client = HttpClient.newHttpClient(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.body()); !?
One can argue about taste, but how can anyone defend such uuuuuuuuurgh?
print and fetch methods and both of those would be equivalent.
The verbosity in that code is less of the typical (and deserved) Java criticism of over-architected pattern cancer. Instead, almost all of the verbosity there is due to a refusal of the language to assume common defaults.
Whether assuming common defaults or forcing people to think about that stuff is good or bad is debatable. But it's certainly far from deserving of the "uuuuuuuuurgh" of a lot of (mostly older) Java I've had to wade through.
You should never try to learn 3D graphics programming if that basic stuff is already "uuuuuuuuurgh" for you.
Why would you need a Builder method on a static object to create a request object? Oh well, let me rephrase that: First you instantiate a Builder object that you need to call the create method on to get a request. Makes no sense to me.
What not make HttpRequest a concrete class and just instantiate it? If there's any good reason for that design please enlighten me.
A builder is a convenient way to wrap up those common settings so that they can be handed to other parts of the code that don't care about them/want to override specific parts and leave the rest in common.
Now, there are other ways to do that (instantiating a concrete class with common settings and mutable fields for customizations in a function, and then passing references to that function to everything that wants the common-config-defaulted output object). The choice between that kind of strategy (or an instantiate-and-freeze-early and pass your mutators in, or a refactor-all-your-code-to-not-mutate strategy etc...) and a builder pattern is a subjective and debatable one. But the approach taken here is certainly defensible.
So you can get a "reference" to the same data where one reference gives you the data immutably while the other one lets you change it. Sounds like a recipe for subtle bugs.
What do you mean, it's not like that at all. You only get back the same object (same reference) if it detects the object was immutable to begin with.
I only found a targz download link, didn't understand the contents of it - it looks like the inside of a macOS application package. The installation instructions refer to it being for .dmg file, which it doesn't seem to be.
Edit: Apparently I won't! This isn't ideal.
Thought they don't (yet) have openjdk11.
There's also some problems with making (at least) the openjdk8 build appear in the usual places, see https://github.com/AdoptOpenJDK/homebrew-openjdk/issues/9 for how to do it manually.
sudo mv jdk-11.jdk /Library/Java/JavaVirtualMachines1. tar zxf openjdk-11+28_osx-x64_bin.tar.gz
2. sudo mv jdk-11.jdk/ /Library/Java/JavaVirtualMachines/
3. Done!
I believe it also has trouble with reflection involving class names that aren't effectively constant at compile-time. So with that and the other limitations, there's a whole lot you can't do. Hopefully they can resolve that.
Can you give an example?
Those are better served by a full JVM, optionally boiled down with jlink or with AOT compilation for faster startup, and the JEP that was mentioned upthread.
In .NET Native and Lisp for example, you need to list code that should be kept around and not removed by the linker.
It is not an easy problem to sort out in some kind of automatic way.
* Run jlink manually (or scripted) to create the bundled runtime.
* Create launcher executables with packr[1].
* Create the installer using whatever tools people normally use for native applications. NSIS[2] and WiX[3] are widely used. (I haven't gotten to this step yet myself.)
[1] https://github.com/libgdx/packr
The rest of your comment is relatively consistent with some trends that I've seen in the development tools communities. I think it is also why it is so difficult to make money in that space.
There are hundreds of well tuned data structures, serialization libraries, and infrastructure services with long open source histories.
Kotlin can target JDK 6 and can integrate with old stacks
and Java 10 has much better type inference too.
How are you planning to move from 5 to 8/11? Our migration from 5/6 to 8 was really painful.
That and Android support as well.
I don't think that they'll remove XML support as other parts like XML properties and Swing XML serialization need it. Although in this new world they could simply remove that as well.
/methinks probably not. The money is in hosted licenses.
https://confluence.atlassian.com/bitbucketserver/supported-p...
Wow, those issues are from 2009.
They're hugely clunky. Also, Java based applets that used to run on browsers were awful.
I'd love to know if this is something to do with Java itself or the way these apps are developed. I understand they're not using OS's native GUI APIs.
At the end of the day, writing editors that perform well is a hard problem. Writing an editor that performs well on small files is an easy problem. People often confuse making the easy problem easier with having solved a general problem.
I do know what you mean though. Even "fast" Java applications have this vaguely clunky feel to them. I think this is the overhead of starting the JVM, or possibly GC. You see something similar with CPython desktop applications.
Why don’t we see this in say, .NET GUI apps like Paint.net? C# has all the same baggage as a Java runtime, but somehow just works without tuning a crapload of GC settings.
Even Electron apps seem hugely more responsive and useful than anything I’ve touched built with Java GUI frameworks (and I’ve touched a lot over the last 20 years).
I think that’s just Stockholm syndrome from the Java dev crowd. They still insist it’s perfectly rational for a 5-concurrent-user web app server to require a 500 MB .war with 40K files and 8 GB of runtime heap.
With SWT, the upside is that you get native widgets that look and work like they're supposed to on the platform, but on the other hand, if the same widget can appear with different sizes, looks and behaviours it's difficult to customize it, align it nicely and ensure the whole design behaves coherently.
With Swing, the other terrible Java GUI library, you get the same look and feel everywhere, but that look and feel is wrong on every platform. As well as slow, ugly and (still!) full of bugs.
Here's a fun Swing bug I noticed yesterday in IntelliJ:
1) Put IntelliJ somewhere in the middle of the window stack, i.e. with some windows under it and some above it.
2) Switch to a different virtual desktop. (Tested in Xfce on Debian.)
3) Switch back to the desktop with IntelliJ on it.
You will find (or I did, at least) that IntelliJ has moved
a) to the bottom of the stack, if using Jetbrains' bundled JRE;
b) to the top of the stack, if using Debian's JRE.
Some Java developers like to claim that it's just everyone using it wrong, but Swing is stuffed with these focus-related bugs. I've seen them in every Swing application now and then, for decades. (It also likes to create windows at the wrong position only to move them to the right position, and draw things initially with slightly wrong layout and then redraw them with the right layout. You can observe this as well in IntelliJ when it starts up.)
Romain Guy's team recently released Filament, https://github.com/google/filament
Back in the Sun days, Romain had a blog about writing nice looking Java UIs, which eventually lead to the "Filthy Rich Clients" book publication.
Swing[1] (especially in it's default Metal look and feel) isn't the prettiest, but it is skinnable. It's used because it's platform independent (because its predecessor wasn't), and supports more than Windows, Mac, and Linux (think things like Solaris, HPUX, IRIX, etc).
[0] https://duckduckgo.com/?q=javafx&t=ffab&iar=images&iax=image...
* Switching to a different window with alt-tab will have moved keyboard focus to the menu bar when you switch back.
* Holding down the mouse button, pointing at menus to open them and releasing to activate an item – the way people did it in ancient times and which has been supported everywhere forever – does not work.
* To avoid submenus disappearing as you try to move the cursor towards them, GUI toolkits use either a small delay or something more clever to keep the submenu for a bit while you try to reach it. Except for Swing and JavaFX, which do neither, leading to a frustrating user experience. Interestingly, they have documented the correct behaviour in the JavaFX wiki[1], but it's apparently not implemented. (They had similar design documentation on the Swing wiki, which I can't find now, which was also never implemented.)
(The Swing menu bar is broken in many similar ways, but in case someone is wondering why it works in IntelliJ, they implemented[2] the expected behaviour themselves.)
[1] https://wiki.openjdk.java.net/display/OpenJFX/Menu+User+Expe...
[2] https://github.com/JetBrains/intellij-community/blob/master/...
https://jaxenter.com/20-javafx-real-world-applications-12365...
Some of those applications are modern, nice looking and fast.
But it is also the most popular, even among the free IDEs. Apparently the community's UI preferences are different from yours and mine?
In any case, while there does appear to be a small latency penalty, there really is no rule that a Java based GUI has to be ugly. I find both the IntelliJ and Netbeans IDEs to be pretty nice.
https://joshondesign.com/c/writings
Don't use library components like JGoodies, http://www.jgoodies.com/
Also many just write everything on the UI thread, thus making the application unresponsive.
Swing can be used to make nice looking applications, even if they aren't exactly 1:1 to native ones, but that requires good UI/UX programming skills, and yes the defaults do make it a bit harder to achieve it.
Having said this, JavaFX is much easier to work with for doing graphical customization, as it is quite similar to QML and WPF in spirit.
Just try the demo. It's amazing.
I think a lot of developers skipped/will skip Java 9 and 10 (Java 9 is already unsupported and effectively history), except for testing their builds and preparing for the Java 8 to 11 migration.
So they actually just went from 9 to 11, going by your logic.