5 ms·

The bytecode stability is only half of it. The other half the stability of the standard library, before Java 9 it was very rare to remove anything from it. I re

by cesarb 6y ago

The bytecode stability is only half of it. The other half the stability of the standard library, before Java 9 it was very rare to remove anything from it. I recall things like a RCS or SCCS revision tag which was accidentally put in a public static field, and it was kept frozen (with the same value) as a public static field just in case someone was using it for some bizarre reason. Starting with Java 9 things changed, many things were removed (starting with all of J2EE) and other things are going to be removed soon. This is one of the reasons why it takes so long for projects to migrate from Java 8 to Java 9 and beyond.

pjmlp 6y ago
Back in 2018 I had a client with Java 1.4 in production, some never migrate, even if there aren't hurdles.
Quekid5 6y ago
> This is one of the reasons why it takes so long for projects to migrate from Java 8 to Java 9 and beyond. EDIT: Oh, just realized... it's probably a misunderstanding on my part. "Java 8 to (Java 9 and beyond)" is the intended reading, probably. My bad. ----------- DO NOT READ BEYOND THIS POINT ---------- Maybe it's just a phrasing issue, but... The Java 8 -> Java 9 (or 11, in practice) transition was special in a few ways (modules, mainly), but I don't see why any future transition should be quite as disruptive? Do you have anything concrete in mind, because if you do, I'd like to know about it!
- alblue 6y ago
  No, it's likely that it won't be quite as disruptive in the future. There were a few backward incompatible changes with modularisation (in order to break module cycles) but the bigger disruptive changes were moves away from sun.misc.* packages which should never have been used by production code (but which often were, because speed). Fortunately Java took a middle-of-the-road approach; it didn't quite get rid of as many things as it could (Unsafe stayed around in a few ways). Had it all been killed off then the transition would have been more problematic. With Java 17 being the next LTS I don't think there's appetite to break things before then but it's quite possible that Java 18 will really put the hammer down and remove Unsafe for good. That, I think, will be one of the last disruptive things Java does.
vram22 6y ago
Why was J2EE removed? Not been following Java developments for some time, though I did a good amount of real life work on it earlier, and liked it at least some, back then. Also, I thought it was renamed to JEE. Or is that also outdated?
- dtech 6y ago
  It's still available as libraries, just not with the default install
- josefx 6y ago
  Maintenance of it has been moved to the Eclipse foundation and it was renamed to Jakarta EE.
- vips7L 6y ago
  Mainly because it was then tied to the release schedule of the JDK and for EE to compete they need to invovate faster.
- vram22 6y ago
  Thanks for all answers.
ChuckMcM 6y ago
FWIW, I had updated Java to use a capabilities model (before the "SecurityManager" cruft was so rudely shoved into the libraries) that was patterned after Joule (one of the few (if not the only) language that had passed 'red book' security certification). And part of the challenge of building it had been understanding method and class "signatures" which would inform the model. In particular, the challenge was trying to figure out what "side effects" were relevant and which were not[1]. The requirement was to throw IncompatibleClassChangeException when the class had changed and thus the capability was possibly incorrect. We got pretty draconian and went for a "class changes can be "additive" only, so that the capabilities could be forward compatible with new classes. Sadly, politics got in the way of shipping it so I ended up with only a couple of patents and a later Javaworld column out of it and most of work never saw the light of day. [1] For example you might have a File class with a write() method that you wanted to be part of a write capability, but there might also be a update_metadata() method that effectively wrote something to the file so you needed that to be part of the capability, and that method might be looking at static member data of meta data flags, which were also part of the read() capability.
- patrec 6y ago
  I'm quite intrigued to hear that Java might almost have had a sane security model – what was the political problem that killed it? Anything from your work that you'd like to see used in new languages (those patents must have expired now I assume?).
  - ChuckMcM 6y ago
    An influential member of the team didn't understand the code I was checking into the source tree so they deleted it all and added the SecurityManager instead. The manager refused to override that action because "the individual threatened to quit."
    - patrec 6y ago
      How typical was that type of thing? Although on the whole I think Java is better than its reputation, I always thought it a bit underwhelming for the brainpower around at the time; one would kinda assume in addition to yourself people like Guy Steele or Gilad Bracha might also have tried to get a forward looking thing or two in if someone had let them. BTW, the link to your capabilities columns on your home page appears to be be broken: http://www.mcmanis.com/chuck/java/javaworld/index.html http://www.mcmanis.com/chuck/java/javaworld/index.html

by cesarb 6y ago

pjmlp 6y ago

Back in 2018 I had a client with Java 1.4 in production, some never migrate, even if there aren't hurdles.

Quekid5 6y ago

> This is one of the reasons why it takes so long for projects to migrate from Java 8 to Java 9 and beyond. EDIT: Oh, just realized... it's probably a misunderstanding on my part. "Java 8 to (Java 9 and beyond)" is the intended reading, probably. My bad. ----------- DO NOT READ BEYOND THIS POINT ---------- Maybe it's just a phrasing issue, but... The Java 8 -> Java 9 (or 11, in practice) transition was special in a few ways (modules, mainly), but I don't see why any future transition should be quite as disruptive? Do you have anything concrete in mind, because if you do, I'd like to know about it!

alblue 6y ago
No, it's likely that it won't be quite as disruptive in the future. There were a few backward incompatible changes with modularisation (in order to break module cycles) but the bigger disruptive changes were moves away from sun.misc.* packages which should never have been used by production code (but which often were, because speed). Fortunately Java took a middle-of-the-road approach; it didn't quite get rid of as many things as it could (Unsafe stayed around in a few ways). Had it all been killed off then the transition would have been more problematic. With Java 17 being the next LTS I don't think there's appetite to break things before then but it's quite possible that Java 18 will really put the hammer down and remove Unsafe for good. That, I think, will be one of the last disruptive things Java does.

vram22 6y ago

Why was J2EE removed? Not been following Java developments for some time, though I did a good amount of real life work on it earlier, and liked it at least some, back then. Also, I thought it was renamed to JEE. Or is that also outdated?

dtech 6y ago
It's still available as libraries, just not with the default install
josefx 6y ago
Maintenance of it has been moved to the Eclipse foundation and it was renamed to Jakarta EE.
vips7L 6y ago
Mainly because it was then tied to the release schedule of the JDK and for EE to compete they need to invovate faster.
vram22 6y ago
Thanks for all answers.

ChuckMcM 6y ago

FWIW, I had updated Java to use a capabilities model (before the "SecurityManager" cruft was so rudely shoved into the libraries) that was patterned after Joule (one of the few (if not the only) language that had passed 'red book' security certification). And part of the challenge of building it had been understanding method and class "signatures" which would inform the model. In particular, the challenge was trying to figure out what "side effects" were relevant and which were not[1]. The requirement was to throw IncompatibleClassChangeException when the class had changed and thus the capability was possibly incorrect. We got pretty draconian and went for a "class changes can be "additive" only, so that the capabilities could be forward compatible with new classes. Sadly, politics got in the way of shipping it so I ended up with only a couple of patents and a later Javaworld column out of it and most of work never saw the light of day. [1] For example you might have a File class with a write() method that you wanted to be part of a write capability, but there might also be a update_metadata() method that effectively wrote something to the file so you needed that to be part of the capability, and that method might be looking at static member data of meta data flags, which were also part of the read() capability.

patrec 6y ago
I'm quite intrigued to hear that Java might almost have had a sane security model – what was the political problem that killed it? Anything from your work that you'd like to see used in new languages (those patents must have expired now I assume?).
- ChuckMcM 6y ago
  An influential member of the team didn't understand the code I was checking into the source tree so they deleted it all and added the SecurityManager instead. The manager refused to override that action because "the individual threatened to quit."
  - patrec 6y ago
    How typical was that type of thing? Although on the whole I think Java is better than its reputation, I always thought it a bit underwhelming for the brainpower around at the time; one would kinda assume in addition to yourself people like Guy Steele or Gilad Bracha might also have tried to get a forward looking thing or two in if someone had let them. BTW, the link to your capabilities columns on your home page appears to be be broken: http://www.mcmanis.com/chuck/java/javaworld/index.html http://www.mcmanis.com/chuck/java/javaworld/index.html