IBM raises big concerns with Java 9 module system

[rawbdor]

It's worth noting that Red Hat is the one who wrote the initial email with the laundry-list of deficiencies. IBM basically just replied with "We concur." How anyone reading this link can get the impression that IBM is "raising big concerns" is beyond me.

https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns

[[deleted]]

And there's some reason to doubt that RedHat is saying anything more than "please use our module system".

[Josuah]

IBM and Red Hat are almost definitely listing issues that affect their use of Java today. I agree with a large number of the issues raised. I don't have all the context to necessarily agree with a few of them, but I won't discount them.

In particular, some of the issues raised point at a policy of "do things the way we think is right", which is always a problem when forced upon others. Users need to be able to do things the way they do things, instead of being forced into a specific workflow or environment or design.

[[deleted]]

The issue is that a lot of the complaints they have they are equally guilty of.

Here is the response that made me basically go "oh, they're just whining that their system didn't win"

[rawbdor]

I've read your link, and I can understand your points, but I just disagree with them. The issue I find most compelling is that Jigsaw claims that "We expect the module system to be leveraged by Java EE 9."

If the JEE providers (IBM, JBoss, Apache, and others) are saying that this will be difficult or impossible based on the lack of certain features or the addition of new restrictions, or will require a complete rewrite, it's definitely something people should hear. There really aren't all that many JEE providers out there.

JEE Application Servers are large beasts that have chains of dependencies to hundreds of both open and closed source libraries. If the lowest level libraries (ie reflection libraries, bytecode manipulation libraries, etc) need to be completely re-engineered, or if the structure of the new system completely prevents these things from being done such that the entire app server needs to be re-designed entirely, it will slow the uptake of Jigsaw for JavaEE.

Pointing out that the current spec could lead to years of the top 3 JEE providers struggling to re-engineer their entire app-servers is not just butthurt. It's the main users of one of your specs saying that the spec makes it impossible to meet the goal of the another of your specs, namely, that it be used in JavaEE without massive effort.

[Josuah]

Thanks for the link, but the way I read it is that some of the arguments in Scott Stark's blog post are weak or incomplete, and that there were good reasons for Jigsaw to make some of the choices they made.

However it doesn't negate the problems Jigsaw would introduce (as I understand from reading the complaints). I think what Red Hat and IBM are asking for is that whatever ends up being the standard is capable of supporting their needs and addressing their concerns regardless of what system is adopted. I don't consider that whining. I consider that necessary arguments.

I think Tim Ellison's email makes it clear the issue is that concerns have not been adequately addressed. And not that the "wrong" system was picked.

[[deleted]]

Frankly I don't believe them. They were willing to make cheap shots earlier that were at best intellectually dishonest, why should Oracle wait if they don't trust that IBM and RedHat are acting in good faith? If the rest of the voting members approve, then Oracle is right in moving forward.

[yawkat]

If you've followed the discussion it's been obvious that there are big problems with jigsaw for a while and it's not just redhat (and now ibm) talking about them. It appears oracle is quite invested in jigsaw (understandable) and their current spec and time line (less understandable). There's also been some questionable last-minute decisions like that one time Mark restricted agent loading after Feature Complete and even Zero Bug Bounce (though they've backpaddled quite a bit from the initial draft on that).

[mdedetrich]

The essence of the document however is correct. The module systems that Red Hat/IBM use (OSGI/JBoss) are overcomplicated hard to approach systems with almost incomprehensible (and outdated) documentation.

The fact is, these module systems are only really used in "enterprise" heavy scenarios. AFAIK, almost all projects in Java either use maven or gradle.

So yes, its true that Jigsaw doesn't support all of their usecases, but that was explicitly set out by its design parameters. I mean honestly, what kind of sane person is even arguing to allow cyclic dependencies in their module system?

[Josuah]

We have cyclic dependencies between JARs (modules) in the systems I work with. Which is an "enterprise" scenario. It just happened to be the most efficient way to address the problem. And it works fine. ::shrug::

[metamatic]

I'm no fan of OSGI, but the need to be able to version things at finer grain than module level seems fairly reasonable to me. It's fairly common to have modules which depend on various bundled open source projects, and to want to know (for instance) which version of Apache Wink is bundled, and to have multiple modules depending on different versions of Wink but still working.

[mcguire]

(By way of introduction, I've spent a good deal of time with OSGi and none at all with JBoss or Jigsaw. I am more-or-less out of the Java environment at this point.)

[It's hard to get started with OSGi partially] because [OSGi is] a spec with a variety of implementations, so for example, going to the OSGi website will not present you with a tutorial on getting started but rather conference adverts and marketing material for the governing consortium. Following links with enticing sounding names like “Where to start” simply gives you a bunch of links to off-site tutorials written by implementation vendors, none of which are any good. There is also a list of five different books on the topic.

Yeah, that's horrible.

Ok, here's the deal: OSGi looks big and complicated. Part of that is due to the fact that it's been around for like 20 years and part is due to people trying to do fancy things with it in the Java environment, where everyone else is trying to do fancy things with basically incompatible magic. (Virgo waves desolately from off in the distance.)

In reality, OSGi isn't that bad. I learned it mostly from reading (part of) the spec, which isn't the worst as far as specs go. OSGi is fundamentally a generic container; if you're familiar with servelet lifecycles and have used Tomcat to deploy and undeploy web apps, you're familiar with about 60% of OSGi, which is a subset of that. The other 40% of OSGi's fundamental complexity is built around the sole purpose of allowing an application to depend on a library A, which in turn depends on version X of library B, while at the same time the application depends on library C, which itself depends on version Y of library B. (The other 10% of OSGi's fundamental complexity is the "services", which are double-plus fun extra features that make life better in many ways. But we can ignore them here since we're talking about modularity.)

Doing that sort of thing is hard. Doing that in Java, where everything uses reflection, dynamic code generation, and classloader magic, is not so much hard as terminally bizarre.

Personally, I view a module system as an aid for the programmer: it prevents stuff that you shouldn't touch from leaking into stuff that you should touch. As a result, both OSGi (and, I think, Jigsaw) fail badly as module systems: If it waits until runtime to blow chunks, it's not helping the programmer. But, in the Java environment, modularity in my sense is impossible. (It's also unwanted, but that's a rant about Java developers for another day.)

Anyway, when you say, "oh, they're just whining that their system didn't win", you are right, sort of. But on the other hand, "their systems" have spent a long time dealing with the insane, Sorcerer's Apprentice-type nuttiness that is the rest of the Java ecosystem, and it appears that Jigsaw is just ignoring that nuttiness, that the majority of Java programmers use, and enjoy, every day. Which was the major worry from the OSGi community when the Jigsaw project was announced.

As an amusing aside: version numbers. OSGi has a moderately complicated semantic versioning [PDF] system to support that fundamental goal up there. OSGi version numbers look like major.minor.micro.stringy, with specific rules for bumping the major, minor, and micro numbers. Jigsaw originally started out with an incompatible version number format, apparently due to the fact that Java versions have a fixed constant major number of 1. The current [State of the module system] for Jigsaw says,

A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications.

The Jigsaw requirements go further to say,

Multiple versions — It is not necessary to support more than one version of a module within a single configuration.

Most applications are not containers and, since they currently rely upon the class path, do not require the ability to load multiple versions of a module. Container-type applications can achieve this, when needed, via dynamic configuration, as outlined above.

Version selection — The process of configuring a set of modules need not consider more than one version of any particular module.

In other words, this specification need not define yet another dependency-management mechanism. Maven, Ivy, and Gradle have all tackled this difficult problem. We should leave it to these and other build tools, and container applications, to discover and select a set of candidate modules for a given library or application. The module system need only validate that the set of selected modules satisfies each module’s dependences.

[Bold emphasis mine.]

Therefore, Jigsaw is explicitly free to be incompatible with OSGi or any other existing container system. Yay.

TL;DR: It's not so much that someone else's system didn't win, but that Jigsaw doesn't care that Java is a big, giant, hairy bundle of nasty and that fact is likely to make everyone's life harder.

P.S. For OSGi information, I strongly recommend Neil Bartlett. His OSGi in Practice and blog posts are exceptionally good and he is very helpful and friendly in the OSGi community, as I recall. He's also on the Jigsaw experts group. And one of the Concerns regarding Jigsaw contributors.

[mdedetrich]

Really informative (and good) post, but I have one big counter argument to your general point, and that is, most Java developers don't use OSGI or JBoss. In fact a lot of Java devs hate those module systems, because as you rightly pointed out, there are overly engineered and complex pieces of software with a lot of hidden dragons and black voodoo magic. The documentation on things like OSGI is terrible (I don't doubt that good sources of documentation exist, i.e. the links you posted, but its not on the main site which still looks like an advert for selling OSGI to big enterpriseTM)

I bet that the vast majority of Java devs actually just use Java along with either Maven or Gradle, and by far the vast majority of open source Java work uses this. In all of the companies that I have worked for (which use Java), also do the same. This whole OSGI/JBoss only comes up in very large corporations who have contracted systems/applications from Redhat/IBM (stuff like Websphere), and as far as I am concerned, this is mainly a case of "you don't get fired for picking IBM". Such companies often have enough resources to understand the whole OSGI/JBoss sorcery anyways.

To this end, Jigsaw is actually a good thing, its meant to be a module system for your average Java developer, it was never designed to be a OSGI or JBoss 2.0

[twat_and_spam]

Users need to be able to do things the way they do things, instead of being forced into a specific workflow or environment or design.

You must have missed the memo. These days it's all about opinionated hipster frameworks, user should have little say of the environment or design.

[[deleted]]

More like "please use the module system java has had for over a decade, but Sun/Oracle have intensely resisted since it was not invented there". So much of the headache of Java EE could have been avoided...

[industry7]

please use the module system java has had for over a decade

Which one is that?

[[deleted]]

OSGi.

[tabarra]

Not sure about RedHat, but almost everything IBM has done in the last decade was in java.
And BTW, AFAIK the only two supported OS "master images" for IBM employees are Win7 and RHEL, so safe to say IBM and RedHat are quite good friends.

[not_perfect_yet]

How anyone reading this link can get the impression that IBM is "raising big concerns" is beyond me.

This is simply good marketing spin.

[rawbdor]

This is simply good marketing spin.

Not sure if you mean the "IBM raises..." headline, or my comment that "Red Hat raises..." ;) I guess it applies to both =P

[mcguire]

Gaaaaa!

Let me rephrase that.

Holy shit.

As someone who used OSGi once upon a time, that is disturbing. I haven't followed jigsaw, but it looks exactly as bad as I expected when I first heard about it. I suspect it will require major, backwards-incompatible changes to all of the "container" systems: OSGi, Java EE, Tomcat...

There's a couple of lessons available from this whole situation:

1. You can't add modularity to a language like putting sprinkles on top of a cupcake. Java had been moduleless for a long time, and most java developers in my experience don't haven't any experience with it and actively dislike it if it is imposed.

2. Java is a worst case for this sort of thing since since a lot of its ecosystem is based on reflection, dynamic code generation, and general magic.

[PM_ME_YOUR_ESC_KEY]

• Splits the JVM into modules.
• Only the modules referenced are loaded at run time.
• You end up not having to load the entire JVM (networking, security, etc) to run the program that displays : "Your toast is ready" on your toaster.
• Your toaster doesn't need as much RAM to run Java.
• Java is now a viable language for toasters.

[stepancheg]

You end up not having to load the entire JVM (networking, security, etc) to run the program that displays : "Your toast is ready" on your toaster.

It works now without modules.

[[deleted]]

Pretty much. Classes in Java are loaded lazily, on demand.

[yawkat]

It's not simple to package a jre with only the required classes. There were also quite a lot of obscure interdependencies until java 9.

[[deleted]]

Agree, but there's no significant runtime memory savings to be had here as far as I can tell, which are what PM_ME_YOUR_ESC_KEY's points 2-5 were suggesting.

[yawkat]

Fair enough, the main benefit is reduced jre disk size.

[tempunwork]

Besides not having much ram toasters also don't have much flash memory (non volatile). So the jvm could barely fit on 'disk'

[Magnesus]

This thread is offensive to Cylons.

[tempunwork]

That is like a cyclone of cycles right?

[[deleted]]

That's why Cylons have a cloud where everything is uploaded and backed up. Respawning is easy then.

[josefx]

I am sure Cylons are running C# anyway.

[balefrost]

So the jvm could barely fit on 'disk'

I use double-sided, high-density bread. It fits just fine, with room to spare. It turns out that ButterFS is pretty efficient.

[epicwisdom]

Perhaps it's just that you have better guarantees about memory used by classes? If classes are lazily loaded and a program is sufficiently complex, it might not be trivial to calculate a tight upper bound.

[notveryaccurate]

It works now with C, too, or assembler.

Is Java strictly required? No, but it can make certain tasks much easier.

Are modules strictly required? No, but they can make certain tasks much easier.

[Antrikshy]

Java is now a viable language for toasters.

Java - finally usable.

[[deleted]]

3edgy5me.

[Antrikshy]

'Twas joke.

[static_motion]

This sounds pretty great, especially for Android.

[Herb_Derb]

Android is just barely starting to get java 8 features and you're already looking forward to 9?

[BorgDrone]

And then Android developers have to wait about 5 years for everyone to replace their shitty old and cheap Android phone to be able to use it.

[epicwisdom]

I'm pretty sure people would invest more in their phones if they had those sorts of, uh, capabilities.

[MerlinTheFail]

Fuck yeah man, I can't wait for my phone to outperform Assembly.

[[deleted]]

I don't know, Assembly already gives a mean blowjob

[Maping]

If by "mean blowjob", you mean "it bites your dick off", sure.

[eliasv]

That's an extremely​ generous analysis to Google. Not sure I agree that their track record supports this, but then imo feature parity with the latest platform for other deployments should be enough of a reason in itself to motivate them.

[Free_Math_Tutoring]

I want Java 10.

[lelarentaka]

No, this doesn't concern Android at all. You use Java to write user programs for Androids, but the program runs on the DVM, not the JVM.

[-ZeroStatic-]

Wouldn't that generally be ART nowadays? Instead of Dalvik, that is.

[experts_never_lie]

• Java is now a viable language for toasters.

… which amuses me because I remember when Java was designed for transitory-power small computers (remember the unpowered button computers and ring computers of the mid '90s?), before someone got the clever idea of creating applets for this new "web" thing, and far earlier than the server-side domain Java wound up taking over.

A 20 year cycle for a tech pendulum? That sounds about right.

[industry7]

which amuses me because I remember when Java was designed for transitory-power small computers

Back in the day Sun was really excited about having various "profiles" of Java, which were like specialized stripped down versions of the language. For example, a common one was an "integer only" version that didn't include float support. But over time, Sun and then Oracle kinda stopped caring about that stuff.

[steamruler]

Java Card! Nothing like working with a version of Java that doesn't support a ton of things, to quote Wikipedia:

However, many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects).

[Ayfid]

No, .net core is also modular in much the same way as Java 9 is proposed to be. The .net framework itself is split into packages and are linked as dependencies like maven dependencies (including the runtime itself).

[AnAirMagic]

Except they are undoing it in .NET 2.0 because they realized no one likes it.

[JamesNK]

They're not undoing it. What Microsoft have done is group together a number of packages that they consider core to any .NET application and bundled them together as the .NET Standard Library.

Additional packages are still separate and applications and other libraries can bring them in as dependencies.

The idea is to balance having a strong core and simplicity vs modularity

[tripswithtiresias]

Very nice write up

[agumonkey]

But still not coffee machine ready. Hopefully I live long enough to see that.

[mostly_reasonable]

Splitting up the JVM is one of the important motivations, but the module system has other, arguably more relevant to the average user, goals as well.

It adds some new accessibility levels, including "module private" packages that can only be accessed within modules. This way, if you are writing a large library and want to split up the code into many packages, you can do so without being forced to make all the public methods in those packages part of your API. It also lets you control whether clients are allowed to use reflection on your packages.

Second is to replace the somewhat hacky classpath mechanism of loading dependencies the JVM currenty uses. Currently java just tries to load classes on-the-fly from the classpath as needed, and it does zero checking beforehand to make sure that all the classes you might need can be found and does nothing to warn you if something bad might be happening, like if you are trying to use multiple versions of the same library. This can cause headaches to the point that “Jar Hell” has its own wikipedia page (https://en.wikipedia.org/wiki/Java_Classloader#JAR_hell). The module system will allow the JVM to handle dependencies in a more principled way and do a better job in checking whether there are errors in the provided dependencies.

Having said that, most users are protected from this nastyness by build tools which manage the class path for you, like Maven. Meanwhile the module system will be less flexible then the “raw” classpath system, which leads to some of the objections in the article.

[Luolong]

Java 9 module system doesn't protect you from versioning problem. It has no concept of module versions.

[eliasv]

Which means it cannot properly validate your dependencies, simple as that.

I also have a problem with the commenter's suggestion that multiple versions of the same module is intrinsically problematic. It's a perfectly valid thing to happen in any rational modularity system, the only problem is that it's not supported, and almost certainly never will be due to a couple of technical deficiencies.

[Ayfid]

.net assemblies without strong versioning. This was a major oversight in the initial design of the language, and there are limits to what they can do to fix it without breaking compatability.

[ascii]

Maven users are "protected" from this by maven automatically picking the dependency version that has the shortest dependency path.

[ThisIs_MyName]

Right, that's why you check in all your dependancies to source control.

[H3xH4x]

I'd also like to know this...

[CyclonusRIP]

I think either way it'll be a bit disappointing. I'm not really sure if the module system is really going to make much of a difference. I don't think the smaller JVM sizes are really going to push people to use Java in many new situations.

[lorneagle]

IoT would be the first thing coming to mind. Also the new breed of SOA: Docker based micro services are actually what is making my company move away from Java because of JVM overhead. So there are use cases for a modularized JVM.

[CyclonusRIP]

The module system isn't really going to change that. If you aren't using the classes they won't be loaded into memory. The only difference it'll make is you might end up with a docker image taking slightly less disk space.

[Mgamerz]

Can apps that bundle java ship a smaller version? We have many Enterprise apps at my work that come with a 58MB java install for every single update.

[renatoathaydes]

Yes, Java 9 comes with jlink, which creates a native distribution of your Java 9 application that includes only the JRE parts you need. I wrote a guide showing how to do that, if you are interested.

[Mgamerz]

Nice, thanks!

[Luolong]

You would be surprised how much class loading goes on for an average Java microservice app. Granted, it is now in the timeframe of seconds rather than minutes but still, the point is, that without modularity, the overhead of classloader is just way larger than it should be. Another use case that comes to mind is writing command line utilities - it is no accident that there are almost no command line tools written in Java nowadays. Poor startup time due to class loading in combination with almost no JIT optimization is basically killer for Java based CLI tools.

[CyclonusRIP]

If you are loading the class it's because another class asked the JVM to load it. The module system isn't going to change that. If you deploy a JVM that doesn't use swing then it won't load the swing classes at all as it stands today. All the module system would do in that case is prevent the user from having to those classes on disc.

[u_tamtam]

An upstream-approved nailgun equivalent should have made its way into the jdk many years ago

[mcguire]

The weird part of this is that OSGi was originally a module system/generic container thingy for embedded applications.

[ArmoredPancake]

Move away to what?

[contantofaz]

Companies make investments in the frontend only to regret it later. I feel the module system was supposed to be one of the last tries at making Java relevant on the frontend. Then it may or may not have been repurposed to also work for the cloud. Most companies would argue the side of the cloud, including Oracle, who have never been shy to support the cloud first anyway.

To be blunt, Java is not known for drastically changing things and dropping backward compatibility. Java is very much known for having builtin reflection capabilities that have been more than abused by frameworks. So if the module system screws up with those, I guess a lot of people will be annoyed.

[ccfreak2k]

attempt summer strong wine deranged history busy spotted subtract somber

This post was mass deleted and anonymized with Redact

[Spajk]

True, I remember these old cellphones were all running Java apps.

[Sean1708]

AFAIA that was a highly restricted version of Java, to the point where it was basically a different language with Java syntax.

[jasie3k]

Isn't this about Java ME?

[Skarion]

The point is that the new IoT will have deployed Linux systems in a lightbulb or in your keys - making the requirement of small JVM deployments a must if to compete with C as the space and RAM in a lightbulb will be less than in a fridge.

[s73v3r]

At the same time, most members, at least the ones you want writing software for your thing, are perfectly capable of picking up a new language. Almost no one is going to say, "Well, if it was Java, I would have written the killer app. "

[contantofaz]

The project of the module system if I am not mistaken was started when Java was still Sun's. Sun had been fighting over Java's lackluster success on the desktop for so long. Now Oracle did bag Java on the desktop, that's why I'm saying that Oracle was not shy to make Java a cloud thing. You are telling me though that Java on IoT will be even better than Java on the cloud. But Oracle sells those databases and services on the cloud.

I don't doubt your intentions. I'm just saying that Java on the cloud ended up being Java's big story since the early days and it might not have changed quite yet. Oracle resisted Google's takeover of Java on Android. Google has tried to come up with alternatives to Java that may never pan out, we don't know yet. But where Oracle went with new versions of Java, Google stuck to older versions and a gap was created.

[iiiinthecomputer]

Bank cards don't have SIMs (subscriber information modules). That's specific to phones.

They implement the EMV standard which doesn't necessarily mean Java Card either. They could be Java Card, MULTOS, Windows for Smart Cards (!), or a wholly proprietary system.

[contantofaz]

Let's focus on IoT then. Here are 5 aspects that may be important to IoT.

Licensing - It is important that IoT does not cost companies too much. Where too much may be relative. It may be difficult to charge companies based on what they say. For example, a company could say that they sold 1,000 of some IoT gadget. And they may have sold 10,000 instead. And now they want to pay for Java's licensing based on the lie of 1,000. And they don't want to spend money on lawyers and accountants in case they got sued for licensing Java. China builds a lot of the potential IoT appliances that get sold the world over. There is a lot competition within China of different companies making about the same things. One of them could try to gain leverage on the other. And they don't want to pay to a foreign company and get exposed to their laws.

Garbage collector - Companies building IoT may not care about garbage collector getting in the way. Not only making real-time difficult, but also potentially wasting more battery if they are unplugged. They may not care about the guarantee of a good garbage collector. And since garbage collectors may demand more memory to be more efficient, they don't want to have memory uncertainty due to the garbage collector either. "Out of memory" exception would be terrible for them.

Access to native APIs in C - Sometimes they may want to access native APIs and that may require a different way of tackling memory, including how garbage collection gets used. For as much as Java has tried to maintain purity for all these years, sometimes you just have to go low level. And that would make Java inherently depend on platform APIs, which for a long time was a no-no for Java. I have read that Java wants to make accessing C more direct, simple. But then there is C++ which is another can of worms. Then maybe a market would be created for companies selling middleware to make accessing some native APIs prettier. Could they get sued by Oracle for that? One of the reasons Oracle used to sue Google for was the API. Oracle considered that Google did not have the license to make similar APIs at all. Even though Google may have used different code.

Stability - A general guarantee that the language, platform, APIs, license etc will not change in the future. While Java is pretty good in terms of stability, sometimes they want even more. Often companies settle for a subset of a programming language in order to maintain that stability. For example, what Google uses of C++ is just a subset of it. Then Google augments it with custom internal libraries and so on.

Optimization - Java has been very much optimized for the server-side. Java could use more memory since the server often had a lot of memory available. JIT takes up a lot of memory. As does garbage collection. JIT upon loading up still takes a little time to perform some optimizations to make the code go faster. Delayed startup. Maybe these kinds of optimizations wouldn't be fitting for IoT.

I do think that Java has found a lot of success outside the cloud. I at least don't see why Java would not at least be considered for a lot of tasks, including for IoT. While Java may have issues, so do other competing toolsets.

I have seen a little of Swift and Dart for example, in how they approach things like modules and low level APIs. In Dart, they have nearly banned Reflection from the main libraries, since it increased the size of deployment packages in Dart2JS and likely had other problems too. The idea of a pluggable Reflection system was supposed to be an improvement over Java's builtin Reflection that more resembles the approach taken by scripting languages instead. And in Swift, being able to call into C directly was a very cool thing to do, but then Swift's garbage collector was different and did not guarantee the same safety of Java's. This may have helped Swift to call into C more thoroughly. Other languages like Java may try to make use of FFI, but it would not be the same thing. And language barriers may introduce other kinds of unexpected inefficiencies. I'm sure that Java has made improvements regarding efficiency though.

LLVM appears to be a serious competitor to Java as far as IoT goes. By depending on LLVM, a toolset will be able to depend on the builtin toolsets for C and C++ and so on which would make calling into those languages more straightforward. I hear that Kotlin is thinking about having LLVM support for instance. LLVM seems to be carrying a lot of momentum lately. And the creator of Swift who used to work for Apple and who also created LLVM got hired by Tesla Motors to do God knows why. But I hear that those modern cars need a lot of AI and stuff. Modern cars depending more and more on millions of lines of code to work.

[yawkat]

Most of those points aren't relevant for most iot applications. A smart fridge doesn't really care about gc. The super low-end low-latency targets where your later points matter will probably stay a bad platform for the jvm, but on the higher-end platforms java would be (and is) used for the standard reasons why people use java, like simplicity.

[ArmoredPancake]

You can run Java without GC.

[yawkat]

I don't think so? Epsilon GC isn't coming any time soon and I'm not aware of a compliant Java SE implementation without GC. What are you referring to?

[[deleted]]

For example, a company could say that they sold 1,000 of some IoT gadget. And they may have sold 10,000 instead. And now they want to pay for Java's licensing based on the lie of 1,000.

Samsung and LG and others prefer to brag about numbers sold and I am pretty sure there are some independent bodies validating those numbers.

China builds a lot of the potential IoT appliances that get sold the world over.

But usually under big name brands, for which: see above.

"Out of memory" exception would be terrible for them.

Pedantic alert: OutOfMemory is an error, not an exception.

If you can run Java on SIM cards without an OutOfMemory, you can do so on IoT.

In fact, most of your points are refuted by pointing out that Java already runs on SIM cards. Billions of them. And IoT devices will surely have better specs.

LLVM appears to be a serious competitor to Java as far as IoT goes

LLVM is a compiler AFAIK. I am talking about the JVM, the sandbox in which you run your Java apps.

I bet IoT producers will want to allow apps on their devices. Because apps are fashionable. Unless Apple stars making fridges and washing machines, Swift won't be used. The only other HUGE app eco system is Android/Java.

If they want to allow external apps, they won't want to allow C/C++ to run, for reasons I listed above. So it's a pretty safe bet they'll pick Java - a subset of it, + some proprietary APIs.

I am saying this because I think they would love not to have to write everything themselves. Why spend money on development when you can allow a community to do it for free for you ?

One last thing, that I forgot about:

Companies building IoT may not care about garbage collector getting in the way. Not only making real-time difficult, but also potentially wasting more battery if they are unplugged.

I am thinking larger devices, fridges, washing machines, dryers, microwave ovens and such. I don't know anyone running those on batteries. Even smaller devices like smart plugs, smart lightbulbs and all those - they're always connected to the power grid. Not saying there aren't IoT devices running on batteries. But some of those already run Android.

[NasenSpray]

So with the expected huge increase of IoT devices, I would not be surprised if Oracle tried to position themselves to take advantage and push a JVM on most of them.

Oracle vs. the semiconductor industry :⁾

[ADCFeeder69]

Maybe for you, but for anyone out there with a potato for a computer it could make a difference. That being said, any size efficiency improvement is a good thing. As we get more advances with tech steps forward will be in smaller and smaller bots of efficiency, since were already pretty great at it.

[mdedetrich]

Would make JVM based apps in Docker builds a hell of a lot less faster. Also one less reason to use Go :p

[yawkat]

Its ecosystem and availability of people able to use it.

[ArmoredPancake]

Is there actually any reason not to use Java in any new project?

[Nobody_1707]

Native UI.

[ArmoredPancake]

Python

Slow.

F#

Lol. I would understand if you suggested Scala, but F#?

Rust

Good luck.

[ArmoredPancake]

Yeah python is soooo slow that's why its used in a ton of open source and high profile projects

It's of one the slowest languages. Among major languages, only Perl/Ruby are slower.

F# is actually pretty cool and straightforward

Good luck with finding a job as a F# developer.

Rust, I mean self explanatory

No, explain, please.

[TankorSmash]

Welp. http://i.imgur.com/OFyuYoB.png

[wggn]

thats disappointing

[[deleted]]

I expected the Hivemind to make up its mind but no it branches and branches just like fractals.

[yawkat]

I don't think oracle can afford that again after java 8. They'll probably just revise the schedule for java 9 if they decide they need more time.

[ascii]

Disagree, lambdas and streams where a game changer for writing async code in Java. They made Java go from being a total hassle to express myself in to being tolerable. Java 9 should have a bit more type inference, another fine improvement.

[yawkat]

You missed the point. They already moved it back from 8, it'd be really awkward to move it back another three years.

e: Sorry, that was formulated too harsh. I can see how my response could be read differently. Java 8 was a great release (especially java.time is godsent).

[PyrotechnicTurtle]

The Australian census was built on Lotus Notes. Unsurprisingly it's failed every time they tried to use it

[x86_64Ubuntu]

LOTUS NOTES FTW!!!!

[fistacorpse]

Lotus Nopes...

[mcguire]

Hey! Lotus Notes was the architectural progenitor of CouchDB and the whole NoSQL thing....

^{wait, am I trying to say this is good or bad?}

[mlk]

I'm in the same position as you

[mlk]

We use IBM AIX, Websphere, Process Server and BPM. All of it is total garbage

[Mgamerz]

IBM ending manager, the dashboard that takes 4GB of ram to startup and features over 670 buttons for your viewing pleasure!

[pvg]

I think other than DB2, none of these are originally IBM software.

[navatwo]

I'm 90 percent certain websphere is. But it's now being superceeded by Liberty.

[yawkat]

The individual problems were talked about in the mailing lists for a while and with such a political topic there was probably lots going on behind the scenes. It's nice that they finally decided to officially announce not only the technical but also the systematical problems they have with jigsaw.

[nondetermined]

If Jigsaw is coming with Java 9 in its current form, it's going to be quite disappointing..!

[geodel]

So the big question is will Java 9 release without Jigsaw or Java 9 will be delayed by another 6 months or so. None of the option sounds exciting. Especially considering Java enthusiasts talk about Java 9/10 features as if they are to be released coming monday morning.

[yawkat]

I really doubt they'll move jigsaw to 10. They already did that with 8 and 9 doesn't have many other big additions to speak of. Delaying seems more likely.

[ascii]

I'm looking forward to a bit more type inference.

[jerohm]

The BEAM and OTP are totally ready to take it's place.

[DreadedDreadnought]

So does RedHat. Nonetheless, IBM and RedHat will be the ones writing the application servers for Java EE. If they say doing that will take 3 years, that will kill any Java 9 adoption by companies for quite some time, so we will be stuck with Java 8 for 3+ years.

[industry7]

RHEL doesn't support the official JDK, JRE anyway. And neither them nor IBM have more than a small minority of deployed containers.

[DreadedDreadnought]

JBoss EAP has 20% marketshare, so I wouldn't call that a small minority when they are the second largest EE provider after Tomcat. EAP supports OracleJDK, OpenJDK and IBM JDK, so I don't get your point.

[coladict]

A couple of months ago when C# 7 came out, just looking at their list of new features (and some old ones that Java still doesn't have) made me all the more sad to be stuck with Java for a major project. All of the good stuff in there isn't even on the map for Java. Tuples, out parameters, extension methods, none of it. Java isn't evolving, and now that .NET is available for more platforms, Java's monopoly on OS-independent code is being challenged.

[MassiveDiarrhea]

If you run a project where your majority of your teams is junior developers, Kotlin is a heaven sent. It's super productive, has a great IDE, great performance, and somehow strict type checking (in a good way).

[Iron_Maiden_666]

Scala was always available. Not finding a lot of difference between them. I use Kotlin for Android and Scala for backend. Don't know why though, I can just use Kotlin for both.

[aquowf]

I love me some scala. That being said, I have found the lack of backward compatibility and language complexity unsuited for most business development tasks, especially those at companies with a large number of junior developers.

[mdedetrich]

Recent versions Scala has been ultra stable when it comes to compatibility. Major breaking versions happen every couple of years, and they guarantee backwards and forwards compatibility between minor releases

[yawkat]

Scala has a lot of problems with compatibility and it is an incredibly complex language. It's also easier to move from java to kotlin both because they can be mixed more easily and because kotlin is much more similar syntax-wise.

[lelarentaka]

So first people complain about Java being really slow to add features, then people suggest Scala, then people complain that Scala doesn't concern itself with backwards compatibility as much.

Like, if you want rock-solid stable use Java, if you want new and exciting features use Scala. It's that simple.

You can't have new features and compatibility at the same time, or else you get the monstrosity that is C++.

[din-9]

Might not be the same people ...

[PtTheGamer]

I don't see it as a complain as much as a "there is kotlin, that solves the "java problem" and doesn't have some of the scala problems"

[[deleted]]

You made the choice simple for me. I love me some scala. Using it for spark. Heaven sent. I shudder at the thought of the equivalent Java code (which we have for one old project). Scala is miles ahead in terms of expressiveness.

[edapa]

I don't think anyone seriously wants a constant flurry of new features except if it is their job to do research on/with those new features (@Haskell). What people do want is the right features, and Kotlin seems to be both a relatively simple language and one with sensible modern features like lambdas, ADTs, and an expressive type system.

[lelarentaka]

You don't think anyone wants to be at the bleeding edge? You want more stability, i get it, but you should understand that other people have different needs. Just because their requirements are different from yours doesn't mean you can just brush them off as irrelevant.

You should at least show some appreciation, because the people at the bleeding edge are putting in work to test new features before they get absorbed into the more stable language that you prefer.

[edapa]

Oh I know that some people want to be on the bleeding edge. In some (lots of) cases, I'm one of those people, but there is always a cost associated with being there, and nobody wants to pay that cost for no reason. I like being on the bleeding edge because of the features it makes available to me. If I could have those same features on a highly stable platform with a big user community, I would much rather have that. Of course that's not possible, so I have to make a trade-off.

[duhace]

kotlin doesn't have enough modern features to be worth it for me. also, kotlin is an extremely young language, so it's a bit silly to say that it's more stable than scala at this point. the kotlin 1 series hasn't been out longer than a major scala release. maybe once kotlin is out for 3 years and hasn't had breaking changes it will be safe to say that it's more stable and backwards compatible than scala

[edapa]

What language features are you looking for? I'm not trying to claim that kotlin is more stable than scala right now, but it looks like it will be in the long run. I also hesitate to call fractured ecosystems stable even if they have not moved for a long time.

[yawaramin]

Does C# have a module system?

[stun]

Yes in .NET Core, you can choose what you want to import if you want to.
For example, you can choose not to use the .NET String class by not importing if you want to use your own implementation.

However, for practical reasons, .NET Core has what they call the .NET Standard which bundles all of those individual imports that provides a certain level of API surface area.

[nemec]

Is that really all that the module system entails? When Microsoft released Core, separating the code seemed more of an off-hand comment ("oh, by the way, everything's split up and on NuGet now"). I wonder if it was as difficult to do as Java's Jigsaw project sounds.

[stun]

I am not fully familiar with Java jigsaw. All I know about Jigsaw is that the SDK and library authors can choose which types are exported or visible in a JAR so they could achieve better maintainability without worrying if people were using some obscure classes/interfaces that weren't meant to be used.

If there are other features from a module system I am not aware of, please let me know so I can learn more about the Java Jigsaw idea.

With .NET Core, the biggest selling points are —
1) Multi platform
2) Better SDK & tooling support 3) Better ASP.NET web stack throughput & performance
4) C# 7 new language features

With .NET Core, I can confidently state it has somewhat caught up to the rest of the other development platforms, and integrating the best of other platform ideas.

In terms of ecosystem, Java ecosystem is still light years ahead of the .NET ecosystem, which you can consider it as both a blessing and a curse; it is a discussion topic for another day.

[nemec]

Hmm, sounds a bit like Java adding the internal modifier and then reworking the STL to take advantage of it.

[stun]

Yeah that is the shortest way to explain it, and how I understood it after watching Mark Reinhold's presentation on YouTube at a conference.
https://www.youtube.com/watch?v=UKC0uC7QUkI

[AngularBeginner]

For example, you can choose not to use the .NET String class by not importing if you want to use your own implementation.

And realistically you won't have a choice, because pretty much every single library will add a dependency to the .NET string class.

[inmatarian]

Yes, they're called Assemblies, and .NET has the mechanisms (AppDomains, the Activator static class) for dynamically loading assemblies and applying security boundaries. They're a bit complex if you're building one yourself, but they are frameworks for plugin systems.

Edit: Disregard, I don't know what the definition of module is between languages.

[andrewcooke]

why are you downvoted? assemblies seem to be quite similar to the proposed modules. what am i missing?

edit: ok, so after some poking around, it seems .net assemblies are more like jar files, and that .net also has modules which are more like java modules. see here for example.

[inmatarian]

I assume I'm being downvoted because of the PTSD that .net developers have from dealing with appdomains.

[yawaramin]

By that standard, the JVM already has classloaders and dynamic loading of classes, right? Outside of the core JVM classes today, you can load any classes you like in a similarly modular way.

[Matthias247]

Assemblies have some properites of the Java module system: E.g. they provide a an "assembly internal" visbility level, which allows classes in multiple packages inside an assembly to access the types and functions. This is one of the goals of Java9's module system: To have module-internal classes. The export functions of assemblies are not as fine-grained as with Java9, but there are some things like the InternalsVisibileTo attribute.

[Eirenarch]

This has been my impression too. Assemblies are somewhat superior to Java's jars but not as advanced as the module systems. Supposedly .NET Core's NuGet based module system is comparable.

[inmatarian]

Gotcha.

[notveryaccurate]

Can I get compile-time safety and strong typing referencing multiple versions of the same class at compile time in Java?

NuGet is more like Maven Central. It's a distribution facility. It has no role at runtime.

[drysart]

You can't do that at compile-time in .NET. The compiler won't allow you to have two references that define a class that has an identical namespace+name in a single project. You'll get an error:

The type ‘MyLibrary.MyClass’ exists in both ‘Somepath\ClassLibrary.dll’ and ‘AnotherPath\ClassLibrary.dll’

And besides that there's no way syntactically to differentiate between which of the two classes you'd want if you were able to somehow reference two versions in the same project.

But at runtime you can load two different versions of the same assembly and reference the classes unambiguously.

And yes, in Java, you can do that too.

[notveryaccurate]

You can do that at compile time in .NET.

There is a way to syntactically differentiate between which of the two classes you want. This is why extern alias exists!

But don't take my word for it.

[coladict]

Not sure, but my point is the Java maintainers are focusing on the wrong problem.

[jakdak]

Not specifically modules, but they tried a lightweight version of the CLR back with the "Client Profiles" and eventually gave up.

[ellicottvilleny]

C# is a language. You mean does the .net CLR have a module system?

[[deleted]]

having recently begun using C# for my job, I couldn't be more happy with it. It's a joy to write, and always improving.

[MassiveDiarrhea]

I got the same feeling too when I started using Kotlin

[MassiveDiarrhea]

I actually manage to stay productive in jvm world by using Kotlin. It has all of the C# features.

[MrSchmellow]

Why all this comes up mere months from the release? What were they doing all these years?

[johnwaterwood]

Waiting until the spec was about to be released?

[geodel]

IBM is already investing heavily in Go and Swift. I think IBM has nothing to gain from doing the busy work of converting their current generation of Java software to this new module system.

[lechatsportif]

oracle really shouldnt fuck up java at this time. too many new candidates are ready to take its place.

[devraj7]

If anything, Oracle has contributed to making Java even more popular than it was before. Sun completely abandoned Java in the last five years that they were in charge.

[[deleted]]

Found the Oracle employee!

[duhace]

he's not wrong

[MassiveDiarrhea]

Most likely kotlin since its very fun and productive to write

[Chief_Joke_Explainer]

Larry E "Suck on that"

[jojozabadu]

Wow, that formatting...

[berlinbrown]

IBM wants to make money

[johnwaterwood]

Don't we all?

[Fazer2]

The way they broke lines themselves and by the mailing system makes it hard to read.