Alright...

Alright. So since java 9 came out a few days ago I was checking out the system requirements to install the different versions of Java. It turns out you can't install jdk 8 on Windows versions older than Vista SP 2. They had dropped support for Windows XP. It also can't be installed on Ubuntu systems older than Ubuntu 12.04, while Java 7 is supported by 10.04.

Java 9 is only supported by Windows 10, 8.x or 7 and Ubuntu 16.04 or 17.04.

Is it possible to understand why they do like this? Why remove the support for old systems? What's new in Java 8? Most people would say the big new thing are streams and lambdas which allows for a more functional-oriented approach to programming. Streams can be executed in parallel so the underlying operative have to be able to execute in threads or processes. Surely, parallel execution in threads must have been in Ubuntu since version 4. Most things in Java should in principle be able to be run on a 50's computer hardware.

Why drop the support for old system? I mean I have an updated one, and reasonable new hardware, but I don't understand what in the Java language changed so that Ubuntu 10.04 couldn't be used anymore for Java 8. I've seen many talks by oracle and they always go on about how they shouldn't break things and have to be backwards compatible. This doesn't fit in with that. It just feels like part of the industry-wide epidemic that you are supposed to upgrade any time you can, even if stuff is moving along great.

To me, it seems like if a developer is happy with an Ubuntu 12.04 installation, he should be able to program java 9 programs with it. Maybe he is maintaining an old code base and it is going to be run an old low spec system that can't run newer operating systems. Why shouldn't we be able to use modern programming techniques to compile code for legacy systems?

No one cares, Rajeesh

> Why they do like this
Because obviously there were differences between Vista and newer Windows' that required reimplementation of presumably srs parts of Java.

And I guess they didn't want to fund maintenance against something Microsoft itself no longer maintains.

Microsoft could have decided to not fuck this up, rather than everyone who makes software dealing with it.

> To me, it seems like if a developer is happy with an Ubuntu 12.04 installation, he should be able to program java 9 programs with it.
You have access to OpenJDK and so on, make it so if you want. Or hire a team to make this possible.

POO

They also have a requirement that Java needs a processor of 266 Mhz or faster. Why? Java isn't a real time system. There is no guarantee that a method in a specific class should execute within a certain time so there is no need to put this restrain on the developers hardware

>. It just feels like part of the industry-wide epidemic that you are supposed to upgrade any time you can, even if stuff is moving along great.
Yes, there are business reasons behind this.
Computers and software are actually difficult as fuck.

So it's a matter of not having enough resources to expend on solutions that merely serve a fraction of the "running-obsolete-systems" audience when it got difficult for one or another reason in the ecosystem. Unless that small "running-obsolete-systems" audience pays srs dough, in which case you can almost be certain that SOMEONE will serve your needs.

Apart from that, at the root of the ecosystem near hardware and all that, only new releases even keep funding businesses. If that didn't happen you'd run out of spare parts soon, plus you'd never get better hardware.

I could kind of understand why they would do this for Windows, since windows systems have been known to have security holes in them. But with Linux systems I see no need why they would drop old systems. It seems like more of a hassle just forcing everybody to just buy newer hardware than a question of not implementing stuff. They have the source code for the jdk. The same source code that compiles for Ubuntu 12.04 most probably compiles for Ubuntu 10.04.

That's a big no one.

Does this mean Oracle is in the pockets of the hardware manufacturers? Forcing people to get newer operating systems and therefor ultimately forcing them to buy new hardware?

I see no reason why Oracle wouldn't just let people compile java 9 on old hardware. They have nothing to lose from it. The "running-obsolete-systems" audience is actually usually pretty stable. There are banks and telephone systems that have been running without any major upgrades for decades. It is when you change things and move to Windows 10 and switch hardware the unpredictable things happen

> most probably
No, unless Ubuntu just got lazy about supporting their older release (in which case I assume some other distro might have a package or an OpenJDK adaptation or whatever), it probably is the case that something does NOT work,

It's just more likely that nobody preferred funding developing and publish a fix, they either kept such a thing to themselves or -more likely- simply updated their Ubuntu or whatever.

I suggest you do the same. Even if you have to adapt a good bunch of hardware that is STILL orders of magnitude cheaper than running a srs software project like keeping a JDK backported.

When they talk about backwards compatibility, they mean backwards compatibility with older libraries written using older versions of java. There is no reason to support older windows versions for which microsoft has dropped support and which are therefore insecure. I don't know much about ubuntu versions, so I can't comment on that.

>62846378
>Does this mean Oracle is in the pockets of the hardware manufacturers?
Not necessarily the case at all. They're just not going to be the ones that fund the expense for compensating for whatever people lower in the stack -hardware manufacturers, OS developers and so on.

They'll just keep what's current or reasonably easy to maintain from the older stuff supported and that's about it. They aren't going to be eager to write massive compatibility layers or multiple implementations so that their stuff works with both the old and new things.

If something older is becoming a pain to support, it'll not be supported anymore. There are no new customers that way.

I'm sure they would like to avoid having to do things to support new Microsoft OS or whatever, but companies don't give up their present and future that easily. Its just expected of a serious company anyone wants to deal with that they at least support current devices and OS' that, you know, you can actually buy on the market,

>When they talk about backwards compatibility, they mean backwards compatibility with older libraries written using older versions of java. There is no reason to support older windows versions for which microsoft has dropped support and which are therefore insecure

This kind of ties in to what I was saying. I reject the notion that a system is insecure because somebody stopped releasing updates for it. A system is either secure or insecure. If microsoft stopped releasing updates for Windows XP and it now is insecure it probably was insecure the whole time.

If you have an old Linux system that you know is secure or at least trust it doesn't become unsecure because somebody stopped releasing updates for it. In fact, it is when you update it its security status becomes unknown.

>I reject the notion that a system is insecure because somebody stopped releasing updates for it.
In the real world, this results in the difference of discovered security flaws not being fixed. Vs them being fixed.

And in the real world, you just have a steady trickle of such security flaws that come out over time. [These systems are complex as fuck and their flaws become apparent and known over MANY DECADES.]

So yea, it's just basically always a difference. You can't "refuse" notions, it's just very quickly insecure in the sense that your adversaries know where the flaws is.

Of course, to an all-knowing being it'd have been insecure all along -maybe every last cipher and every last MB of software and every piece of hardware is exploitable from the other side of the universe-, but since we're not dealing with those as adversaries, it's the other thing that is relevant.

>Is it possible to understand why they do like this?
Yes, if you read the release notes and follow the development process you have a high chance of actually understanding the design goals and why certain decisions for the implementation were made, retard.

fuck off you idealistic piece of crap. nobody takes you seriously until you've actually been in the shit

>I reject the notion that a system is insecure because somebody stopped releasing updates for it.
>A system is either secure or insecure.
That's where you're wrong. There simply is no such thing as a secure system. Virtually any system in use has a number of unknown vulnerabilities, the difference between supported and unsupported systems is that for supported systems, an update that fixes the security issue will soon become available, while the bug will be left unfixed on unsupported systems. This is a problem, because the security issue will eventually become publicly accessible knowledge, and then anyone can write a program that exploits it. Windows XP is not a secure OS just because it has existed for such a long time, and hackers most likely put extra effort into discovering new exploits for it after MS dropped support, because any new vulnerability they discovered would never be fixed, and it would always be there for them to exploit.

I mean u cant compete with the population of india ofc

Systems are secure if they are old and simple. I'd like you to point out the security flaw in One Time Pad encryption. I can't be broken unless you resort to things like "huhu, I could beat the guy until he gives me his keys."

I get your point that newer systems have less known security holes than old unpathced ones. But if there is a system that is simple enough, interact with the outside world in limited ways and isn't changed every 6 months it can actually be said to be more robust

>Asking yourself why a 16 year old OS is no longer supported

Granted, XP was great in comparison to 98, ME, Vista and 8, but it's goddamn OLD

If they were adding disrutive changes to the language in every other release I would agree. But mostly the just add a few classes like ConcurrentHashMap, implement a few more methods in the existing classes in the standard library and go along. Most of this is written in java itself.

In particular since this is all run in a protective virtual machine called the jvm, that they have said they are extremely conservative to change, since other languages like Scala and JRuby is run on then and they don't wasn't to mess up for them.

If they decided to suddenly add primitive support for quantum bits, 128 bit integers or decide to remove the underlying jvm layer and make the code native I could totally understand if they dropped old hardware OS support.

Lmao the security flaw isn't in the protocols, but in their implementation. Have you heard this thing called heartbleed? If you'd been running a version of linux for which support was dropped before the vulnerability was discovered, people would be free to read random bytes from your server's memory to this day. And it took like two fucking years to discover it, so you can't say that simple systems are necessarily secure. The shellshock bug, although arguably less exploitable, took more than 20 fucking years to discover, so your old and simple really doesn't equal secure.
When you decide to use an unsupported system, you essentially bet all your users' data on there being no yet undiscovered security holes in your system, and I hope I don't have to explain why that is a dumb, and even unethical thing to do.

Nah.. XP i can kind of understand cause it was Microsoft and ridden with holes even when it was being patched. But I have a harder time figuring out why Ubuntu 10.4 can run java 7 but not java 8. They didn't change THAT much.
Or that java 9 who's new feature basically just allows your packages to be put in folders and they changed the garbage collector to another one that already worked can only be run a year or so Linux system.

Why would you need to compile newer versions of java in old systems? You only need them if you
a) need something from the new libraries
b) need to make a new module or some shit in the system

Old, ancillary systems generally don't need that stuff, they keep running until a really bad security flaw is discovered or they are unable to interface with newer systems (or the time/money cost to maintain becomes prohibitive because nobody can/wants to maintain it). And generally in those cases, the need arises to simply port the whole fucking mess to a newer version or remake the mess in another platform/system/language/framework/whatever

change may seem seamless to you,but I can assure you maintaining some 10 year old shit is hard as balls, when everything you develop ALSO has to be compatible with the 10 year old shit. It's incredibly time consuming and after a while it's apparent that "it's not worth it". It's not just saying "yeah we support that OS", Java is a product (albeit a free one) and therefore you gotta test 100% of it on the OS you say it's compatible with. That's another time consuming task, and when you have 10 different OSs instead of 3 or 4 it's even worse.

Imagine you have a code you're working on with an ongoing client. The client is not interested in technology at and and just want it to work. The system needs to be changed every now and then because the organization is growing etc. But the client is really not interested in changing the hardware or the systems this thing interact with. Think a telephone switch or something. Something where it's gonna be really expensive to change out the hardware this is run on.

Then it would make all sense in the world to be able to use modern programming paradigms to rewrite/update his old code. Most guides when you search something are going to assume newer users of java so if the programmer has a problem he finds solutions easier using the newer jdk.

Also, even if it's not gonna run on legacy systems, you could just let people compile on an old computer if they want and run it at their clients hardware. Compiling is literally just a text-to-jar mapping and there's no reason there should be any fancy requirements.