Noteworthy, the oracle JDK license has apparently changed so you can't legally use their distribution for much of anything except for the development of inhouse java applications? So I guess you can't even use it just for its JRE to run, say, eclipse for PHP development, or to host a servlet web server? Anyways looks like the OpenJDK is now on feature parity and is GPL licensed. https://blog.joda.org/2018/08/java-is-still-available-at-zer...
There are a lot of enterprise users on Java 7 at the moment and they are not going to move to Java 11. I just moved a company to Java 8 and it was a big thing. Not sure which one is the next "LTS" release, that will be the next target for our migrations. The biggest "feature" is G1GC in "new" Java for a lot of users based on my experience.
One huge difference for enterprise users is release cadence.
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.
The slower release cadence of openjdk makes it a good fit for enterprise users as they tend to also have a slower release cadence. Is anyone even using Java 9 or later?
Azul's Zulu fork is compatible with Oracle's but with a better concurrent, parallel, pauseless GC. I can't see a reason not to use theirs because their support is excellent (have tried) and any enterprise problems can be delegated to them with a support contract. IOW it works for indie devs and enterprise alike. It sounds like I'm pitching them, because they're a compelling alternative.
Good to know. I am amazed by the history of openjdk and how it's slowly become the mainline of what people use. Does OpenJDK come with all that mission control (I think that might have a new name?) stuff or is that the primary reason people buy Java from Oracle at this point?
I don’t follow Java too closely these days as I haven’t worked in it in years. Pretty wild that Applets are now removed. I still remember the wonder of being able to build a compiled application that could run from command line or in the browser. RIP Applets, long live Java :)
With the removal of applets I feel like the last of the Java that helped build is gone. The process of working on the development of, and then watching the weaponizing of Java is one of the more memorable chapters in my career.
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?"
I was working for Sun during those days. They used to have this vision that everything would be written in Java. They threw everything at that wall, and ran with the ones that stuck.
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.
Java wasn't really good at being a server early on, it was very much 'client side.' It would have been an interesting exercise for me to implement NIS+ in it :-)
I think the point is that they weren't tied to a particular operating system. If someone wrote an application as an applet, they could sell it to customers who had Windows, or who had Solaris. They could, to coin a phrase, write once, run anywhere.
As long as "anywhere" meant Windows and Solaris. There were a lot more commercial operating systems in those days (eg. Tru64, SCO, HP-UX, OpenVMS, AIX, Linux, QNX, Classic MacOS etc), many or most of which didn't get a JVM/JRE until much later.
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.
JavaOS was DOA and end-of-lifed in 1999. Superseded by J2ME, which didn't support applets, as least not without an application-specific loader, or within a web browser AFAIK.
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.
You are missing the embedded and factory automation market, blu ray players, cable TV boxes, where plenty of JVM vendors are happily selling bare metal JVMs.
The ones that never had any issue with either Sun or Oracle, because they always played by the license rules.
I'm not missing anything. You can keep moving the goal posts all you want.
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.
It certainly did at the time that Java was released, which was the context I was commenting in (ie. "needed", not "needs") - the original HotJava browser (1994) or Netscape 2.x (1995) with builtin Java applet support, before it was later moved to a plugin.
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.
I remember AWT&Swing from the 1.0-1.2 days. heck, I got an A for some project at DeAnza that was an applet for something, maybe a chess board.
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.
Ah yes, I believe I have a Knight’s tour solver written in Swing. Not sure I ever fully mastered GridBagLayout! Now to convert that to Autolayout and Swift...
WebAssembly can't do anything JavaScript can't do. Applets on the other hand have full access to computer and hardware. The only thing WebAssembly does better is performance and even that is questionable.
The java applet's possibility to gently jump over the sandbox fence was probably the most terrifying feature of java which probably put Java on an equal footing as Adobe Flash, i.e. a potentially dangerous browser extension which requires regular updates (Flash and Java updaters were omnipresent in the Microsoft Windows tray in these days, isn't it?) and which the average user does not understand.
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 :-/
Applets were heavily sandboxed. I think the only substantial things they could do that JavaScript can't were start threads and open TCP sockets (although still only to their origin host?). WebAssembly seems like a very good comparison.
What is Oracle's rationale for the new licensing terms ?
It seems counterproductive to me as it will push developers to use OpenJDK ,which is pretty good on its own and "unlink" Oracle from Java in our minds. To be honest, I have climbed through hoops to install Oracle's JDK on my Ubuntu just out of habit. Now I wont do that because any application I develop on this JDK cant be put into production.
> It seems counterproductive to me as it will push developers to use OpenJDK
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.
> What is Oracle's rationale for the new licensing terms ?
- 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?
You might not be familiar with the Oracle policies - which is fair enough, not everyone has worked there ;) Once Premier support is over, the only thing you get for your money is “we will not delete related KM, and we will still answer the phone and tell you you’re screwed”. Even Extended Support is a bit of a joke, you’ll just get “don’t sue me” fixes.
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.
Be that as it may Premier Support for Java 11 still lasts until September 2023. So yes, Premier Support is down to five from eight years but I don't see how this requires a different licensing model.
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.
As far as I understand, Red Hat plans to take the lead on supporting a LTS version of OpenJDK 8 after Oracle steps down, with the intent to eventually do the same with 11. Various organizations such as AdoptOpenJDK will then be making releases off that.
Idea/PyCharm/etc say they work better with Oracle JDK but I haven't noticed any difference so there seems to be little reason to install Oracle JDK ever. Perhaps it has some features some devs use in some special cases but in general, the Open JDK seems working equally well.
Before Oracle synchronized all the code between the proprietary version and OpenJDK, stuff like the graphics engine and font rendering wasn't the same.
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.
I ran into this just the other day, Autopsy, a digital forensics application ( https://www.sleuthkit.org/autopsy/ ), requires Oracle JRE and wouldn't even start with OpenJDK when I tried it.
Is the openjdk all lgpl/gpl with link exception? Because if not that leaves five options: distribute to end users without a jre/jdk, bundle under gpl, bundle with other jvm/jre (oracle, other commercial), bundle with graal as native code - but I seem to recall that also has a split license?
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?
This is also a gem: "Because list is already immutable there's no practical need to actually create a copy of the list-instance, therefore list and copy are the same instance. However if you copy a mutable list, copy is indeed a new instance so it's garanteed there's no side-effects when mutating the original list"
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.
Looks like Java is slowly but surely catching up to Scala in terms of API, syntactic sugar etc. I wonder if some people disliking Scala compiler slowness would consider the switch back to Java.
Far from it. When Java gets pattern matching, Scala will have moved to version 3.0 with trait parameters, union and intersection types, implicit functions, type lambdas, cleaner macros and many more.
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.
The whole point of Scala are its advanced features like implicits, higher kinds and macros, and not just syntactic sugar like in Kotlin. Therefore you won't appreciate Scala by just shortly playing with it.
Also in 2018 interop issues or missing tooling problems are long gone.
The first step towards pattern matching will be previewed in JDK 12[1], as a Kotlin-like switch statement, to form the basis of pattern matching[2] together with changes already in JDK 11[3]. I think it will be more like 15 months than 15 years.
I don’t expect higher kinded types any time soon, though.
If it doesn't have what 305 calls "deconstruction patterns" and "nested patterns", it's not really pattern matching. I'll be impressed if those make it in within 15 months.
I saw that on reddit and downvoted it, title says it shows new Java 11 things, so I expected dynamic class-file constants example and explanation, ZGC tuning and showcase, not "var" from Java 10 and HTTP client from Java 9... Your post describes some minor syntax changes and a few new base methods, doesn't cover release notes.
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.
This is really a really weird overdesigned API. Maybe I don't understand the purpose of it but it seems like an excessive use of design patterns.
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.
Many use cases want to make a whole lot of pretty similar (URI, creds, method) requests that vary only in a single way ( e.g. a POST parameter) or don't vary at all (e.g. polling).
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.
Much better than HttpUrlConnection though.
As an aside, the http client API seems really well thought out, supporting all sorts of common use cases for http. Once you convert the examples to some non trivial request response stuff, the new API shines. I think the job of pleasent APIs for starters is left to external libraries here.
Almost nobody uses the standard lib for http in practice. Just use Unirest/OkHttp/SpringBoot then it’s trivial. SpringBoot is the best framework that I have worked with regardless of language. It covers most use case out of the box and everything is still completely configurable.
Just installed OpenJDK 11 on my macOS machine. Remarkably unfussy install process. Missed the times when installing will involve accepting license, multiple clicks on installer GUI and helpful offers for browser toolbars used to be present :-)
Feeling like a bit of a noob, but how did you install it?
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.
You might be able to make an installer package from it with pkgutil. You can use the Contents/Home directory from the tarball as your JAVA_HOME; no need to do an installation.
One setback with this release is that the javapackager tool, which made native installers that bundled the Java runtime, was removed (presumably because it depended on JavaFX) and there is no replacement for it. One is being proposed at http://openjdk.java.net/jeps/343 but I'm not sure when that is expected to be done.
* 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.)
I was positively surprised when I noticed how easy it is to create a windows installer using nsis from osx. makensis is cross platform and can be integrated easily in the build toolchain
If your application doesn't do bytecode generation or instrumentation at runtime then the graal native image compiler might do the job too or even better.
It looks like that makes a native executable, not a package meant for end users. The javapackager tool actually built .exe, .app, .deb, and other OS-specific packages.
> If your application doesn't do bytecode generation or instrumentation at runtime
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.
I don't think they intend to solve that because the cases that it can't handle are basically application servers, plugin-based applications and the like. They violate the closed world assumption which graal's native image builder relies on.
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.
Sure, just about any project that has the concept of plugins. At runtime the code looks for plugin instances by searching for, e.g., META-INF/services/<interface_name> on the classpath. Inside that file (or files) you have implementation class names, which are collected and instantiated.
I think that a lot of people misunderstand Oracle. As a former Product Manager there, I can safely say that Oracle only cares about development tools to the extent that it furthers their business interests (based on Executive Meetings I attended). And since Microsoft provides a popular and full-featured development environment, Oracle is forced to provide an alternative or they might get shut out of all development projects by Microsoft (in fact, that is Microsoft strategy as learned by some of our "spies". Or did you think that Microsoft supports development tools because they want to be in that business?). In addition, based on meetings with executives from several Fortune 50 hardware and software vendors, it is clear that transferring as many costs as possible to open source groups saves money. And, as another benefit, any bugs or shortcomings can't be blamed on the corporation who sold them their hardware or software - again saving costs and preventing many lawsuits (which account for many, many millions paid quietly.) So be careful about projecting the "myth" of open source on to the companies involved with open source. The interests they claim are not their real interests.
(And since some HR readers routinely ask me "what proof" and then work to dismiss anything I write - let me say that I have no proof. Insisting on proof for all data-points leads to poor judgment. It makes more sense to collect unproven data-points and assemble those along with known data to craft good judgment. Honestly I feel sorry for those whose judgment is blinded by their insistence on legal-level proof. They are mentally disabled.)
IMO, your comment would have carried more weight without those last two sentences. Those seem a bit unnecessarily insulting?
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.
Of course Microsoft wants to provide tools. Developers are what made Windows popular. They want to have cross platform tools because their next growth opportunity is Azure.
I'm more qualified to comment on .NET but the main difference here is that Core was basically starting over on .NET from zero to go cross-platform and then immediately scrambling to get everybody's favorite feature plugged back in. Java seems to be trying to chip pieces off of the standard library by either modularizing or like this, just dropping it from the standard offering.
Ouch. Java 7 and 8 introduced a bunch of very pleasant syntactical fixes that greatly improved my pleasure in coding Java. What's holding you back on 6?
Bingo! Ginormous amount of technical debt that nobody is dealing with and probably not even seeing ... Plus a culture of "if it works don't touch it" ... I am dying inside ...
On the bright side, Java 5 is a huge improvement over earlier versions – at least you have generics, and you don't have to manually create iterator objects every time you write a loop! (Java ME was stuck on 1.3 until its death.)
Well, removing SOAP is a little too radical. Indeed nobody likes SOAP and it is mostly used by EE guys but there still probably are many non-enterprise public SOAP APIs. This makes me wonder if they are going to remove XML support in the next version :-) Also, JavaFX is amazing, I actually wish it would get more popular, it feels like the best GUI framework I've seen so far.
You can still use SOAP, just add a JAR or two, as it should be. If you were using Java EE you were always using the Java EE classes and no the Java SE classes anyway. I think it was mostly removed because Java EE required redefining some Java SE classes which is a bit of a pain with the new module system so they simply kicked it out of Java SE.
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.
JavaFX getting removed from the JRE/JDK is probably the best thing for it, I think Gluon and other contributors will do a better job acting as stewards of it than Oracle.
Eclipse actually uses SWT, the least terrible Java UI framework! But making a cross-platform UI framework is just fundamentally difficult, it seems, and is always a compromise.
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.)
Yes it is using it wrong, because while some issues are indeed Swing interop bugs with the host GUI, others are lack of skills by not reading canonical books like "Filthy Rich Clients", written by Chet Haase and Romain Guy, the guys that drove most of Android rendering stack.
There's nothing technical that prevents beautiful, fast Java apps. I thought that Java FX looked pretty in the screenshots[0]. It just so happens that Java is mostly targeted towards people that value functionality over GUI design or performance.
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).
Java FX does look pretty, but the menu bar implementation is as broken as the one in Swing:
* 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.)
I think you're picking out examples of poor performing Java applications. IntelliJ's IDEs are also written in Java and they are widely acclaimed.
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.
> 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).
This was my reason for asking the original question. I always feel that Java apps are just clunky. I agree with your observation but I’m also reading that IntelliJ and other well designed Java apps are better.
> I’m also reading that IntelliJ and other well designed Java apps are better.
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.
Its a really good question, tbh. I've used Eclipse and other Java IDEs for years and I consistently feel like Eclipse has had the worst UI design of them all.
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.
I guess it's really a matter of taste. I prefer Eclipse over IntelliJ for example (in terms of GUI). But I also prefer Eclipse over the current MS Office GUIs for example.
While I don't hate IntelliJ, I do get the impression it is mainly seen as beautiful in comparison to Eclipse/NetBeans.
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.
Because developers don't bother to read books like "Filthy Rich Clients" and "Swing Hacks: Tips and Tools for Killer GUIs", or aren't even aware they exist.
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.
Java 9 and 10 were released. Java has moved to a time-based release schedule where they release what is ready for each release rather than having things block releases forever. Every third release is a long-term-support release. It's similar to Ubuntu where they release every 6 months, but then there's an LTS release that many people will wait for.
So yeah, in essence Java went from 8 to 11 if you look at it as a sequence of major releases such as 5, 6, 7, 8, and now 11.
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.
Java 9 was a major release. Project jigsaw (introducing modules) was a major change and blocker. Once they got that out of the way they changed the release cycle, which is why java 10 was released soon after java 9.
So they actually just went from 9 to 11, going by your logic.
It was a major release in terms of features and platform architecture, but it was not in terms of adoption. Project jigsaw at this moment is a blocker for upgrade from Java 8 - majority of developers will move from it only when it sees the ecosystem ready for that step. Now it's not - due to plenty of major libraries and tools that didn't even start the migration or still have "alpha" in their version numbers.
Also Java 9 and 10 aren't LTS-releases, which in turn causes the ecosystem to ignore them largely, because they'll be buried and forgotten by the time they're ready for Java 11.
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.
I imagine the main target customer are the large enterprises and the like that want full support contracts for everything.
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....
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.
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.
http://www.javaworld.com/jw-07-1997/jw-07-javamac.html
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.
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.
- 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.
https://github.com/JetBrains/jdk8u
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.
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.
https://winterbe.com/posts/2018/09/24/java-11-tutorial/
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.
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.
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.
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
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?
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.
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.
You should never try to learn 3D graphics programming if that basic stuff is already "uuuuuuuuurgh" for you.
print and fetch methods and both of those would be equivalent.
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.
1. tar zxf openjdk-11+28_osx-x64_bin.tar.gz
2. sudo mv jdk-11.jdk/ /Library/Java/JavaVirtualMachines/
3. Done!
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.
* 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
[2] http://nsis.sourceforge.net/
[3] http://wixtoolset.org/
https://www.graalvm.org/docs/examples/native-list-dir/
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.
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.
Can you give an example?
[1] https://itnext.io/java-is-still-free-c02aef8c9e04.
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.
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.
That and Android support as well.
/methinks probably not. The money is in hosted licenses.
https://confluence.atlassian.com/bitbucketserver/supported-p...
https://jira.atlassian.com/browse/CONFSERVER-16431
https://jira.atlassian.com/browse/JRASERVER-41589
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.
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...
[1] https://en.wikipedia.org/wiki/Swing_(Java)
* 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/...
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.
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.
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.
http://filthyrichclients.org/
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.
[1] https://www.bitwig.com/en/bitwig-studio.html
https://jaxenter.com/20-javafx-real-world-applications-12365...
Some of those applications are modern, nice looking and fast.
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.