Kind of have to agree with RedHat and IBM here. Jigsaw was designed specifically for modularising the JDK. Trying to make it an application-tier modularisation system is a square peg in a round hole, particularly when it completely ignores the work done in both SE (Guice etc.) and EE (OSGi etc.) lands.
Oracle has hit out at IBM and Red Hat Middleware for their continued opposition to its proposed plan to make Java modular. IBM has suggested it will vote against the JPMS JSR that Reinhold leads – JSR 376. The result for the Community vote on JPMS is due to be announced on June 8. Mark Reinhold, Oracle’s Java Platform chief, …
Monday 8th May 2017 15:29 GMT Anonymous Coward
I think that some of the reasons that Oraclewant to do modularisation their way are:
1. A custom JRE can be built with only the required JRE libs, to save significant of disk space, so the builder tool must somehow be told the application library dependencies to do this.
2. They want better security, reliability, and possibly speed than old frameworks like OSGi, which allows risky concurrent use of different versions of a library.
3. They want to do better JIT optimisations.
4. They may want to make better use of RAM for metadata.
5. They saw previous IBM contributed code in the JRE, and the IBM sponsored Eclipse IDE, and SWT, just saying...
However, if Oracle plans to stop allowing custom class loaders and does not provide replacement dynamic extension support, they deserve a revolt!
Monday 8th May 2017 17:27 GMT sorry, what?
OSGi and "risky concurrent use of different versions of a library"
I personally saw this as one of the biggest benefits of OSGi - different apps/modules/libraries could rely on the code-level API and implementation of a third-party module/library without fear that some other co-hosted app/module/library needed a different version of that same module/library that would break some functionality. As long as you correctly encapsulated that dependency this worked a treat.
Wednesday 10th May 2017 04:54 GMT wodencafe
"OSGi, which allows risky concurrent use of different versions of a library."
An OSGi bundle specifies what dependency it uses, down to its version / range, so one bundle is not using multiple versions of the same dependency at the same time, as your post is suggesting.
Each OSGi bundle gets its own Class Loader, there is no "cross contamination" between them.
Monday 8th May 2017 11:58 GMT Justicesays
One party state model?
"A vote against the JSR, Reinhold warned here, would delay completion of the next version of Java and be a “vote against the Java Community Process itself.”"
Can someone explain this Community Process? As it seems like Oracles idea of this process is that they propose stuff, and people have to "vote" to agree with them (or else).
Monday 8th May 2017 12:15 GMT jackharbringer
In Soviet Russia, the App Server runs you
"The Linux spinner is a keen user of Java, which runs on its JBoss middleware."
I think I know what is meant here - that JavaEE applications run on JBoss. But as stated this seems the wrong way around, as JBoss itself runs on "Java".
As to the actual beef. ¯\_(ツ)_/¯ A modular Java is certainly welcome and might be able to keep it going for a bit longer. But, at least for my work with microservices, Java is a whole lot of bloat for not a lot of advantages and just making it more modular won't save it from being the new Cobol.
Monday 8th May 2017 13:02 GMT Spaceman Spiff
Java is an abomination. Not as a programming language per se, but as a systems programming language! It was never intended for the uses we find it in today, and we all suffer for it. I got my first Java compiler directly from the inventor, James Gosling, back in 1995 when we both gave invited papers at the IEEE manufacturing engineering conference in Boston. His intention for the language at the time was to build applets for web browsers. The language wasn't officially released by Sun until about 5 years later.
Monday 8th May 2017 14:02 GMT Anonymous Coward
"Java is an abomination. Not as a programming language per se, but as a systems programming language! "
You wouldn't use java to do systems programming in the first place. If you want to get down and dirty with the OS you'll be reaching for your nearest C compiler.
Java as an application programming language OTOH has its merits tho memory usage certainly isn't one of them. The only real beef I have with java (speaking as a C++ developer) is that it seems to me the wheel has been reinvented far too many times in the libraries. Just how many - for example - graphics APIs or container classes does a language need? There's a tipping point where having too many variations on a theme on offer actually makes life more difficult for coders, not less, since no one can be expected to know all of them yet they'll probably have to maintain code that uses them at some point or have to choose one for a green field project and spend ages trying to grok the differences between them for the best option.
Monday 8th May 2017 17:41 GMT sorry, what?
Too many options...
@boltar, how do you get innovation but by iteration, speculation and plagiarism? And, by the way, this is not at all special to Java. Look at Linux and how many different package management systems there are, or graphics kernels, or image manipulation packages or... you get the idea.
A programming language that prevents you from doing this is going to keep you from doing what you want to do at some point.
Monday 8th May 2017 18:15 GMT bazza
Re: Too many options...
"@boltar, how do you get innovation but by iteration, speculation and plagiarism?"
Er, proper design and thought?
Look at the Altivec extension to PowerPC. Ok, so that's nothing to do with Java, but it's a good example of what you can get right with careful thought. Motorola (for it was they, back then) sat down, thought long and hard about what a decent SIMD unit for a CPU should look like, and built it. The result, Altivec, was stunningly good for the time, and didn't need any changes to be useful to a wide variety of applications, and is still largely the same even now in IBM's Power chips.
Iteration and speculation is what Intel did. First, there was MMX. Then SSE. Then SSE2, 3, 4, 4.2, and now AVX256 and AVX512. The first few of those were rubbish, and it's comparatively recently that they finally, eventually gave up and put an FMA instruction in to make it actually half-decent.
The result? Loads of image / signal processing software got written for PowerPC very quickly. Mac versions of Photoshop used it big time. It was worth writing for. Whereas the use of SSEWhatever on Intel has been far slower to get going, because until quite recently everyone knew that the majority of hardware out there wouldn't have a version of SSE new enough to be worth using.
Ok, so the design and thought might be iterative, but foisting part formed speculative ideas out there on to the masses who have the job of making use of the damned thing really doesn't help. The software world is of course always going to be iterative to some extent, but for something as major as Java modularity it would be far better if it was done Right First Time (tm).
As for Linux, the plethora of package management systems is in my view a real embarassment. The lowest common denominator is still compile-yourself-tarballs-and-sort-the-dependencies-yourself. And they keep inventing more. Personally speaking I think FreeBSD is far better organised in this regard.
Tuesday 9th May 2017 11:41 GMT Anonymous Coward
Re: Too many options...
"As for Linux, the plethora of package management systems is in my view a real embarassment."
It's not a problem from a user's point of view though, because you just use whatever your distro uses. I've had no problem installing software on Red Hat, SUSE, Debian and even on less well known distros like Puppy and Damn Small Linux. So long as the distro maintainers have done a proper job of documentation, package management is pretty easy to pick up. (One or two distros do make things a little harder (e.g. Gentoo) but it's for a good reason:- user customisation.)
The more important difference between distros isn't the package format, it's whether version X.X is available of package Y in the repository for your distro.
Monday 8th May 2017 19:36 GMT Notas Badoff
Re: Too many options...
@sorry, what? "@boltar, how do you get innovation but by iteration, speculation and plagiarism?"
Java did so spectacularly badly at this I reference them as a badly managed language.
"iteration, speculation" was thoroughly used for multiple versions as Sun said "let a hundred regexen bloom!" Wasn't it Java 5 or was it Java 6 that *finally* 'introduced' regex support? After half the population had bought one of hundreds of expensive badly implemented commercial packages, with the other half still laboriously hand-coding text parsing routines contributing to a large part of the early security flaws Java apps were(?) famous for.
"plagiarism" is a fabulously good thing when it improves your particular tool of choice. After hemming and hawing for years they finally ended up approving a basic PCRE engine. Frabjous fuck. It was a toy language until they recognized basic interfacing with the external world.
I'm remembering/thinking the community process was ideally started to identify problems outside Sun's myopia. Ah, regular expressions in JSR 59 in Java 1.4, the 5th Java release, and first under the community process.
Monday 8th May 2017 22:18 GMT Anonymous Coward
Tuesday 9th May 2017 08:18 GMT Anonymous Coward
"The problem is not that you reinvent the wheel, but rather that you use generics for stuff, and then a wheel factory, and you just needed a wheel."
Of course the irony there is java doesn't technically need generics anyway since everything is inherited from Object. They were put in to "tidy up" the language. I'm sure they help with finding errors at compile time but they sure as hell don't help with syntatic readability.
Monday 8th May 2017 17:35 GMT sorry, what?
Uh, I don't think so
@Spaceman Spiff, Java 1.0.2 was released in 1996; I remember an ADI (an IBM internal developer conference thing back in the day) in 1997 where a speaker presented on the use of Java on the server side using the servlet API and supporting runtime. I'm not at all sure I understand where you're coming from with what you've reported here.
Monday 29th May 2017 22:13 GMT JMcL
"The language wasn't officially released by Sun until about 5 years later."
I beg to differ - I was writing Servlet components on top of Apache Jserv in 1998 (Java 1.2 I think), your 5 years would leap right into Java 1.3.
On the other hand, Java EE 2 where you had to hand code EJB stubs skeletons and all that malarky (unless you had deep pockets for Rational Rose), now that was a "life's too short" style abomination
Monday 8th May 2017 15:36 GMT Anonymous Coward
Now who would I trust here....?
On the one hand we have Oracle and on the other hand, we have Satan, Lord of the Nether Regions, killer and destroyer, self professed lier and spoiler of dreams...
Difficult but I have to go with Satan as the most trustworthy and person I would prefer to deal with.
Satan only normally takes your first born, Oracle on the other hand takes everything you had AND sets lawyers on you.
Whilst you have to have a long spoon to sup with the devil, there isn't a spoon long enough to sup with Larry Ellison. Also Lucifer does stick to his contracts, diabolical they may, Oracle will happily rip them up if its to their advantage,
So in hindsight, dealing the devil is easier, simpler and less soul destroying than Oracle.
Monday 8th May 2017 16:30 GMT bombastic bob
change for the sake of change?
I have to wonder whether Oracle's plan for Java "modularity" is JUST ANOTHER CHANGE FOR THE SAKE OF CHANGE, like so many OTHER things have been in the last decade...
In other words, maybe THEIR millenials are saying "It's OUR turn now"...
I'll keep using OpenJDK / OpenJRE and whatever ends up as part of Android in the mean time.