Red Hat And IBM Will Vote Against Java's Next Release (infoworld.com) 57
An anonymous reader quotes InfoWorld:
The next edition of standard Java had been proceeding toward its planned July 27 release after earlier bumps in the road over modularity. But now Red Hat and IBM have opposed the module plan. "JDK 9 might be held up by this," Oracle's Georges Saab, vice president of development for the Java platform, said late Wednesday afternoon. "As is the case for all major Java SE releases, feedback from the Java Community Process may affect the timeline..."
Red Hat's Scott Stark, vice president of architecture for the company's JBoss group, expressed a number of concerns about how applications would work with the module system and its potential impact on the planned Java Enterprise Edition 9. Stark also said the module system, which is featured in Java Specification Request 376 and Project Jigsaw, could result in two worlds of Java: one for Jigsaw and one for everything else, including Java SE classloaders and OSGI. Stark's analysis received input from others in the Java community, including Sonatype.
"The result will be a weakened Java ecosystem at a time when rapid change is occurring in the server space with increasing use of languages like Go," Stark wrote, also predicting major challenges for applications dealing with services and reflection. His critique adds that "In some cases the implementation...contradicts years of modular application deployment best practices that are already commonly employed by the ecosystem as a whole." And he ultimately concludes that this effort to modularize Java has limitations which "almost certainly prevent the possibility of Java EE 9 from being based on Jigsaw, as to do so would require existing Java EE vendors to completely throw out compatibility, interoperability, and feature parity with past versions of the Java EE specification."
Red Hat's Scott Stark, vice president of architecture for the company's JBoss group, expressed a number of concerns about how applications would work with the module system and its potential impact on the planned Java Enterprise Edition 9. Stark also said the module system, which is featured in Java Specification Request 376 and Project Jigsaw, could result in two worlds of Java: one for Jigsaw and one for everything else, including Java SE classloaders and OSGI. Stark's analysis received input from others in the Java community, including Sonatype.
"The result will be a weakened Java ecosystem at a time when rapid change is occurring in the server space with increasing use of languages like Go," Stark wrote, also predicting major challenges for applications dealing with services and reflection. His critique adds that "In some cases the implementation...contradicts years of modular application deployment best practices that are already commonly employed by the ecosystem as a whole." And he ultimately concludes that this effort to modularize Java has limitations which "almost certainly prevent the possibility of Java EE 9 from being based on Jigsaw, as to do so would require existing Java EE vendors to completely throw out compatibility, interoperability, and feature parity with past versions of the Java EE specification."
Excellent! (Score:1)
Honestly, the whole Jigsaw thing, while interesting, didn't require all the internal replumbing they're doing. As for J9EE not running on Jigsaw, great! Does anyone still use EE for anything new? Pieces of it, sure, but EE as a whole? Who'd want that?
To be honest, simplifying the Java system into a solid core is great, but Jigsaw seems to break far too many things.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re:me too! (Score:5, Funny)
I vote against Java as well. Can we vote that it gets deleted from existence? That's my vote.
Java can't be deleted. Instead, you have to try to break all strong references to it, then hope that it gets garbage collected.
Java... sucks... (Score:2, Interesting)
I would love for older versions of Java to go away. The majority of the 80,000+ workstations I'm responsible for has the current version of Java installed. Some of these workstations have legacy applications that requires an older version of Java 6 by itself or with the current Java installed. Accidentally deleting an older version of Java can cause a blizzard of emails. Whenever I come across an older version of Java, I create a ticket for the local tech to evaluate.
And then there is Adobe Flash...
Re: (Score:3)
Technically speaking nothing what so ever requires older versions of anything in the digital world. More accurately, they have no economic desire to invest in port programs and converting data in order to make the transition. The cost is large and problems will occur but it most definitely is not impossible, or even all that difficult, just quite expensive. What I have learned, is the longer you put it off, the more expensive it becomes, flip side early conversions often lead to choosing the wrong direction
Re: (Score:3)
In conjunction those two issues keep legacy stuff hanging on far longer than they should.
The only legacy applications that get off the network in a hurry are those tied to specific version of Windows Server at end of life. Server owners have 18 months to move their server to a current image of Windows Server. If they don't do so six months after the deadline, the server team will yank their physical server out of the data center and drop it on their desk. By drop I mean two feet above the desk and a 50/50 chance that the server might not work again.
Re: (Score:3)
Known as "bit-rot" due to third party API's. Write your own software layers and there is no problem. Use a third-party API, and suddenly those simple menu widgets that you used happily for many years, suddenly disappear or get reformurgulated into some new document design pattern requiring base, derived parent and children classes with additional callback event handlers, simply because the developers thought those old widgets didn't provide enough flexibility. They could of course provided an emulation libr
Re: (Score:1)
Are you even aware that JAVA importance is NOT because of desktop apps but server ones - where its whole different world?
Are you aware that early Java server applications often require a Java front end on the client side?
Its so silly to see people bashing Java by people who never used/developer any java server based software (like your bank or hospital or goverment or insurance company do)...
I've learned every flavor of Java while getting my computer programming degree at the community college. I think we had a chapter or two on Apache Tomcat 5. After I graduated with a 4.0 GPA, I went into IT Support and never used Java again (I prefer Python). Java is just another checkbox on a long list of applications that I need to keep secure on 80,000+ workstations.
Re: (Score:2)
"Are you aware that early Java server applications often require a Java front end on the client side?"
Yes. We have a server whose client UI requires installing some archaic version of Java and Firefox on any machine that accesses it because... some reason or other that I can't remember offhand. A newer browser with a newer Java plugin won't run on it, and there's no budget for building a new UI so long as there's a simple workaround.
Re: (Score:2)
[...] archaic version of Java and Firefox on any machine [...]
That configuration wouldn't fly at my job. Internet Explorer is the only approved web browser and locked down so tight that it's practically broken for general browsing. The legacy applications that I support are full Java clients that don't require a browser.
A newer browser with a newer Java plugin won't run on it [...]
New versions of web browsers are phasing out support of the Java plugin. I have to use the mobile app to deposit checks since the bank for my business checking account haven't gotten the memo that check deposits on the website stopped working.
Abort Java! (Score:2)
People need to stop using Java for everything, not because of personal preference but because of Oracle's incessant bullshit. Honestly, if OpenJDK hadn't originated from SUN then Java programmers would shit out of luck as Oracle would have had to crush them just to get to Google.
Stop supporting Oracle's eternal war and move to different languages!
Re: (Score:2)
The choice of high level language is more to avoid the debugging time having to deal with pointers, and matching memory allocation and deallocation. Even with C++, the use of smart pointers is preferred because then time doesn't have to be spent looking for memory leaks. To make things even more complex, these can differ from OS to OS and even compiler version. Plus they don't want to be dominated by Microsoft at any cost.
Re: (Score:2)
"Even with C++, the use of smart pointers is preferred because then time doesn't have to be spent looking for memory leaks"
People who believe that tend to be the same people who write Java code with horrendous memory leaks. Or with essential objects that get garbage collected because they forgot to keep a pointer to them.
You know the saying... (Score:3, Funny)
"JDK 9 might be held up by this,"
Write once, wait everywhere. :-)
[ Disclaimer: I like Java. ]
Re: (Score:3)
[ Disclaimer: I like Java. ]
Your Smalltalk block says otherwise!
Re: (Score:2)
[ Disclaimer: I like Java. ]
Your Smalltalk block says otherwise!
I've also used LISP and Prolog, but never Smalltalk.
too big to ...move fast? (Score:4, Insightful)
Re: (Score:2, Troll)
And still doesn't come anywhere close to C or C++.
Re: (Score:3, Interesting)
http://www.androidauthority.co... [androidauthority.com]
While C is faster in some cases, java is faster in other cases starting with Android 6.0.
Personally, I think Java is the way to go until we invent another language which is clearly better and can easily and automatically be converted to from Java.
I saw the value of Java when it first came out. And I've seen many other languages come and go since which are less mature and frequently lose support after you commit to them. I know of more than one multi-million dollar applicat
Re: (Score:1)
Fuck dynamic typing and fuck anyone that still advocates for it.
Re: (Score:1)
There is. It is called c#.
Unfortunately is heavily tied to win32 but MS is starting to move core .NET to opensource and Mono already has some cloned opensource wise.
C# is what java should have been or would have turned into if it were not for Sun mismanagement last decade.
Re: (Score:1)
After what microsoft did to visual basic, I would never trust them with an enterprise/mission critical application I intended to use long term.
http://www.eweek.com/developme... [eweek.com]
I worked in a shop which had large VB applications and they were told "convert or die". As if they could just print money and whip up a bunch of programmers to convert the applications. (It looks like microsoft eventually relented a bit but they didn't want to and I still don't trust them.)
Car manufacturers support their car
Re: (Score:2)
Hey, we still have a product written in VB6. We inherited it from a company we bought years ago, and the main organization that still uses it sends us money now and again to add new features.
I don't know what hoops the developers who work on it have to jump through to get it to build and run on modern Windows, though. I think they do the development on VMs running XP.
Re: (Score:2)
http://www.androidauthority.co... [androidauthority.com]
While C is faster in some cases, java is faster in other cases starting with Android 6.0.
Nothing in the article you linked supports your claim properly. There's not even a guarantee that the math program using FP that supposedly "won" in Java was identical in semantics given the different treatment of floats in C and in Java because we don't know what it did and what options were used for the C version.
Benchmarking (Score:2)
While C is faster in some cases, java is faster in other cases starting with Android 6.0.
As a falsehood this is fairly outrageous. Real benchmarks are available here. [debian.org]
Java must be considered good in its niche. Despite that, it's apparently necessary for you and others to write apologetics for it. As a language, it's verbose and unlovely. Worse than that, it's boring. Which of course makes it all the more suited for its purpose: most applications are boring. Boring code does what it's supposed to do in ways that are easy to understand.
Programming has two inheritances. The first is the theoretical
Re: (Score:2)
I tend to prefer reduce(+) rather than sum(). The Java code example was taken from Stack Overflow. Perhaps you should add your answer there. However, while I appreciate that it is possible in this instance to write a relatively concise version of the code in question in Java, the point does not generalize: Java is verbose. I'm sorry you have trouble with that fact.
As it happens, I'm forgetting that in Ruby zero isn't falsy like in Javascript. The code should actually be:
Re: (Score:2)
Personally, I think Java is the way to go until we invent another language which is clearly better and can easily and automatically be converted to from Java.
Or you can just use Kotlin [kotlinlang.org]: modern syntax, lightweight (uses the JVM libs instead of inventing their own), pragmatic mix of procedural and functional, excellent interop with compiled Java, production ready (created and used by JetBrains for tools like their Idea IDE).
Re: (Score:1)
I've been hearing comments like that for 35 years since I was programming in sweet 16 on the apple.
Kotlin has no jobs compared to mainstream languages and so it has no installed base. And so when a company needs to find a Kotlin programmer, it will take longer and they'll have less ability to judge the skill level of a Kotlin (or Scala) programmer.
At one shop a friend worked at it was "D". Never heard of it. Guy there was a big fanatic of the "D" language. And he helped found the company so he had some
Re: (Score:2)
It's about time for Java to die. The Oracle experiment was a failure.
For that matter, it's about time for Oracle to die. And Oracle trollmod employees can also FOAD.
I have java but don't let it into my web browser (Score:3)
Wildcard Version Requirement Numbers Are Evil (Score:1)
IBM and Red Hat are correct:
The project seems to have slipped backwards, as this slide from 2014 indicates the implementation of version requirements. [slidesharecdn.com]
Whereas the 2016 documentation stipulates:
"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 State of the Module System [java.net]
Anything less than Node's package requirements is going to be useless. There should be absolutely no wildcards in major version numbers, with warnings in medium. They are the curse of Node!
The bigger picture... (Score:2)
I've not looked into Jigsaw / JSR 376 in any detail, so I can't comment on it's virtues or problems.
But I wonder if the bigger picture isn't being missed here - part of the reason why other languages are taking off is a lack of progress with Java. Although, I've always seen the calls for modularity a bit misguided - the classloader provides separation within a JVM when it is required. An "interpreted" mode (e.g. watches .java files for changes, and compiles / replaces the class behind the scenes) would be a
Hmm, looks like they might be rushing it (Score:2)
My Vote (Score:1)