Slashdot Mirror

← Back to Stories (view on slashdot.org)

Java 9 Delayed Due To Modularity Controversy (infoworld.com)

Posted by EditorDavid on from the see-you-in-September dept.

An anonymous reader quotes InfoWorld: Java 9 won't be released on July 27 after all. Oracle has proposed that Java 9 Standard Edition be delayed until September 21 so the open source community that is finalizing Java 9 can address the ongoing controversy over a planned but later rejected approach to modularity, said Georges Saab, vice president of software development in the Java platform group at Oracle and chairman of the OpenJDK governing board...

The [Java Platform Module System] measure was sent back to the proposal's expert group for further discussion. Since then, the group has reached consensus on addressing the modularity concerns, Saab said. But they cannot rework Java 9 in time for the original July 27 release date... If the revised JSR 376 approved, as expected, work can proceed on implementing it in the official version of Java 9 SE. This setback for Java 9s upcoming upgrade, however, should just be temporary, with Oracle expecting a more rapid cadence of Java SE releases going forward, Saab said.

79 comments

  1. Java? by DontBeAMoran · · Score: 0, Troll

    That's still a thing? I thought we were all supposed to move to WebAssembly?!

    --
    #DeleteFacebook
    1. Re:Java? by __aaclcg7560 · · Score: 1

      Java isn't Perl (yet).

    2. Re:Java? by Lordpidey · · Score: 1

      They're for completely different purposes.

      Webassembly is supposed to replace javascript.

      Java is still used for serverside technologies.

      --
      Some people encrypt by using rot-13 twice. I prefer the more secure method of using rot-1 a total of twenty six times.
    3. Re:Java? by Anonymous Coward · · Score: 0

      java is a hell of a lot more than just the swiss cheese of browser plugins.

    4. Re:Java? by Anonymous Coward · · Score: 1

      For people who work for a living, yes. Ignorant social leeches like yourself aren't likely to have used it for anything besides shitty Bittorrent clients.

    5. Re:Java? by Anonymous Coward · · Score: 1

      Found the millennial.

    6. Re:Java? by Anonymous Coward · · Score: 0

      Well, son, speaking of *tribalism*.... /ahem...

      Javascript is a tool, yes. The fact that it is the ONLY tool in the toolbox is completely idiotic. Why? Because it's poorly designed from the get-go, and despite the efforts of ECMA it is _NOT_ getting better.

      Yes, things change. Change in and of itself does not always constitute a *change for the better*, especially when you insist on changing only one tool, because creating more and better tools "would be a lot of work"....that "almost nobody has any interest in building" ....??? Now, what were you telling me about tribalism?

    7. Re:Java? by DontBeAMoran · · Score: 1

      Hum... swiss cheese...

      --
      #DeleteFacebook
    8. Re:Java? by Anonymous Coward · · Score: 0

      It's funny how people who hate popular things never stop to think that maybe, just maybe they're completely out of touch with why it's so popular. And that maybe, just maybe sometimes popular things are popular not because of the moral decay of society but because they add real value.

    9. Re:Java? by Anonymous Coward · · Score: 0

      The fact that nobody is interested in creating the so-called "better" tools you're imagining has nothing to do with tribalism and everything to do with not enough people agreeing with your conception of "better."

    10. Re:Java? by Anonymous Coward · · Score: 0

      Having a lot of experience with both Java and Perl (16 years in Java, 2 years in Perl) I can clearly state that Java programmers are not rabid fanboys of Larry Wall, the one true programmer who designed his language such that it could take on different meanings based on what is just out of view on your terminal.

      Perl suffers from not having enough reasonable people in the programming base, which consists mostly of people who never went to college to learn Computer Science. Languages that are not context sensitive are far easier to validate than languages which are, and strong typing permits one to catch some errors at compile time (which isn't just a phase that is revisited every time you're about to run a program).

      Java mostly suffers from being the one programming language of its time to try to put OOP first, which really chaps the masses and the elite. The masses hated it because dammit, they just wanted to program in "better" C (and they still try to do that in Java), while the elite don't like Java because they just invested years in learning how to not get cut by C++'s sharp corners. Today Java is not as cool as (insert language X) but it is far more effective to do anything in Java as the key problems in programming are rarely the language, but the lack of decent computer science and sensible supporting libraries.

    11. Re:Java? by Anonymous Coward · · Score: 0

      Perl suffers from not having enough reasonable people in the programming base, which consists mostly of people who never went to college to learn Computer Science.

      Believe me, I've met many college grads who could not program their way out of a bag! I knew a person with a Master's degree in CS that didn't know the difference between a regular variable and a pointer. Being a college elitist snob puts you in the same category with them in my book.

  2. Java? Nobody uses Java anymore by Anonymous Coward · · Score: 0

    LOL jk

  3. shoulda coulda by bugs2squash · · Score: 2

    they should have adopted osgi, maybe with a few tweaks to allow selective inclusion of the standard library components. It's a perfectly reasonable approach that has a proven track record, tooling support and is not significantly more onerous that the idea of modularity is intrinsically.

    --
    Nullius in verba
  4. I only have an A.S. degree in programming... by __aaclcg7560 · · Score: 1, Interesting

    What does modularity mean? Why should I care?

    1. Re: I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      Weird how doing entry level jobs for 50k a year makes it so you don't learn useful things!

    2. Re:I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      You're a Slashdot poster, your mother doesn't own a coffee table.

    3. Re:I only have an A.S. degree in programming... by Creepy · · Score: 1, Interesting

      From what I've read, it is a fancy way of saying modules will enforce the object oriented paradigm. In true object oriented languages like SmallTalk you can't change anything inside the object without accessor functions into the object, but languages like java and c++ have the idea of 'public,' which allows access and even changing things inside an object (and the reasoning is that it is much faster to just change x than have accessor functions like setValue(x) and getValue(x)). Not having modular code makes modular testing difficult because any other class can change values in the class you want to test without the class knowing about it, so problems with a module may not be caused by your module. For example, if some other class (module) tries to set the resolution to 3840 × 2160 but the monitor doesn't support that, you can have your class (module) enforce the maximum resolution and refuse the new setting. Enforcement of those settings can therefore be entirely contained to the module and tested within the module.

    4. Re:I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      Two sagging cardboard boxes and a cut off piece of a door?

    5. Re:I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      There is also things called 'private' and 'protected' which prevent those items from being modified outside of the object. If that's all modules are in Java, then it's a shitty workaround to developers who are too lazy to auto-generate getters and setters.

      At a higher level, breaking things into modules makes understanding, developing, and supporting software systems much easier. Every module/service/component/actor/program/interface/etc... has a set interface which should be what that module can do (example: makeSandwhich(details) instead of: setBreadType(), setSpreadThickness(), ..., combinePartsToMakeFood()). The module can be understood fully by itself without having to learn any other aspect of the system. Thus you can diagram complex systems based on how their modules interact rather than trying untangle random function calls. If you need to change a part of the system, then you can jump to the related module instead of trying to trace through the entire programming looking for the right spots to edit. For testing, you can swap out a module for a stubbed version if you want to test the other modules of a system. For team development, each team member can work concurrently on their module without having to worry about conflicting with other developers.

    6. Re:I only have an A.S. degree in programming... by Richard_at_work · · Score: 2

      But don't the standard access modifiers (public, protected, private and unmodified) already accomplish that...?

      Set your class to public, but your class variables to private and they cant be called by anything other than code in the class itself... if you want to set defaults and sanity check values, you create getters and setters...

    7. Re:I only have an A.S. degree in programming... by __aaclcg7560 · · Score: 2

      From what I've read, it is a fancy way of saying modules will enforce the object oriented paradigm.

      Loooks like this might be the Java version of the Python package (a collection of modules) with a layer of access control. Being a Java implementation, it's going to be a fine mess.

      https://softwareengineering.stackexchange.com/questions/311280/why-packages-and-modules-are-separate-concepts-in-java-9

    8. Re: I only have an A.S. degree in programming... by __aaclcg7560 · · Score: 1

      Weird how doing entry level jobs for 50k a year makes it so you don't learn useful things!

      I haven't used Java since I got A.S. degree. These days I install Java updates on systems that won't play nice and I use Ant to automate some of my Python scripts at home. I keep hoping that I might have a reason to look at Java again but my hopes keep getting dashed by Slashdot nihilism.

    9. Re: I only have an A.S. degree in programming... by ewanm89 · · Score: 3, Informative

      They envisioned a way where one could package the parts of the standard library with a application without including the whole thing. Of course, to do this they decided to totally change how the classpath and classloader works (how the VM finds and loads libraries) and then break reflection (being able to inspect library code from the code using that library).

    10. Re:I only have an A.S. degree in programming... by mark-t · · Score: 1

      What modularity in the case of Java 9 means is that it was intended to migrate away from a monolithic design, which could enable faster startup times for many programs as they would not need to wait for the entire JRE to be loaded and initialized before starting.

      --
      File under 'M' for 'Manic ranting'
    11. Re:I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      I'm not seeing the advantage here. If you want to restrict access to the choice of screen resolution as you describe wouldn't you just make them private and provide set/get functions for access? Just because you give the developer an option to shoot themselves in the foot doesn't mean they have to take it, surely?

    12. Re:I only have an A.S. degree in programming... by angel'o'sphere · · Score: 2

      Your rant has nothing to do with Java Modularity, aka project Sigjaw or look at OSGi.

      Your reference to SmallTalk is wrong too.

      In Java you have a private attribute x, and use accessor methods like getX() and setX(). But if x was public you could write: obkect.x = balls or balls = object.x. In SmallTalk you can not even write that, because it lacks the syntax for it. Hence the SmallTalk IDE/compiler generates you the getX and setX methods ... no big deal.

      The rest about "modules" you write is utterly wrong.

      A module is a jar file, aka a library, that exports (makes public) some of its classes and some not.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    13. Re:I only have an A.S. degree in programming... by angel'o'sphere · · Score: 1

      Laymen don't need to care. For them it makes writing simple programs just more complicated.

      A module is a library, aka jar file, that exports a part of its classes, and keeps the other classes private. Unlike ordinary "private classes" non exported classes are basically invisible for everyone outside of that module.

      While you can do that with OSGi, too, OSGI is configured via the .MANIFEST file in a jar file and modules in java 9/project Sigjaw are configured via semi Java looking source code processed by the compiler.

      Modules can have dependencies and have version numbers, so module x-1.0 can depend on module y-1.2 etc. How the dependency resolution works and how they support maven or similar repositories, I don't know. I did not bother to "learn" that stuff, as it is now postponed to be released since about 5 years .... yawn.

      If you are bored: https://www.infoq.com/java9+mo...

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    14. Re:I only have an A.S. degree in programming... by angel'o'sphere · · Score: 1

      I'm not aware of anything in the Java world that is a mess :D

      The stackexchange question you link is simple to answer: because packages and modules are two different things?

      Is the trunk of your car a suitcase? Or a pocket in your jeans? Does your jeans pocket have a lock? Does your suitcase have wheels? Regardless of yes or no ... are they the same thing?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    15. Re: I only have an A.S. degree in programming... by angel'o'sphere · · Score: 1

      and then break reflection (being able to inspect library code from the code using that library).
      Inspection always ever only worked on objects and classes and not on libraries.
      So if you have a class loaded from a module, reflection works exactly the same as loaded from an ordinary jar file.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    16. Re:I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      All you are describing is poorly written software, nothing else. Of course there are accessor functions, it`s a pretty simple software pattern you can implement in java, c++, c#, etc.

    17. Re: I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      This is slashdot, not YouTube. And worse, you're not funny. You're not welcome here.

    18. Re: I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      All the real Java programmers eventually got tired of the Slashdot Java hate. It helped push a lot of people off this site.

      Slashdot likes to live in a bubble where they barely know Java, but are experts in how it sucks. It's as if they could collectively alter reality based on their hate. There's a reason Java is the leading language for new application development for over a decade, but the people here won't listen. They just prefer to hate it.

    19. Re:I only have an A.S. degree in programming... by Anonymous Coward · · Score: 0

      java - the well-organized language designed for large enterprise software projects, with a huge standard library, backed by one then by another huge company is "of course going to be a fine mess"

      heavy cream posting more deep thoughts about things he knows nothing about. the true question you can answer for us creamer: is java as heavy as RAID? now talk about your weight some more please.

    20. Re: I only have an A.S. degree in programming... by ewanm89 · · Score: 1

      Okay, on the Java a library is a set of classes... And an object is just an instantiation of a class. I would point out that when loading other JVM hosted languages these semantics no-longer necessarily hold true but the reflection can still be used.

      And no it does not work the same with modules, I know because it does fun things when the way the Clojure interpreter/compiler works uses that reflection and it is a core part of LISP based languages. The reflection checks a whole new set of access control related to these "modules" which gives important Clojure traces as unknown class, unknown method...

      Finally "an ordinary jar file" is not a first order thing, it is a packaging format (really just a ZIP file of .class files with a few metadata files added), the .class files are the first order way of load classes. However more than that, there are different levels of class loading governed by calling different class loaders in the JVM, Languages like Clojure inject into the JVM at a lot earlier point than an import statement in a running program does. This difference is important allowing clojure to override certain things and do the high performance interpretation/compilation without having the overhead of the rest of the libraries loaded that the users code uses.

    21. Re:I only have an A.S. degree in programming... by Immerman · · Score: 1

      Indeed. And there's really only two reasons I leave member variables public: they're cosmetic/convenience data that makes sense to bundle into a larger object from a data management perspective, but doesn't actually affect functionality (so it's extremely unlikely that unexpected changes will cause problems). Though I do lean away from this for anything that might conceivably eventually need validation or other special handling.

      Or alternately, when I'm writing a simple class where the internal functionality should reasonably be exposed - for example a 3D vector or quaternion type, where direct access to the data components permits access using conventional mathematical grammar, and it's impossible to place them into an inconsistent state anyway.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
  5. java medium security come back! lot's of IPMI and by Joe_Dragon · · Score: 3, Insightful

    java medium security come back! lot's of IPMI and network hardware needs it.

  6. Misread title by Anonymous Coward · · Score: 0

    As "Java 9 Delayed Due To systemd Controversy."

  7. Re: Are people still seriously using Java? by Anonymous Coward · · Score: 1

    It's the #1 used language so yeah, a lot. If I want a job in Java there are near endless options. If I want a job in, say, Elixir, I would have to move.

    Java is far from perfect, but Spring Boot with Java 8 does everything I need it to.

  8. Re: Are people still seriously using Java? by Anonymous Coward · · Score: 1

    People that make money use Java.

  9. Re: Are people still seriously using Java? by Anonymous Coward · · Score: 2, Insightful

    It is easy to refactor Java with Eclipse rename and extract. It has maven which makes 3rd party lib usage simple. It has auto formatter. Using threads is simple enough. Making libs is simple. It is fast. Debugging is easy. It has good static analysis support. It is easy to find people who know the language. The language has pretty good libs for many different things like GUI, calendar, 3D, regex... , JUnit makes testing easy, auto import works with it, it will by default give good info where it crashed and why, it is OSS, it is easy to manage even large projects with it. Library support for various databases, and many other things. Many of these are because of Eclipse and similar IDEs, but considering how bad IDEs C++ has, I think it is because of the language that these tools could be made.

  10. Re: Are people still seriously using Java? by Anonymous Coward · · Score: 0

    Not used CLion for C++ then?

  11. Re: Are people still seriously using Java? by mark-t · · Score: 1

    i gave up on colon because I couldn't import my existing projects with their own working makefiles. It insisted on using cmake

    --
    File under 'M' for 'Manic ranting'
  12. Re: Are people still seriously using Java? by mark-t · · Score: 1

    Fucking autocorrect. I meant clion

    --
    File under 'M' for 'Manic ranting'
  13. Re: Are people still seriously using Java? by Anonymous Coward · · Score: 0

    Emacs is written in lisp and is the best ide

  14. Re: Are people still seriously using Java? YEAH! by Anonymous Coward · · Score: 0

    Ummm The ENTERPRISE uses it heavily! Many major Ecommerce sites are built on it (Cabelas.com - I helped build the original site when it was on ATG, then it got re-written onto Blue Martini). nflship.com, espnshop.com, footlocker.com, eastbay.com,finalscore.com just some of the others that were built with Java and Cold Fusion. bestbuy.com is as well.

  15. Duh. That's what happens when Sun is involved by Cyberax · · Score: 4, Informative

    This is what happens when architectural astronauts get involved. The module system was NOT designed to solve clients' problems, it was designed to make JVM "modular" to better support IoT and "containers".

    And because it's not a user-driven feature, Snoracle went wild. They designed a complicated system that basically will force a significant redesign of every large Java-based system, all the while ignoring experience of OSGi, Maven and other modular systems. Here's a nice breakdown: https://developer.jboss.org/bl...

    I can add a couple of my own comments, Snoracle is _still_ enamored with code access security. They think that they need to mutilate the language to support running of privileged and unprivileged code within the same address space, separated only by module boundaries. To this end, they designed complicated rules of visibility with restrictions for reflective access. You can guess how useful this is going to be - just remember the great security of applets.

    1. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      Applets where unsecure because the Java Plugins for browsers had bugs. (Because they had to implement more security restrictions than an ordinary VM)
      That has nothing to do with Java 9 modularity.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    2. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      Java 9 modularity spends a lot of spec to describe ways to limit the access from untrusted to trusted modules. The justification is code access security, this model splits _code_ into trusted and untrusted with trusted code having privileged access. And it's the real reason applets were so buggy - it's easy to trick a lot of "trusted code" by carefully crafting the data it works on.

      In contrast, modern approaches put the trust boundary at the process level and simply disallow access to anything that is not explicitly whitelisted. See: http://doc.pypy.org/en/latest/... as an example. Your code can be as buggy as you want, but it doesn't matter if it can't access the whole world.

    3. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      And it's the real reason applets were so buggy - it's easy to trick a lot of "trusted code" by carefully crafting the data it works on.
      That is nonsense.

      Java Sandboxing works based on so called Security Managers, which restrict access to certain packages, classes or modules, and have nothing to do with "data".

      Nice link though, but it looks similar vulnerable as the Java way. Only glanced over it, but will study it later, thanx.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    4. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      That's what I said - Java uses code access security. It divides code into trusted and untrusted parts, so that trusted code can do privileged actions. The great problem here is that the trusted code can be called from untrusted. And then it takes just one privileged function like:
      public String listFiles(String data) {
      return call("ls -la "+data);
      }
       to ruin everything. And it turns out that the JDK is full of these.

      The modern approach is to limit the _data_ on which you can operate by restricting you to operations with file descriptors you've inherited with the environment and maybe to IPC calls through a well-defined protocol. Think about this as a classic Unix suid binaries versus network servers with authentication.

    5. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      Sorry, I don't get what you want to say.

      If call() is a method in a package/class that can only can be accessed under certain circumstances, e.g. SecurityManager grants access, it can only be called then. Unless there is a bug.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    6. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      Suppose that listFiles() is within a trusted package and was left with public access so it's granted appropriate permissions from SecurityManager. The fact that it was left with public access _is_ a bug, of course. The problem is that it's too easy to make such mistakes and it takes only one to bring down the whole system. And if you think such mistakes are rare, here's a partial CVE list: https://www.cvedetails.com/cve... , https://www.cvedetails.com/cve... , https://www.cvedetails.com/cve... , https://www.cvedetails.com/cve... , and so on.

    7. Re:Duh. That's what happens when Sun is involved by drolli · · Score: 1

      And it turns out that the JDK is full of these.

      As long as it's only JDK and not the JRE.....

    8. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      I should have said "JRE", JDK is basically a JRE with a compiler, source code and examples packaged.

    9. Re:Duh. That's what happens when Sun is involved by squiggleslash · · Score: 2

      What the GP is referring to is called the Confused Deputy problem, a class of security issues where:

      * A isn't trusted to access C because reasons.
      * A is trusted to access B.
      * B is trusted to access C.
      * By exploiting a bug or design flaw in B, A can actually access C.

      The fact that Security Manager prevents an application from accessing, say, the classes used to access (for example) the file system doesn't mean that an application cannot fool other built-in privileged classes from accessing the file system in the way the application wants if those privileged classes have bugs.

      The proof is in the pudding, to a certain extent: if Security Manager worked, then Java applets wouldn't have a reputation almost as bad as Flash's for having the security of swiss cheese. Now, I'd agree with the view that Java isn't nearly as insecure as detractors claim - to a certain extent, we're looking at the airplane vs car problem, where people will drive because they think flying is unsafe, because car crashes aren't news whereas air crashes are reported internationally. But it's certainly had exploits over the decades its ran.

      Disclaimer: I can't comment on whether anything being proposed for Java in Java 9 would actually fix this. If java.boogie.graphics.OpenContext(String prefs) throws ContextExceptionWithCompleteConfigurationInExceptionObject does a direct system call to fopen("/var/lib/java/boogie/contexts/" + prefs + ".cfg"), I don't see how any amount of sandboxing or scoping is going to fix that.

      --
      You are not alone. This is not normal. None of this is normal.
    10. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      Suppose that listFiles() is within a trusted package and was left with public access so it's granted appropriate permissions from SecurityManager.
      That is not how a security manager works.

      he fact that it was left with public access _is_ a bug, of course.
      If it was not public it could be called at all.

      Perhaps you mean: there should be a public method that is invoking the security manager before calling the private implementation. And the example above you assumed "listFiles()" was that private implementation and left accidentally public as well?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    11. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      Security manager works exactly as I described - you whitelist code to invoke privileged actions: https://docs.oracle.com/javase... It's also possible to grant privileges dynamically to the calls down the stack (that's what you're referring to), but it's not the sole model. The JRE uses the whitelisting approach for its own classes - check the jre/lib/security/java.policy file for details if you don't believe me.

      In the example above I assumed that listFiles() was somehow made callable with untrusted data (perhaps not even directly).

    12. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      if "listFiles()" is supposed to only work if there is no SM installed then the code inside of listFiles needs to look something like this:

            if (System.getSecurityManager() == null) {
                  return privateListFiles();
          } else if (System.getSecurityManager().getListFilesPermissions() == "can list files") {
                return privateListFiles();
          } else {
                throw new SecurityException("list files not permitted");
          }

      Policy files are used for different stuff, e.g. Applets (and then read by a SecurityManager).

      So: no, the system does not work the way you think it would.
      However it would make more sense to have policy files for everything and have a CodeWaver that weaves in the security (manager) code.

      The JavaDoc you linked has absolutely nothing to do with SecurityManagers aka calling of certain code. It is an abstraction for ACLs, Digestes and Certificates.

      Perhaps you should read the links you post?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    13. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      The problem is, if listFiles() is inside the JDK then it doesn't NEED to look like this. It will work just fine and all the permission checks inside call() that runs a command-line utility will be green. What you're describing is a manual check inside the listFiles() which is completely beside the point.

    14. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      I don't understand what your point is :)
      Java security managers work in the way I described.
      No idea about what you are talking.

      However I would rewrite the JDK with annotations and let the compiler weave in the calls to the security manager, or even better use proper AOP and define all security related stuff outside of the runtime, you could even use a policy file for that.

      I guess you talk about completely different security issues then I did.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    15. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      NO THEY DON'T. I gave you links to actual policy files. In JVM you grant permissions to _code_, so if your code has appropriate permissions then anything will just sail through. You are confusing it with _how_ permission checks are _sometimes_ implemented in JVM. For example, FileInputStream internally has a check with the SecurityManager and so does ProcessBuilder.start()

      However, if ProcessBuilder.start() is called from the code inside the JRE then it WILL ALWAYS RUN, according to the policy file I gave you. So if listFiles() is inside the JRE and is public then any applet with the most strict security policy will be able to call it, and listFiles() will then be able to call ProcessBuilder.start() without any problems.

      The fact that you don't understand it exactly explains why code access security is such a pile of shit.

    16. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      And I told you: policy files are not used that way.

      When a security manager is installed it absolutely does not matter from where the relevant code is called. That would be completely idiotic to allow JRE calls and forbid "client side code calls".

      So if listFiles() is inside the JRE and is public then any applet with the most strict security policy will be able to call it, and listFiles() will then be able to call ProcessBuilder.start() without any problems.
      No it won't. That makes no sense.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    17. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1
      Seriously? Please at least read this: http://docs.oracle.com/javase/... - it describes how grants work. Now read the JDK policy. You can even write a short demo - create a policy grant for one class and create a security manager that restricts everything. Run your code with this manager and try to use privileged operations with this class. It will work, I tried this. Do you want to bet against it?

      No it won't. That makes no sense.

      Yes it will. And yes, it doesn't make much sense.

    18. Re:Duh. That's what happens when Sun is involved by angel'o'sphere · · Score: 1

      If you use a policy file to grant or restrict access to certain methods of the target object: every method on the call stack needs to have a _grant_

      It is clearly written in the Docu you link. Or in the X-linked other pages.

      It is completely impossible, unless there is a bug, to trick a JRE method into calling something the client code has no grant for.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    19. Re:Duh. That's what happens when Sun is involved by Cyberax · · Score: 1

      If you use a policy file to grant or restrict access to certain methods of the target object: every method on the call stack needs to have a _grant_

      Grants are applied on per-location basis. A file anywhere in JDK is granted all access. If it then calls (through a callback) a code outside JDK then this code won't get any additional permissions. You're keeping inventing stuff, just read the document.

      You're confusing the static code access security with doPrivileged stuff which is dynamically assigned to the thread context: https://docs.oracle.com/javase...

  16. Repeat after me... by Anonymous Coward · · Score: 0

    "Java" is not the same thing as "Java Applets" which are not the same thing as "JavaScript"!

  17. Re:Are people still seriously using Java? by angel'o'sphere · · Score: 2, Insightful

    All the idiots who want stuff to get done and get payed for it.

    It is surprising how ignorant /. readers are.

    While the majourity of all big internet software in the USA is written in Java, thy proclaim death to Java all the time. How is the balance between C# and Java in the USA regarding serious back end software? 10% is Python and PHP and 0.5% PERL? And the rest? 60% Java versus 40% C#? No idea just wondering.

    In Europe basically 90% of all industrial software on high performance back ends is written in Java. The idiots who decided for C# don't even find developers to maintain their systems. I have requests for C#/.NET developers every day. I would get $1000 for every colleague I would refer to the requesters. Unfortunately I do not know a single person who is so dumb to work with C#/.Net ... go figure.

    Java is just C++ running on a VM without real templates, anyway. If that is to hard to grasp, you should not be working in the software industry.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  18. Not too surprising... by ndykman · · Score: 5, Interesting

    The JSR process has become massively slow with tons of large companies fighting by proxy. Honestly, I think .Net Core may find a bigger place in the overall ecosystem alongside Go and NodeJS. Sure, Java isn't going anywhere, but some of the issues that Java 9/Jigsaw are trying to deal with don't exist in .Net, and C# has adopted some very useful language features.

    Also, the .Net Core is simplifying some complex use cases that Java 9 is trying to adopt. They are depreciating AppDomains in favor of OS level isolation (processes, threads) while still allowing for unloading/replacement of assemblies. Similarly, they are backing off the code trust model, moving again to OS level mechanisms. Their reasoning is pretty sound, it was complicated, didn't really work as expected and why not simplify and just support what most people actually do.

    It's not prefect and there's work to be done, but it might really gain traction. .Net has great APIs for the kind of strongly typed data transformations enterprise apps do. They still have build chain issues and cross platform tooling needs to mature, but really, if all the major players in the JSR keep butting heads like this, Java will face even more competition than it already does.

    Also, this all impacts other languages. Scala and Kotlin have to jump some hoops to support certain features, but they are still tied to the JVM and its core mechanisms, which why this was a part of Java 9 in the first place.

  19. Re: Are people still seriously using Java? by Anonymous Coward · · Score: 0

    No clion came after I switched to Java. But I did use C++ and C heavily before that. Even made my own IDE with C++. After mastering both languages I won't be going back to C++. 2 files for 1 class, everyone using different build file system, unit testing or compiler with its own extensions. C++ ecosystem is a mess. But I will still ask. Can you rename a class and its files with one action in clion?

  20. Re:Are people still seriously using Java? by __aanljs7351 · · Score: 1

    I've been in IT for 20 years and started coding by typing in those programs they'd print in the old tech magazines. While I've seen C# and PHP, I don't know anyone who uses Java or PERL. I myself usually refactor in Python. This is in Silicone Valley though - I don't know about Europe (don't even have a passport).

  21. Re:Are people still seriously using Java? by squiggleslash · · Score: 2

    If you're in "Silicone Valley" (isn't that Beverly Hills?) then yes, you've probably never been exposed to Java. If you worked for a giant non-tech company - banks, automotive manufacturers, etc - you'd almost certainly be a Java (or possibly .NET - but not desktop application .NET) grunt, not programming in whatever it is you do.

    If you're old enough to have typed in programs from computer magazines, then think back to those days, and imagine if you worked for Microsoft, or Commodore, or for that matter Activision. You'd have been exposed to a lot of assembler and BASIC, and maybe some C. You wouldn't have met anyone at all who did anything in COBOL. But in the 1980s, COBOL was still one of the world's most popular programming languages, if not the most popular. Our industry is much more specialized than most people think.

    --
    You are not alone. This is not normal. None of this is normal.
  22. Re:Are people still seriously using Java? by angel'o'sphere · · Score: 1

    Perhaps ou can google which silicon valley companies mainly use Java :D
    www.indeed.com lists about 2400 Java jobs in silicon valley open.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  23. Re:Are people still seriously using Java? by __aanljs7351 · · Score: 1

    I don't need to google, I have been in IT for 20 years. Started out video games - those weren't in Java either. All I'm saying is in my career, I have not seen Java. I am a virgual ditch digger though - not a software developer or DBA.