5 ms·

Entire companies exist around functionality provided in Unsafe. I don't see this going well if they remove it without providing access to the functionality it g

Entire companies exist around functionality provided in Unsafe. I don't see this going well if they remove it without providing access to the functionality it gives. Java has plenty of problems, but backward compatibility over the years has been simply amazing. This would chip away at one of the few legitimate reasons to use Java in 2015.

xxpor 11y ago
sun.* has ALWAYS been exempt from that guarantee though.
- LoSboccacc 11y ago
  yeah they went the fast and cheap route instead of doing the right thing, and they are now going to be bitten by it, and they can go cry a river for all that I care. those are the sloppy engineers that are holding back evolution of software at large, from little things like obscure functions to huge operating systems like http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/444390.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/44439...
  - Someone1234 11y ago
    You forgot to explain what the "right thing" that they should be doing is? Even according to most articles on the topic there is very to any pleasant alternatives that are cross platform e.g. https://dzone.com/articles/understanding-sunmiscunsafe https://dzone.com/articles/understanding-sunmiscunsafe
    - LoSboccacc 11y ago
      jni, and don't tell me now that c isn't portable.
      - Someone1234 11y ago
        C isn't portable. You cannot write it once and run it everywhere, each platform needs a bunch of macros and flags. Plus you'll now either be delivering it in binary form (which may or may not work due to bitness, OS incompatibilities, and so on) or you'll be delivering it as code (which may or may not work due to compiler incompatibilities, build system components available, and missing libraries). C is only portable in the sense that "every platform ever made has a C compiler." But if you've ever written a C application which is just meant to run on Windows, OS X, and Linux you'll know that it is a painful experience (double that if they're meant to compile it themselves).
        LoSboccacc 11y ago
        *bad C isn't portable. and you can pack as many platform as you wish in your binary distribution, so single download still works everywhere (everywhere you built beforehand).
        ectoplasm 11y ago
        I think the issue is a disagreement over what portability means. To me, portability doesn't mean write once, run everywhere, it just means you can make it run on a different platform with a bit of effort. In a C/C++ program, if you're careful, you can isolate the platform-independent parts so that you only have to write them once. VM languages abstract further by creating a new language for these platform-independent parts. However, the platform-dependent parts are still going to be written in C/C++, or assembly, or generated by a JIT compiler written in C/C++ (there are rare exceptions). So if anything, I would say that C/C++ enables portability, simply because there aren't any other viable choices besides assembly when it comes to generating platform-specific machine code.
        LoSboccacc 11y ago
        no the issue is that while it's true that complex library accessing native stuff in c are hard to port, you don't need the whole stuff ported under jni, and here is the missing link, the functionality provided by unsafe is limited enough (think of it as a building block for higher level stuff) that it could be reasonably done in c, using posix stuff and some patching in for window which while non posix enough is at least stable trough versions. so it basically become write twice run on many things, which is good enough. the problem is that it's not 'rewrite all the libraries in jni' but only 'rewrite the two calls you need in jni' - scoping is relevant, as we are not arguing about jni in a vacuum.
jryan49 11y ago
Java is very explicit that anything not part of the public API may not work in the next version. So I'd say them disabling it, they're in the right. Since so MANY projects use it though, I think it might need some special attention.
geofft 11y ago
Entire companies existed around DOS extenders and TSRs. Microsoft rearchitected and everyone is better off for it. The argument needs to be that the use of Unsafe by these companies (or the projects listed on the blog post) both is good and has no alternatives, not that the use exists.
- taeric 11y ago
  There should be some argument made that the use by these companies is causing trouble, as well. DOS had real identifiable reasons not to use it. The rhetoric used so far just has Unsafe upsetting some engineers for existing.
deleted 11y ago
[deleted]

xxpor 11y ago

sun.* has ALWAYS been exempt from that guarantee though.

LoSboccacc 11y ago
yeah they went the fast and cheap route instead of doing the right thing, and they are now going to be bitten by it, and they can go cry a river for all that I care. those are the sloppy engineers that are holding back evolution of software at large, from little things like obscure functions to huge operating systems like http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/444390.aspx http://blogs.msdn.com/b/oldnewthing/archive/2005/07/28/44439...
- Someone1234 11y ago
  You forgot to explain what the "right thing" that they should be doing is? Even according to most articles on the topic there is very to any pleasant alternatives that are cross platform e.g. https://dzone.com/articles/understanding-sunmiscunsafe https://dzone.com/articles/understanding-sunmiscunsafe
  - LoSboccacc 11y ago
    jni, and don't tell me now that c isn't portable.
    - Someone1234 11y ago
      C isn't portable. You cannot write it once and run it everywhere, each platform needs a bunch of macros and flags. Plus you'll now either be delivering it in binary form (which may or may not work due to bitness, OS incompatibilities, and so on) or you'll be delivering it as code (which may or may not work due to compiler incompatibilities, build system components available, and missing libraries). C is only portable in the sense that "every platform ever made has a C compiler." But if you've ever written a C application which is just meant to run on Windows, OS X, and Linux you'll know that it is a painful experience (double that if they're meant to compile it themselves).
      - LoSboccacc 11y ago
        *bad C isn't portable. and you can pack as many platform as you wish in your binary distribution, so single download still works everywhere (everywhere you built beforehand).
        ectoplasm 11y ago
        I think the issue is a disagreement over what portability means. To me, portability doesn't mean write once, run everywhere, it just means you can make it run on a different platform with a bit of effort. In a C/C++ program, if you're careful, you can isolate the platform-independent parts so that you only have to write them once. VM languages abstract further by creating a new language for these platform-independent parts. However, the platform-dependent parts are still going to be written in C/C++, or assembly, or generated by a JIT compiler written in C/C++ (there are rare exceptions). So if anything, I would say that C/C++ enables portability, simply because there aren't any other viable choices besides assembly when it comes to generating platform-specific machine code.
        LoSboccacc 11y ago
        no the issue is that while it's true that complex library accessing native stuff in c are hard to port, you don't need the whole stuff ported under jni, and here is the missing link, the functionality provided by unsafe is limited enough (think of it as a building block for higher level stuff) that it could be reasonably done in c, using posix stuff and some patching in for window which while non posix enough is at least stable trough versions. so it basically become write twice run on many things, which is good enough. the problem is that it's not 'rewrite all the libraries in jni' but only 'rewrite the two calls you need in jni' - scoping is relevant, as we are not arguing about jni in a vacuum.

jryan49 11y ago

Java is very explicit that anything not part of the public API may not work in the next version. So I'd say them disabling it, they're in the right. Since so MANY projects use it though, I think it might need some special attention.

geofft 11y ago

Entire companies existed around DOS extenders and TSRs. Microsoft rearchitected and everyone is better off for it. The argument needs to be that the use of Unsafe by these companies (or the projects listed on the blog post) both is good and has no alternatives, not that the use exists.

taeric 11y ago
There should be some argument made that the use by these companies is causing trouble, as well. DOS had real identifiable reasons not to use it. The rhetoric used so far just has Unsafe upsetting some engineers for existing.

deleted 11y ago

[deleted]