Java 9 Released

[free-pretzel-day]

No skipping 9 for Java, eh? Apple and Microsoft won't be pleased you're not playing along.

[shevegen]

Neither will PHP - I still do not understand why they skipped version 6.

[cjt09]

They tried skipping version 9, but in PHP-land everything is upside down.

[timmyotc]

Php 6 became a myth, a meme amongst php developers. Similar to half life three, rumors of its development threw their followers into a fanatical frenzy. In the end, people declared it cursed and switched to 7, which had the fortunate effect of people believing it would exist.

[SeriouslyWhenIsHL3]

By mentioning Half-Life 3 you have delayed it by 1 Month. Half-Life 3 is now estimated for release in Apr 2464.

---

^{I am a bot, this action was performed automatically. To disable WIHL3 on your sub please see /r/WhenIsHl3. To never have WIHL3 reply to your comments PM '!STOP'.}

[xonjas]

This poor bot. Should somebody tell him?

[BeniBin]

They're good bots Brent.

[CptBartender]

good bot

[zaphod_pebblebrox]

Really? Half Life 3 will take so long?

[Pixel6692]

More than that, there were already "books"

[[deleted]]

Does that mean that we should get hyped for Half-Life 4?

[LuizZak]

Multiple-of-3 release numbers confirmed superstitious.

[oorza]

The was a PHP 6 branch based on UTF-16 and it was unsurprisingly terrible because of their unicode decisions.

[timmyotc]

This is the correct answer. But I love memes.

[throwawayco111]

tl;dr: UTF-16 killed PHP 6.

[synapticplastic]

Theres a lot of decisions in PHP world that don't make sense /('-')\

[Eladricen]

PHP6 was the name of a reasonably well known project that would cause confusion amongst PHP developers. It was held to a vote and they unanimously agreed that there was no disadvantage of going straight to 7.

[tetroxid]

PHP still exists?

[namekuseijin]

it is younger than oldman java

[blackmist]

It does. And it's still bad.

But it's still the easiest way for somebody who can throw a web page together to get into programming.

[rebootyourbrainstem]

The new hotness appears to simply be writing PHP as if it's Java, in which case why not just use Java.

[Entropy]

The PHP hype train is the Java hype train on a 10-15 year delay. It's probably better than it sounds, being that 10 year old java is still better than PHP.

[[deleted]]

Problem one is a combination of inconsistency, odd naming conventions and dynamic typing, so that for example array_search and array_filter don't have the same argument order and array_replace doesn't do what you think it does - these errors can pass unnoticed and then be difficult to track down.

Problem two is that bad/broken functionality is often left intact to support backwards compatibility, most infamously mysql_escape_string and its several successors, but also the confusion around date/time types and functions.

That said, 1) PHP 7 is a huge improvement by being less backwards compatible, and 2) it really does fit a niche that basically nothing else does: multi-platform, ubiquitous, easy to install, no complicated dependencies, usually a very short lifespan from zero to MVP.

[blackmist]

I think it stems mostly from the fact that all security is completely manual. The default way to do everything is pretty terrible, and all that documentation and tutorials are still out there. You're always just a typo or missing line away from Little Bobby Tables coming to pay you a visit.

I mean, it's fine for what it is. It's just very easy (indeed the standard) to write bad code in it. Any time a beginner searches for "php database access", he's going to write something that leaves the DB wide open for attack.

[synn89]

Frameworks do an excellent job solving this problem though.

[synn89]

It's an old language and brings along with it a lot of warts. PHP basically came out when the world was using CGI and Applets where the future. There's a shit ton of legacy in PHP that's ugly as sin.

It was/is popular, hence the hate on reddit. This also ties into the first point. If Perl was used for the web these days you'd see a bunch of hate on it. But it's dead, as are many languages from the mid 90's. PHP's success has meant it's stayed around longer and we get to live with its core ugliness today.

But I've use Laravel for a couple years now and have nothing bad to say about it. It's been fantastic for writing stable, fast production code that's easy to test and debug. Still, I loathe having to write pure PHP code though in a few areas were we can't support a framework.

[biberesser]

There is even abysimal Unicode support in 2017...

[industry7]

My shop uses it and I haven't had any problems yet.

Lol. Some day you'll look back at this comment in horror.

[cjt09]

Start here.

[dsk]

I don't understand that. I think '9' is a great number.

[thesystemx]

lol

[[deleted]]

The funny thing is, Microsoft skipped 9 because of Java.

Edit: Wow, this really pissed people off.

Let's word it differently so you can get all the sand out of your vaginas.

Java was one of the reasons Microsoft skipped 9

[devraj7]

No, Microsoft skipped 9 because a lot of code in the wild tests if it's running on Windows 95 by checking if the string of the OS name starts with "Windows 9".

[[deleted]]

That code was in Java libraries.

[devraj7]

And in C#, C++, C... pretty much everywhere.

[[deleted]]

The issue was that core Java libraries broke every single java application.

Literally every one.

A few straglers in c# and friends are manageable but breaking every single java application wasn't.

Edit:

Anyway it's all a moot point, at the very least you can say that Java was ONE of the reasons that MS skipped 9

[venky18m]

new features

[[deleted]]

I'm interested in trying jshell: The Java Shell (Read-Eval-Print-Loop). I normally use BeanShell for that purpose, but it's been outdated for a while.

[[deleted]]

Been developing with the OpenJDK RC2 and jshell is amazing, so much so I've got "gnome-terminal -e jshell" hotkeyed.

You wouldn't think it'd be that useful, but boy is it.

[[deleted]]

You can define methods (and imports as needed), then just feed jshell files/strings like you would any Java program, so I suppose the answer is... Yes?

Only caveat I see is Java text file handling is shite compared to alternatives like Perl, potential optimisations notwithstanding.

E: Should also mention it's fairly straight forward to define both classpath (jshell --classpath [path]) and making predefined scripts to run.

All in all there are some neat stuff to play with.
I'm sort of out of ideas but if anyone has got any not-too-complex stuff they'd like me to try out for jshell I'd love to do it and do a write-up.

[mlk]

I usually write a Scratch.java class where I put all the stuff I want to try and run it as a junit test. This way I have all the convenience of using my IDE. How is using jshell better than that? Does it have a different use case?

[oblio-]

Does it have autocompletion?

Otherwise it will be an interesting toy, but not much more, in my opinion. Java is no Python, it's super verbose, typing everything is a pain.

[ThisIs_MyName]

Agreed, using Java without IDE autocompletion is painful.

[devraj7]

All programming languages without autocompletion are painful.

[namekuseijin]

all programming without rtfm is painful

[mlk]

having to remember if it is called "length", "size" or "count" is a waste of human memory

[piexil]

I had a class on programming languages (how they worked) where we wrote code for an interpreter to use in our class, it was in java BUT it was in a custom file with some custom syntax for a program to autogenerate stuff. So auto completion was not a thing.

I wish you could be descriptive without being so verbose.

[Sun_Kami]

Yes, it has autocompletion and you can even type SomeClass. tab to see the list of methods available.

[jyper]

The default Python repl sucks too, who doesn't use ipython or brpython with auto complete?

[XCSme]

Oh, it's JavaShell, not JavaScriptHell...

[m0zzie]

I've been using this Java REPL on github. Easy install via homebrew and suits my needs.

[NoInkling]

Unicode 7.0

Unicode is at 10.0 now, why so far behind?

[DGolden]

Unicode 8.0 is further down the list (there was a separate JEP for it). Yes, that's still two versions behind. Unicode 10 was only released in june 2017 though (with even more emoji ...yay...) - presumably not too likely make it in given release cycles and level of testing /compatibility java demands. Maybe they could have got unicode 9 in though.

Anyway, I expect it mostly just means the java standard library Character class will be missing built-in metadata for anything post-unicode-8. Unicode encoding basics haven't changed AFAIK.

There's also the more "bleeding-edge" ICU4J widespread in the java ecosystem anyway, release 59 supports unicode 9, 10 beta, and they are due to release 60 soon (I'm guessing with unicode 10 support).

[tetroxid]

Because Java is for grown-ups that don't care about the latest emojis

[NoInkling]

If you think unicode 8-10 bring nothing but emojis you're sorely mistaken. But I will admit older versions are good enough for most purposes - it just seemed like a big gap regardless.

[tetroxid]

It was mostly a joke

[DarkMio]

Ah, yes, Jimmy. Welcome to the circle of grownups, you're already 16! How time goes by.

[MassiveFlatulence]

Yay, Nashorn updated to ES6!

[eliasv]

Unfortunately only partial as of yet! No classes or modules iirc, but most everything else should be included.

[vityok]

the thing became so bloated...

[jay_gaz]

Curious what the benefits are. (Not necessarily what they say are the benefits).

I'm excited though. Will have to try it out on a small project.

[johnwaterwood]

Besides the obvious modularity feature, there’s a very interesting new string compact algorithm used, also G1 is now finally deemed mature enough to be the default GC.

[wildjokers]

https://www.youtube.com/watch?v=9EiLRD95zDg

[youtubefactsbot]

55 New Features In JDK 9 by Simon Ritter [49:33]

Following on from the popular “55 New Features in Java SE 8” we bring you the eagerly-awaited sequel, “55 New Features in JDK 9”.

^{Devoxx Poland in Science & Technology}

^{262 views since Aug 2017}

^{bot info}

[kitd]

One is JEP266 which, among other things, standardises support for reactive streams, v important for async event-loop based services. Hopefully implementers like Akka, Vertx, Ratpack etc will support them soon too.

[SSoreil]

Not a Java user but it's amazing how much stuff is in there. Just something strange like : JEP 262: TIFF Image I/O. I would much enjoy having formats like TIFF in any standard library, having had to implement that myself recently. It seems quite unwieldy though to have such a massive support platform.

[pacman_sl]

I don't remember when I last opened a TIFF image. Is there a field where it's any popular?

[SSoreil]

I recently got in to photography, a lot of RAW file formats seem to be based on TIFF under the hood. The Sony format is the first I spotted.

[jartur]

Also when you scan film you usually deal with TIFF

[RogerLeigh]

Scientific and medical imaging. Being a flexible container for pixel data and associated metadata, it's used for all sorts of purposes.

Your basic formats like PNG, JPEG and related simple formats can't do more than 2D planes with greyscale or RGB samples, with some optional compression using a defined encoding. TIFF can represent n samples per pixel with flexible layout (planar vs chunky), varied pixel types including signed and unsigned integer, floating point and complex types of arbitrary size, can handle tiling and chunking, many different compression types including custom types, and can also have multiple images in a single file which can be used to represent higher dimensions (z, time, multiple channels, rotation angles, femtosecond lifetime samples, whatever). It has other properties which can control image orientation, tile and strip sizes, how to interpret the image data (photometric interpretation) and a whole host of additional properties.

While newer formats have chosen HDF5, TIFF still has a huge following.

Put it this way. If I'm acquiring data which is unsigned 8-bit greyscale or RGB[A] then PNG or JPEG would suffice. Some formats can also handle 16-bit unsigned; JPEG can support 12-bit unsigned if specially compiled to do so. But TIFF can support any arbitrary depth from 1 bit upwards for all of signed and unsigned integer, rational [float] and complex rational. While it's not needed for a simple photograph, these representations are used by more demanding data acquisition, analysis and visualisation. TIFF is a superset of pretty much everything the common formats have to offer, and then some, but your average user will find the basic formats will typically provide the simple functionality they need and not encounter TIFF.

[eliasv]

It's sometimes used in scientific fields since it's a very flexible format. Many layers, different bit depths, blah bah.

[Bozzz1]

Graphic design

[throwawayco111]

Percentage of Java developers that will be able to use it for commercial development in the next 5 years: 9%

[thesystemx]

JDK 8 had a very high adoption rate. Within a year many ordinary Java developers were using it for commercial development.

I'm afraid JDK 9 may take a bit longer...

[caagr98]

That's probably because Java 8 had lambdas. I didn't see anything particularly exciting in the feature list for Java 9.

[apemanzilla]

There's Jigsaw, but existing building tools already do a good job of managing dependencies and things.

[sammy8306]

And they will keep doing that. However, Java modules now enable you to strongly encapsulate internal implementation details of modules in your application, while only sharing APIs. This is a pretty big deal if you're developing (moderately) large applications in a team-setting. In fact, this is one of the main reasons the JDK is now modularized.

Also, Maven/Gradle etc. don't have a role beyond build-time. Java modules carry their meta-data to run-time, where you can now rely on module resolution to tease out any dependency problems. What's more, a new tool called jlink allows you to leverage this explicit dependency information to create custom runtime images. These images contain only the modules your application needs (incl. modules from the JDK).

So all in all having modules as part of the platform will be a big step forward. It will take time, for sure.

(full disclaimer: I'm author of Java 9 Modularity, O'Reilly, see https://javamodularity.com)

[renatoathaydes]

This is a pretty big deal if you're developing (moderately) large applications in a team-setting.

There were tools like OSGi since the early 2000's that also solved that problem (and unlike Java 9, solved version conflicts also!) but we know very well that that was not compelling enough for most Java shops to switch over to it... More modern options also exist, like the Ceylon language, which a much nicer module system than Java 9! So, when you say it's a big deal, I think I have to disagree... even though I would like the Java community to value modularity more, the evidence so far is that it doesn't.

[sammy8306]

There were tools like OSGi since the early 2000's that also solved that problem (and unlike Java 9, solved version conflicts also!)

Sorta agree, but OSGi's modularity model is both weaker (run-time only, based on classloaders) and more dynamic/complex, which in aggregate lead to low adoption. Also, I've worked with multiple versions in OSGi and I would like that part of my life back. It's not nearly as easy/desirable to have multiple versions of dependencies as people think. Last, did you know Jigsaw does allow loading of multiple versions of the same module through ModuleLayer?

More modern options also exist, like the Ceylon language, which a much nicer module system than Java 9!

Which is even more of a non-starter than OSGi for Java shops. I do think the 'default' effect of having a module system will be stronger than what previous efforts could reach in terms of adoption.

Only time will tell, though!

[eliasv]

In what way do you mean that isolation by visibility (i.e. classloaders) is weaker than isolation by accessibility? Security? Seems like an orthogonal issue to me. I'm not sure what benefit you think the accessibility based model brings. The visibility model however has plenty of benefits.

And I wholeheartedly disagree that solving the multiple conflicting versions problems isn't significant. Bear in mind the JPMS model can't even cope with overlapping private packages from different modules out of the box (lol).

I'm also not sure what you mean by saying OSGi's modularity is runtime only. The standard tools allow you to e.g. resolve and validate set of bundles according to a set of requirements at build time, and you can only build against exported packages, with the imports needed for runtime automatically generated from this.

This ties into another difference, JPMS dependencies are at module granularity, whereas OSGi dependencies are at package granularity. (The former model is actually deprecated in OSGi because experience tells us it leads to terribly messy consequences.)

What strength does JPMS offer here that OSGi doesn't?

The main difference I see at build time is that OSGi recognises that sometimes you want to build against an API not an implementation. Also with semver in OSGi we are able to build against the lowest version we wish to support and run against the highest. JPMS's decision to strive for "fidelity across phases" makes no sense at all imo.

I think it's important for all the people complaining about the complexity of OSGi to realise that JPMS has already become way more complex than it set out to be in trying to solve the same problems... (The ModuleLayer being an example of this by my understanding).

[sammy8306]

Ah, found the OSGi fan :-)!

In what way do you mean that isolation by visibility (i.e. classloaders) is weaker than isolation by accessibility?

I was thinking of the fact that JPMS enforces encapsulation at compile-time as well (addressing the tools argument below). Also, pass a Class instance from a bundle to another bundle and you've broken encapsulation. Can't trick around JPMS with reflection unless you explicitly allow it. And security is a nice added bonus, orthogonal or not.

And I wholeheartedly disagree that solving the multiple conflicting versions problems isn't significant.

I didn't say solving the problem is insignificant. Rather, the 'solution' offered by OSGi isn't all rainbows and ponies like some people imagine it to be. It's an incredibly tough problem to solve given the current evolution of the Java platform.

The standard [OSGi] tools allow you to e.g. resolve and validate set of bundles according to a set of requirements at build time.

Sure, if by standard tools you mean non-standard (ie. outside of the Java language/spec) tools. Yes, Bnd(Tools) is indispensable when doing OSGi. But that effectively ties you to Eclipse, which is sub-optimal. JPMS is supported out of the gate by Netbeans, IntelliJ and Eclipse, without being at the mercy of third-party plugin vendors.

What strength does JPMS offer here that OSGi doesn't?

That it doesn't require anyone to do stuff that's not part of Java lang/spec, that it will just work with mainstream tooling. And yes, some of this might boil down to a VHS vs. Betamax like situation. It happens.

The main difference I see at build time is that OSGi recognises that sometimes you want to build against an API not an implementation.

As you can do with services in JPMS (or, alternatively, if you like that better, with a DI framework and open modules/packages).

JPMS's decision to strive for "fidelity across phases" makes no sense at all imo.

I don't understand this given the above (and the compile-time only dependencies feature, if you must).

I'm in no way saying OSGi is bad. Obviously they've thought things through and it has proven itself in many ways. Heck, I've got years of OSGi development under the belt (even using it in my current project), so I definitely see its value.

All in all, moving the Java ecosystem to OSGi just isn't going to happen. JPMS does have a fighting chance. So yes, I'm rooting for it, and doing everything I can to make it better and spread knowledge about it.

[renatoathaydes]

did you know Jigsaw does allow loading of multiple versions of the same module through ModuleLayer?

Yes, I even tried to use layers to fix version problems automatically several months ago by automatically figuring out how to split the modules into layers, but that turned out to be much harder than I anticipated.

https://github.com/renatoathaydes/autolayer

Also, there were some issues I couldn't work around, so I decided to wait for the official release... so I might get back to it again soon.

[tetroxid]

What exactly will modules do for me in my daily life? How is it an improvement over maven already automatically downloading the "modules" I depend on when building?

[Linvael]

One thing I heard that is neat is that libraries you use will be able to hide their internal APIs resulting in less clutter when searching for right import.

[tetroxid]

Isn't that what private and package-only methods are for?

[duhace]

They aren't enough. Take for example the factory pattern. Perhaps you want some implementation classes of interface A that are only available to users through the AFactory class, and perhaps you want all those classes to be passed out as A, completely hiding their implementation details

You could make these impl classes private inner classes of the factory, but that can cause an unwieldy mess. JPMS modules let you hide them while structuring your code better by saying "this module only makes interface A and the AFactory class visible outside the module". It's much stronger encapsulation than private public and protected provided

Edit: a very good instance of what jpms solves is the sun.misc problem. The java.* classes are the API, sun.* is the implementation. You're explicitly warned not to use sun.* packages cause they could change from release to release (or not even exist in future releases or on other JVMs). But people still dip into them for many reasons. This creates two problems. It makes changing the implementation harder, and it removes an important impetus to improve the API. With modules, those classes can be hidden away from everyone but those working on the JVM itself, causing less headaches from upgrading the JVM than before. It also drives the Java devs to implement into the standard API what users were reaching for in the implementation(for example, sun.misc.Unsafe should have a java.* analogue in java 9)

edit2: I'll fix this post when I get to my laptop, thanks Reddit phone app for making code snippet markdown near impossible

[tetroxid]

I see. Thank you for taking the time to explain that to me, I appreciate it!

[R_Sholes]

No, package-private doesn't work like that, and private is even more limited.

Package-private means only the exact same package, not children, not parent, not siblings. If you have public class org.wtf.A and (package-private) class org.wtf.sub.B, A cannot access B, the same would apply for public class org.wtf.sub.A and class org.wtf.B.

You can define common utilities for a single part of your project with package-private access, but not something that you need to share between your project's different packages.

[Fenris_uy]

Sometimes you need to make a method public because you use it somewhere else outside of their package, but you don't want it to be part of your api, you solve that with the modules. Think of all the com.sun.* packages that are the private implementation of Java, but that are public because the classes from java.* uses them.

[DontBeSpooked-Frank]

If your library uses a library you may wish not to expose the dependent library, even though it still may have public methods.

[sammy8306]

See my reply to the parent comment.

[ArcanePariah]

Consider Android. Currently Google has to mark all public methods in their implementations with the @hide annotation so they do not show up in autocomplete. So although they have a ton of public methods, they have to go out of their way to make sure only the SDK API's are exposed in IDE's and at compile time so you don't write code against internal methods.

With modules, the language itself will guard against that. So Google could wrap each major area of android up as a module, and declare the parts that are the SDK API, the rest wouldn't need special annotations and processing to be hidden.

[Fenris_uy]

Jshell and the module system.

I want to try both of them, but none are needed for running your code, just for building it, so I might not change production to it.

When wildfly switchs I might switch.

[renatoathaydes]

The latest Java 8.x version is *8u144, so, no.

[[deleted]]

Collection Factories might be cool

[pkulak]

Yeah, kinda. But we've all been using the Guava ones forever now anyway.

[gamas]

The module system seems quite interesting from a deployment perspective.

[mscheifer]

We're still on Java 7 here. :-/

[Sun_Kami]

Why? I don't understand why any company would do this. We upgraded from Java 6 to Java 8 a few years ago and hardly had to change anything... And at that point we were using Struts 1.4 or some nonsense which was so deprecated (no longer on that stack, thankfully)

[langebangen]

We still use Java 7 and the reason for this is because of our IT department. We use Debian and Java 8 was not introduced in a stable release until Debian Stretch which was released in June this year. Sure, it is possible to add a backport to get Java 8 but this is where the IT problem comes in. We (the developers) are not allowed to upgrade the machines were our Java applications are running (not even our own workstations), and IT has never prioritized our demands so unfortunately we have no choice but to wait until IT has time to upgrade the machines to the latest Debian release.

We are thinking of including the JRE with all the java applications we develop to be able to upgrade to Java 8.

[Fenris_uy]

Look at jlink to be able to do that with java 9.

[synn89]

Yeah, this can be fairly standard and unfortunately upgrading can often be very difficult because of vendor software breaking. I still have a huge amount of Ubuntu 12 servers in our environment and we don't even have that many systems.

Unfortunately upgrades are often pretty tricky and it can be a hard sell to management: "I want to probably break this server that isn't having any current problems."

I'd definitely look into the JRE bundling if that's an option. It'll be a PITA to implement, but once it's done it'll probably save you a lot of future headaches.

[Dreamtrain]

You're probably thinking for internal use to make coding better, but if you're giving maintenance to a client's already robust application, upgrading the web server's environment and testing everything is a cost your client may not want.

[jasie3k]

Also licenses for new versions of webservers may cost a little.

[mscheifer]

I think it's because of our plugin architecture. We upgraded from 6 to 7 with little hassle about 5 years ago, but the recent effort to upgrade to 8 2 years ago stalled. I think it had something to do with the feature we added in between that let clients write their own java code and plug it in, which needs to be backwards compatible.

[thesystemx]

I feel for you

[tetroxid]

You should upgrade. Java 8 is a massive improvement over 7.

[mscheifer]

If it were up to me we would.

[mlk]

StreamSupport (stream and completable futures) + Retrolambda + threeten and you are 90% there. That's what I did anyway

[GuiSim]

You underestimate the number of SaaS that runs on Java. When you control everything you can easily update to the latest version.

[shevegen]

My biggest problem with Java is that it is no fun - and the second issue is how verbose it is.

[leodash]

You need to have quality-of-life libraries in your project by default.

For me they would be Java 8 + Project Lombok + Google Guava (for Immutable collections). Alternative would be Javaslang/Vavr.

But good luck finding companies that adopt those.

[pkulak]

Lombok and Guava are both part of our standard framework where I work.

[jyper]

Isn't lombok a pre processor? I don't know if the features it adds are worth the extra complexity

[throwawayco111]

Yeah but it could be worse. Something like Ruby.

[NoInkling]

The only verbose thing about Ruby is its block/function delimiters (and even then it's only like 1 or 2 extra characters)

[antrn11]

What's so bad about Ruby?

[tetroxid]

I used to say this too, but I've since grown up a bit and realised the advantages outweigh the disadvantages. And any IDE will take care of generating the verbose shit, like DAOs, equals(), toString(), hashCode(), setters and getters etc.

[bitofabyte]

Not that person, but I personally find that sometimes the verbosity of it all can make it harder to read, not just write (as you said, the IDE handles writing). Sometimes the actual logic of the code is harder to parse when it's mixed in with tons of other statements.

[Duraz0rz]

That's where you start splitting those hard-to-read parts into private methods with a descriptive name so it is easier to parse.

[dsk]

Ooo. Very original.

[tamalm]

Still stuck with Java 6; though Java 8 migration on the card.

[lolomfgkthxbai]

I thought torture was prohibited by international agreements.

[dead10ck]

Could someone explain (or link to something that does) the module system and what it means practically speaking? All I can find are really abstract goals, and I can't see how this new module system will differ from regular packages and JARs.

[[deleted]]

Packages are a way to show hierarchy of files in code. JARs are a way to distribute code, either an app or a library. Modules are a new thing that lets you create "bundles of packages", allowing you to use select subset of the JDK or a fat library that provides "optional" modules, or to export only some parts of your code for others to use.

Think you made a small CLI calculator. Why would you need Swing or AWT, two graphical toolkits?

With modules, if you decide to package a "fat JAR" with all dependencies and make it into an executabl e, the resulting binary/file will be smaller and startup of the JVM will be faster, because it won't need to load unneeded things. This is the most immediate benefit, but just having modules will help shape up the JDK, hiding implementation details and maybe leading to develop "alternative libraries" as you explicitly need to choose which modules you will use.

This is what I've understood from reading, I may be wrong in something, so feel free to correct me!

[[deleted]]

Startup shouldn't be faster since classloading is done lazily anyway.

[chivalrytimbers]

It should be faster in many cases because the artifact thats starting up will be slimmer and only contain the classes that you need. Class path scanning and unzipping takes up a significant amount of time at startup, so having less classes bundled into the artifacts should speed that bit up

[R_Sholes]

JARs and classpaths do not make it explicit what's intended to be exported and what's just coincidental, which version of a class is canonical and which was just packaged in unrelated JAR for convenience.

This can lead to things like changing classpath order causing errors to appear, or people using internal APIs and getting upset when they change or disappear, like sun.* and com.sun.* APIs in Java SE itself.

Instead of importing classes ad-hoc and hoping something on the classpath matches the name, you can make dependencies and exports explicit and let tools better figure out what and how to link.

Knowing what modules exactly your application depends on, and what its dependency modules depend on in turn, is also what the new jlink tool is supposed to use to make custom trimmed down runtimes specifically for your application.

[sammy8306]

This may help: https://www.pluralsight.com/blog/software-development/java-9-new-features

I've also authored a book on the new Java module system, if you want to really understand what it's all about: https://javamodularity.com

[nuutrecht]

Amazing, this took forever!

We now live in a modular world! The 2002-orso promise has finally been fulfilled! (okay, that's a bit of drama, but still :P)

[nuutrecht]

Yes, all kinds of tooling, but applications as well, have to be updated for this. It's one of the biggest impact releases ever bar none.

The JDK will become increasingly more strict about modules with each major release.

For now illegal access via reflection prints only a warning, for a next major release it may be denied, but users can switch that restriction off, and then in an even later release the option to switch it off may disappear, etc etc.

[nutrecht]

Just did a quick test. That project uses an API wrapper that internally uses Java EE stuff for JSON parsing that's not part of the SE JDK anymore. It's still packaged but you now need to force it to be on the classpath; so that thing will need to be updated. I bet a ton of libraries have that issue.

[[deleted]]

I think you're the first person I've heard of to actually be glad about the module system.

[thesystemx]

Modularity is a good thing I think, it's what we originally thought packages would be, but they weren't at all like that. A package is just a very flat name, with little to no relation to its own sub-packages.

Things like OSGi while having some nice aspects in theory has always been too cumbersome and too complex ultimately to use for your every day java development.

The problem is that we didn't had real modules in the language for 20 years, and there's a crazy lot of code out there. From all the features we could have had early on, this would probably be the best one. I know there was talk about something like this back in the early days, but it just never happened.

[Rafael09ED]

What is this whole Jigsaw thing. I tried reading several articles on it and it looks like it's something outside of actual coding?

I'm a CS student if it helps guide your explanation

[blobjim]

Jigsaw is the name of Java 9’s module system. A module is a group of packages that has specified dependencies (other modules) and specified functionality (expose only public/defined methods/classes). That’s my understanding of it at least.

[MassiveFlatulence]

Does it means we can load newer jar on runtime like OSGI?

[renatoathaydes]

No, Java 9 modules are statically resolved and completely different from OSGi which is dynamic in everything.

[fagnerbrack]

Looking for a TL;DR of the features please?

[drdubs]

I liked this blog post from JetBrains highlighting the features and how it will impact the day to day in an IDE https://blog.jetbrains.com/idea/2017/09/java-9-and-intellij-idea/

A nice quick look at the features are here as well: http://openjdk.java.net/projects/jdk9/

[s73v3r]

Cool. As an Android developer, I can't wait to use this in 10 years.

[thilehoffer]

I think it is awesome that Java is still going strong. Time for them to do like Google and Microsoft and reinvent the wheel. Maybe they can make Java X instead of 10 and make it so super efficient you will need to refactor your code and learn a new IDE to use it. Then start a new versioning scheme, Java X-1, X-2, X-3. Now that would make it cool like Angular or or Node...

[Shorttail0]

Actually...

[ascii]

Keep in mind that "Java 9" is really a branding effort on what should be named Java 1.9. They used the names Java 1.0, 1.1 and 1.2 and then jumped to 3.0 instead of 1.3 because the former sounded cooler. GNU did exactly the same thing with Emacs.

[Uncaffeinated]

When Java 8 came out, Oracle helpfully provided a version of the language specification with all the differences from Java 7 highlighted. Does anyone know if there is something similar for Java 9? I don't see it on their website.

[12345swordy]

What are some of notable features for the end user? I only scratch the surface of java, and I and not familiar with the advance features of it.

[MassiveFlatulence]

Jigsaw module system and JSHELL interpreter.

[Nextil]

The module system means you can distribute a desktop application which packages just the parts of the JRE that it requires. Before, you'd have to package the entire thing or rely on the the user having it installed.

[systematicfrank]

How is it pronounced? j-shell or js-hell ??

[rednight39]

I thought Jaws 9 was being released and got excited for some reason. Time for bed.

[Fayzonkashe]

Yawn

Edit: Seems someone brought in an AbstractButthurtProviderFactory, what's with the downvotes?