Evidence of incompatibility (was Some suggested patches and improvements)
On Wed, May 17, 2017 at 1:08 AM, Andrew Dinn wrote: > On 16/05/17 19:11, Gregg Wonderly wrote: > > > > > If we really cannot actually keep from breaking 90% of existing Java > > in the market place when this new JDK release goes out, how valuable > > is JigSaw really? > > citation needed? > I mostly ignore jigsaw, and check in every now and then. I have a few co-workers that have poked at migrating their products to Java 9. So far as I know, nobody has succeeded yet. With significant regularity, I see issues pop up on this list that have odd problems, or persist in being unresolved. One of my favorites at the moment is automatic module names - a problem that Jigsaw caused for itself. Maybe that one is resolved for now, but I'm pretty certain that questions will come flooding back once Java 9 GAs. As near as I can tell, applications that compile and run under Java 8 will mostly *not* "just work" with Java 9 JRE. And that seems to be the lived experience of my co-workers. If a project is lucky, the only changes necessary will involve command line parameters. If a team is unlucky, they will need to rebuild for Java 9. If a team is really unlucky, they will need to partially or fully modularize. At which point some even more juggling is required to continue to support Java 7 & 8, if that's required by customers. My overall concerns for Jigsaw: https://medium.com/@one.eric.johnson/java-9-jigsaw-troubles-4fc406ef41e0 I'm not sure what citations you expect to see. There's probably nobody out there who can afford to pre-flight an EA build of Java 9 against all their products to see what the actual costs are going to be. Based on anecdotal evidence from this mailing list, significant players in the Java ecosystem - build tools, IDEs, critical libraries - have all had to fix unexpected breakages with Java 9. Obviously, the ones that don't break don't typically show up, so this is a self-selecting example, but an important one. However, even something as simple as requiring changes to command line parameters in order to launch a program compiled for Java 8 is a breaking change. The Jigsaw team seems to be taking this as a mere complaint, rather than as a genuine compatibility issue. Here's a challenge back to the Jigsaw team. Can I still do java -jar ... every existing Java application (without recompile!) that currently launches that way? I'm even willing to cut some slack and ignore applications that use com.sun APIs that have been "private" for years. Will that still work? The Jigsaw community should be able to provide evidence that's still possible, not that we should be required to provide evidence that it isn't. Eric. > regards, > > > Andrew Dinn > --- >
Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch
On 12/9/16 3:21 PM, Uwe Schindler wrote: > The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, > but it does not solve the underlying issue. Apache Solr/Lucene and > Elasticsearch will no longer work with Java 9 unless you require users to add > those strange options. Elasticsearch already runs with a SecurityManager by > default, so the question is: why is this not handled by a security manager > and a new permission like "crossModuleAccess/module/package"? Why must it be > done on command line? This makes it impossible to ship something like Lucene > that it work out of box together with correct policy files? I've asked the question multiple times on this list, about what the threat model analysis is behind this new level of runtime "security". Alas, no answers so far. Eric.
Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)
On 9/25/16 8:50 PM, GREGG WONDERLY wrote: I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count. I'm with you there. I'm fascinated that this thread has triggered references to the "legacy" security manager. Somehow, the security manager is defacto not worth extending / expanding, but this whole module boundary enforcement scheme is. I understand that the JDK itself is not deployed with a security manager impl in most cases, and thus there would be no access context for the security manager to be used against. A different way of framing this whole discussion, though, is to say that with Jigsaw, Java always runs with some kind of "security manager". Oracle may not want to call it that (whatever, it is just a name), but that's effectively what it is. What is annoying / odd / frustrating is that there's no variability in implementation. The discussion on this list has made it crystal clear that the JSR authors did not fully anticipate the range of security people would need to impose. Using an analogy, even SELinux has configurations where boundary violations are merely logged, not blocked. What’s odd, is that you are still trying to block access to reflective access to the “open JDK”. If it’s really open and it’s really something that the community contributes to, why do we need to block access, hide details and otherwise obfuscate access details? Modularization should just be about separating pieces not needed should it not? Well, yes and no. I'm all for modularizing the JDK. Yet, for effective modularization, you have to hide things at compile time. The treatment of com.sun.* APIs over the years is clear indication that merely flagging these issues as warnings will not keep people from poking around the innards. The details need to be blocked, or people will keep using (exploiting?) them. Why has this degenerated into such a huge bit of access restriction too? Runtime enforcement is another problem. I respect Oracle's (implicit) position that they need to block access to the "non-published" aspects of the JDK. Why? Because every API they can hide reduces the attack surface for every application that runs in the ecosystem. By in large, that's entirely a good thing. My company's products have in the past been exposed to this very problem - reflective access to the innards of the JDK enabled possible attacks - /merely by the presence of the wrong version of a JAR file in the classpath/. If the JDK innards were hidden at the time, the attack avenue would have been blocked. Taking enforcement further, though, becomes problematic very quickly. I suspect the best way to inform that discussion would be with well explored threat models. That way, we'd know what the new module boundaries are supposed to be protecting us from. With the current Jigsaw approach, it seems logical that if it is good for the JDK to reduce its attack surface, that it is likely a good thing for everything that runs on top of the JDK. However, that's making all sorts of assumptions about threats. So what we seem to be left with on this mailing list is continued exploration of use-cases that run afoul of the "reduce attack surfaces for everything" approach. Whereas I think we'd all benefit from looking at the different threat models. Could people who think that modularity should solve these problems and the security manager not be part of the solution please provide some details about how security is the modularization mechanisms responsibility and not the security managers? For deployment, I’ve always used the security manager to limit/control access when I take some 3rd party code/jar and deploy it into a production environment. That helps me restrict its access to resources in a manageable and maintainable way. What I see happening, is that this single issue of “access” to pieces of software, from other pieces of software is degenerating into huge amounts of complexity and specification and release control, which isn’t really what makes “open software” work together. I think the "open software" aspect is likely unimportant. Huge amounts of complexity and specification are an anti-pattern in any environment. Particularly in the realm of any kind of security enforcement, the simpler the better. The more complex the rules, the more likely it is that the implementation makes a mistake. Eric.
Java 9 Obfuscators?
Anyone aware of byte-code obfuscators already working with Java 9? How does modularization interact with obfuscation? Eric.
Re: Exporting - the wrong default?
There's so much to tackle on this thread... On 8/2/16 5:47 AM, Stephen Colebourne wrote: IMO, we need to get existing OSS libraries migrated to modules ASAP to maintain the ecosystem, which requires the migration to be really simple. Get this wrong, and we'll all just carry on using the classpath, and the last 5+ years of effort in the JDK will have little value. Indeed. Commercial vendors will have the same problem. And to the extent that we use open source libraries, we may need to fork said libraries. In working with OSGi, my company has had enormous issues with getting the metadata right for libraries - nothing obviously wrong with the code, but the metadata is a royal pain. It doesn't appear to transfer between platforms seamlessly. Potentially a huge cost with JDK 9 modularization. At the same time, I work on security issues. I want security by default. So I want both sides of this question to get the answer they want. Nasty conundrum we've found ourselves in. One part of the split is simple - modules are a (presumably) useful compile time constraint. Giving Java the ability to hide public classes simply because the author didn't really want to expose them, but the language constraints didn't give them a choice, that seems like an improvement. This is not a security problem, just a language problem. Bring module enforcement into the runtime, and it is now a security problem. All security problems are trade-offs. For one step, (as I've mentioned before) I'd really like someone to point at some security analysis document that goes through the threat model analysis (or its equivalent), so we can have a deeper discussion than "default to secure" as the only answer. Off the top of my head, I cannot think of any threats to something like Eclipse, which has already embraced the OSGi form of modularization. How will Jigsaw modularization enforcement at runtime can actually make Eclipse safer? I don't think it will. On the server side - much different question. On the server side, without deep analysis, I suspect the default to enforce module boundaries makes sense. However, we also know, up front, that such a step will break things. To fix that breakage, will mean lots of changes to code, made by a lot of people, not all with lots of experience, across a lot of libraries. In other words, an opportunity to accidentally introduce new security bugs while trying to work within a new security framework. Again, wanting a threat model analysis, because helping those developers cross the chasm should be part of the threat equation that we're trying to solve. So we really want a place where people can start using modules at compile time, and choose to opt into module boundary enforcement at runtime. I suspect it is probably an OK starting position if the JRE itself always benefits from boundary enforcement. But everything else - not sure that's a good idea, as it will blow-up the Java ecosystem. Two possibilities - either a flag for the Java runtime to enforce module boundaries (default off?), or let individual modules choose whether they opt-in. Actually, both might be useful. With the opt-in on a module basis, the open source project that needs to produce a module can produce one quickly, and opt-out of boundary enforcement. No source code changes besides module declarations, so minimal risk. That way, those developers can avoid all the hacking on code and changes that might be necessary by flipping to strict enforcement immediately. Over time, downstream users of those open source projects will be able to test those libraries by flipping a switch, and enforcing module boundaries for a given module, then testing to see if that caused problems. They can then go back to the open source project with definitive information, gleaned from actual use, about what is necessary to opt-in to full enforcement. As for flags on the runtime, it might be good to have a flag which defaults to off. Other settings would be "warn", and "strict". SELinux, which seems closely analogous to this problem, has a similar model of "warn" vs. "enforce". So perhaps a good pattern to follow? Eric
Re: It's not too late for access control
At least someone replied to my question. On 7/14/16 5:44 AM, Russell Gold wrote: On Jul 12, 2016, at 1:31 PM, Eric Johnson wrote: What infuriates me is that in all this discussion, I don't see anyone talking about a threat analysis. What are we trying to protect, from whom, and why? I see comments about how implementation details of the JRE (such as "com.sun" packages) must be hidden, but without reference to the threats that cause a problem. It’s primarily a maintenance issue, IMO. It is common that we provide classes and methods that are intended to be used from elsewhere inside a product, but which we do not want users to see. That is, it is much the same as the reason you use “private” for class internals - if everything is publicly accessible, people use it, and you cannot refactor your code without breaking theirs. If the entire aim is just a maintenance issue, then I assert that compiler changes should be sufficient. At that point, anyone who fires up runtime reflection to work around the compiler gets the benefits and the costs that they deserve. Benefits include the ability to leverage code in the guts of any library or the JRE that the authors decided they didn't want to publish. And they embrace the likelihood that it will break in the future. I don't feel a huge need to argue about language design. Other people can battle over the contentious issues of what is appropriate for language constructs. That could be module boundaries with metadata, it could be new keywords like "friend", or even package level declarations (more like OSGi). I suspect we'll all adopt to the "best" solution determined by those who want to improve the language. To make this more concrete, Scala could introduce some kind of scoping mechanism completely unfamiliar to existing Java developers. Few people, if any, would be upset that it was merely a compile-time enforcement, and the runtime didn't enforce the new capability. Same should be true of Java itself. For one possible framing, perhaps I ought to be able to compile a module-based application and yet run it on Java 8 without modification? So yes, modules for the compiler, if that's what Oracle thinks is best for the language, I can live with it. Need not affect the runtime, though! However, like I said in my original email, I believe genuine security issues can be found in this quicksand. The JRE has valid reasons to prevent access to implementation details. That reduces the possible attack footprint, and also strengthens the walls of the "sandbox" that Java puts up (more code to tunnel through before getting to the vulnerable chunk). And it seems pretty clear, from the CVEs found <https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html> in the JRE, that these changes should happen regardless of whether or not the runtime has a security manager installed, because it is common enough to run without one. To pick an example from another language, you can't run Ruby without having "taint" support on. In other words, the Jigsaw runtime change to enforce module boundaries amounts to /always/ running with some sort of security manager. If you frame the implementation that way, though, then it is clear that alternate implementations might be quite valuable - especially in a transition phase from prior versions of Java. While this discussion is ostensibly about reflection and accessibility, I'm viewing it as really about what kind of security manager is the minimum allowed at runtime. I applaud Oracle's effort to tackle the unpleasant task of imposing (on us) a mandatory minimum security monitor on the JRE classes. However, to date, Jigsaw is imposing one specific model of mandatory minimum security on all of us, without entertaining alternate solutions. That's what I find enormously frustrating. It is pretty clear to me from the discussions on this mailing list that the one they've enforced so far is the wrong one, at least if Java 9 is going to be adopted widely.
Re: It's not too late for access control
On 7/11/16 7:21 AM, David M. Lloyd wrote: The crux of this access control discussion is that, up until JDK 9, "public" meant "public". End of story. If you did not want something to be visible, you made it not public. Very simple and very clear. The word "public" literally means "accessible to all" after all; that's why the term was selected in the first place, and it is nearly certain that this was the intent of the thing up to this date. To be fair, OSGi established a precedent - a "bundle" can make a distinction between that which is public and that which is "exported". (I think of this as the distinction between public vs. published, because I like the alliteration). Mostly, I agree with your point, though! OSGi makes this distinction, because it is worried about having multiple versions of the same package available at run-time, and even that bundle A can have a complete copy of JAR B - from a completely different project - and not want to take responsibility for the "public" version of the API of JAR B. So OSGi explicitly needs to be able to hide ostensibly public APIs, because author A cannot possibly correctly guess the intent of author B in all cases. However, Jigsaw is explicitly not concerned about this problem, so the extra distinction seems spurious to me. What is being required in the JPMS spec, and, I dare to suggest, what has been generally asked for by the public (and even required by the JDK), is a way to provide an additional capability - the ability to selectively share otherwise unshared code. The existing Java language accessibility model is (of course) well-understood by experts. For new developers, the concepts takes a bit of time to explain but can generally be grasped. In the end the accessibility of a member is generally easily determined by examining the qualifiers of that member. What has been proposed and implemented in Jigsaw is essentially a completely new approach to access checking. Because it is new, and because it is essentially untried, I predicted that issues would arise not unlike the ones being currently discussed. I argue that this approach is not optimal, for at least reasons discussed on this list and in this email, but that even now, it's not too late to change the approach. What infuriates me is that in all this discussion, I don't see anyone talking about a threat analysis. What are we trying to protect, from whom, and why? I see comments about how implementation details of the JRE (such as "com.sun" packages) must be hidden, but without reference to the threats that cause a problem. I've seen enough security issues about Java to believe that there /are/ threats that Oracle should be concerned about. And I'm happy to have Oracle hide ostensibly public classes in the JRE at runtime, because I want the JRE to have a smaller attack surface. At compile time, project Jigsaw makes total sense to me. A modularized Java makes sense, both because it highlights an excessive dependency tree, and because it can help reduce the footprint of the code. In other words, it isn't a security measure, it is a design tool. At runtime, though, does the JVM benefit from something more complex than a simply layering model? Layer 0 - the boot system, Layer 1 - the JRE, Layer 2-N - defined by the developer. I'm guessing in the server model, Layer 2 is the "container" (Servlet, Spring, etc.), and Layer 3 is the "application". However, I'm unable to assess whether my proposed JVM model meets the security requirements. Why? Because I've never seen the threat analysis spelled out or referred to on this list. Maybe such a document exists? With the simple layered model, almost all applications (except those that load JRE internal details either via reflection or direct linking) would continue to work as is. With the Jigsaw model, I feel like I have to assume everything will break, unless otherwise fixed. Hoping something about this will change. I propose, once again, that rather than changing the meaning of "public" to something unintuitive (and indeed counter to the definition of the actual word), we instead allow the selective extension of package-private. Users would make public any type or member which is *meant* to be public, i.e. accessible by all. Rather than (at best) changing their expectations as to the behavior of "public" only to immediately betray that expectation by forcing them through a backdoor in order to meet practical needs, we ensure that their expectations remain: public members are public, and things that are secret are not public. I think this is an interesting idea to consider. Except again, I'm unclear on what we're trying to protect from whom, and why? So I don't know if this solves the problem. Eric
Re: the acyclic module graph
You might have to be more precise in your example. The runtime could define interfaces and classes that app0 could implement / extend. The modularity isn't about execution exclusion, but rather about API visibility. Eric > On Dec 5, 2015, at 9:16 AM, Jochen Theodorou wrote: > > Hi all, > > in the sadly few hours of my spare time these days I am trying to understand > jigsaw better and I came across the condition that the module graph should be > acyclic... which made me wonder... > > > So Let us assume there is a module groovy.runtime and a module app0, which is > written in Groovy. groovy.runtime exports a equally named package for general > use. Since app0 is written in Groovy there is the high possibility that I > will have to invoke arbitrary methods from app0 from inside groovy.runtime. > Meaning app0 needs to give a read edge to groovy.runtime for app0. So app0 > depends on groovy.runtime and groovy.runtime depends on app0... is that a > cricular dependency that is forbidden... or was it only for compile time? > > bye Jochen
Re: Multiple Versions at Launch-Time
Hi Nicolai, On Tue, Oct 20, 2015 at 9:56 AM, Nicolai Parlog wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Eric. > > > Why not use OSGi? Or is that what you mean by a "container"? > I assume that the quote I gave uses "container" to mean systems like > OSGi (it's from Alan, maybe he will correct me if I'm wrong). So yes, > I mean that. > I am trying to find a way without OSGi because it looks like it is not > used for many projects (relatively speaking). But most projects > routinely run into problems with conflicting versions and it would be > great if Jigsaw could solve this for them out of the box. > OSGi is used for far more projects than Jigsaw is! I think you're far, far better off if you can avoid this problem. Even with OSGi, which is fully capable of supporting many different versions of a JAR file, to get it right requires some skill at designing for that type of modularity. You're unlikely to take any off-the-shelf library and get multiple versions loaded into a JVM successfully. Java is *very* leaky with interfaces crossing ostensible package boundaries. As I understand it, since what you're asking for is specifically out of scope, I don't think you're going to get a great answer here. Eric. > > so long ... Nicolai > > > > On 20.10.2015 18:10, Eric Johnson wrote: > > Why not use OSGi? Or is that what you mean by a "container"? > > > > Eric. > > > > On Tue, Oct 20, 2015 at 6:30 AM, Nicolai Parlog > > wrote: > > > > Hi! > > > > There have been a number of threads regarding loading multiple > > versions of the same module. The requirements say: > > > > "It is not necessary to support more than one version of a module > > within a single configuration."[1] > > > > The threads hence usually end like this: > > > > "The module system isn't suggesting any solutions, it is instead > > leaving this problem to the build tools and containers."[2] > > > > I can see how we can use class loaders (and now layers) to load > > multiple versions at runtime. This is essentially what containers > > do. > > > > Now I wonder, is there anything a build tool (or a dedicated > > developer for that matter) can do to launch the JVM with multiple > > versions of the same module? > > > > Running Example: > > > > App requires LibA App requires LibB version 2 LibA requires LibB > > version 1 > > > > One way I hoped to do this was to treat both versions as two > > different modules, i.e. renaming them and update the dependencies > > on them. > > > > App requires LibA App requires LibB_v2 LibA requires LibB_v1 > > > > This does not work because both modules would export the same > > packages. That's a little disappointing - I hoped it wouldn't > > matter because no module is reading from both versions. > > > > Since this failed I see no way to solve this aspect of JAR hell > > without containers. Does anybody else seen one? > > > > so long ... Nicolai > > > > > > [1] > > http://openjdk.java.net/projects/jigsaw/spec/reqs/#multiple-versions > > > > > [2] > > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-October/004787. > ht > > > > > ml > > > > > > > >> > >> > > > > - -- > > PGP Key: > http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 > > Web: > http://codefx.org > a blog about software development > http://do-foss.de > Free and Open Source Software for the City of Dortmund > > Twitter: > https://twitter.com/nipafx > > Diaspora: > n...@pod.geraspora.de > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWJnIhAAoJEMo7rS6czNUJkVkQAKsoySvjZGpWXo5P7hM9ePpf > N0iawy47qMEgeMYrgephHL/1mLyhfV7ISHDLjTCdNuLsUz1h26o4fQXy8gWfd192 > mN+q3iDQcXX9ub0NQQu8zh5GHd/8Y6Woi1dqPTaFNvRHEBFsAj7amnb0KkLO2uZz > KGX0gIRlOfzOC/atHWgusx2MBUoH4syDOSwhijNm0DiYLsxSDOAkJWZGsiwGrpK+ > 7cSE7mL5TOX2e6DI8dcW/nRMxUM5Zn5em5gi8dYc4LwfYlfjQ2Dz02QymJnOKqG7 > UdBrb+od24vepK6Re/a95yVDmpqDhwsF/4CZF+lzxZwtJhnJ9yQrPGKjPsDYs4Yq > T8zt/d9O0866zxzo00dM//wx57wPY0VEYdh0XfwveqmJTBYPFrKGqRzN6jUs8cMa > pdKAyq5iJ61A2jpI7KJ4Bk5Xo7OMxCT4uCVu6S1rTKym0lP7oNn1xiFMxtjgEuOE > fNFWQEYEM1iCVcmJ7PH25O9/C5sjsgzFwy/d2tWfKdDlyf5WVRVIHOYvjKrr+yBL > fDlueRRrvaxJhJOYHRJ1xRvmXDNVmFlbzxrnOQcK/nU7R8IwELwr6FfSteOl7WEt > 1qY6f0DuvIzhCg6GWt+Jm4wdeqDpYnmSpuDYDGtbMiFOfhJ0fCnqJwN3lR70FPNa > dopyg43RJIJXUXHm0+S0 > =s6OU > -END PGP SIGNATURE- > >
Re: Multiple Versions at Launch-Time
Why not use OSGi? Or is that what you mean by a "container"? Eric. On Tue, Oct 20, 2015 at 6:30 AM, Nicolai Parlog wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi! > > There have been a number of threads regarding loading multiple > versions of the same module. The requirements say: > > "It is not necessary to support more than one version of a module > within a single configuration."[1] > > The threads hence usually end like this: > > "The module system isn't suggesting any solutions, it is instead > leaving this problem to the build tools and containers."[2] > > I can see how we can use class loaders (and now layers) to load > multiple versions at runtime. This is essentially what containers do. > > Now I wonder, is there anything a build tool (or a dedicated developer > for that matter) can do to launch the JVM with multiple versions of > the same module? > > Running Example: > > App requires LibA > App requires LibB version 2 > LibA requires LibB version 1 > > One way I hoped to do this was to treat both versions as two different > modules, i.e. renaming them and update the dependencies on them. > > App requires LibA > App requires LibB_v2 > LibA requires LibB_v1 > > This does not work because both modules would export the same > packages. That's a little disappointing - I hoped it wouldn't matter > because no module is reading from both versions. > > Since this failed I see no way to solve this aspect of JAR hell > without containers. Does anybody else seen one? > > so long ... Nicolai > > > [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#multiple-versions > [2] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-October/004787.ht > ml > > > > - -- > > PGP Key: > http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 > > Web: > http://codefx.org > a blog about software development > http://do-foss.de > Free and Open Source Software for the City of Dortmund > > Twitter: > https://twitter.com/nipafx > > Diaspora: > n...@pod.geraspora.de > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWJkIPAAoJEMo7rS6czNUJKqcP/jCPBM5bhYbLg1iM04CshfKc > 5Ers7HvrnxEvES9wVEFkM2MMCieNwZfK5FCuKUWoM3nwxjbU4rgG6tzRwxfUphky > mMIcfUaqUPzBBaA/rtdk7NVhwMv4fK45eaylL/1LpH0xgSbBgTN4FnqMRKiLuKNJ > yPZAbXHwhAGjDIEUjdxcenmS494CJHNcI2QgR1onC2kEBZe0r+rH48WQwncMq9dy > WKetJi8U5uCUpBGAs+7Qi6GbAMIY03t4Vlb5+13hgvjkvX9bY6T47Ey1wC85Lx+X > OzTrktnJxzaQQNeqsLcYfvLRW9kEWj+N178He7+IWffBVDZCwdEeErZUWrbAwHKe > 2o6iFYxtDoU/NzviniL+kUPcmi4dUsO/953HhCAjIET2DJRh2Jr3DrJ+eoVvdKZD > 0EkCaO1tpo4QJXiu3aM1f1qFbZj6QaYb2YQSqsUllc+9n4nzDCH2QS69Y9Q5dO3s > Gu7pfsAGBLUESyIWaVhiIQQ5jxsoTUvSbG5dn/NfGO10qeewmBdOpuvCJPptr9UP > 5l/aCUz6PL6PRPN2B/iPkc6I1jkq3lAzd+FtvKZ6CI4RAfKMOKBkrQ7jiLz3SAVY > 2jV6vAizHQBF8UPpA+HJOgUue9WNJrLPD7LpeOpmlamwaRSRIiE5j2goFMAp2QC5 > 4AybhvOsjbM65c/CmWpV > =XAwk > -END PGP SIGNATURE- > >
Re: JEP 200: The Modular JDK
Thanks for sharing that with the jigsaw-dev mailing list. Quick question: Why does this JEP need to make assumptions 4, 5, and 6? Seems like assuming existing classpath semantics is good enough for this JEP. Seems like these additional constraints just bring in a lot of text about re-exporting, when, for the purposes of modularizing the JRE & JDK, such technical details could be left to the module system, rather than here. Did I miss something? Eric. On Tue, Aug 5, 2014 at 9:49 AM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/200 > > - Mark >
Re: Modularization [was: Jigsaw prototype, take 2]
On 9/6/13 7:33 AM, Tim Boudreau wrote: A lot of the things on that list above are orthagonal. Yes. Eric
Re: Jigsaw prototype, take 2
Hi Mark, On 8/28/13 9:27 AM, mark.reinh...@oracle.com wrote: We remain committed, of course, to this Project's high-level goals: Create a modular and scalable platform, improve performance and security, and define a standard module system. Repeating the same thing over again, and expecting a different result? I'm all for modularizing Java. I'm struggling with the other goals: Improving security: Certainly, we don't want modularization to weaken security, but why is necessary for improved security to be a part of the Jigsaw project? It should be treated as a separate concern (which it is). On top of that, improving security implies a well understood threat model, vulnerabilities, and risks. Since Java is run in so many different places - secured networks, insecure networks, mobile devices, desktop/laptop machines, and via applets, the considerations for each might be radically different. Deserves more careful consideration than as an add-on goal to a modularization project. Only insofar as a modular JRE could exclude all sorts of unneeded/unwanted pieces from particular profiles, that is by definition improved security for downstream deployers, but that's a side-effect of modularity, not a specific goal. Of course it may be a side-effect informed by security considerations (for example, remove JMX, JDBC, CORBA, and applet support from a mobile device), but it isn't, by itself a more secure platform. That's because there will still be deployments that need everything, and modularization by itself won't have changed a thing. Improve performance: Again, modularization shouldn't lose performance. Don't see why it would be an explicit goal to improve performance. As a colleague of mine says, "first get it right, then make it work, then make it fast." Seems like you're jumping ahead to step three with this goal. Define a standard module system: Why? One way of leveraging a modular Java means taking the existing JRE, repackaging it, and removing unwanted parts. That's a building/packaging exercise, and has no run-time implications. So why define a module system? Java already has a standard way to "modularize" a build, via these well known artifacts called "JAR" files. Eric.
