Re: Alternative to fatJar - modular solution?

as the mobile code interface to remote services. It really feels like Oracle and the Java team have no interest in what the desktop environment represents… Gregg Wonderly > On Oct 7, 2021, at 7:41 AM, Glavo wrote: > >> >> *Bandwidth optimization and rare machines.* This is i

Re: Modules with platform specific parts

more portable and dependable software systems. Gregg Wonderly > On Sep 27, 2021, at 7:07 PM, Samuel Audet wrote: > > Android actually includes OpenJDK these days, still only OpenJDK 8 at the > moment, but it is a project downstream to OpenJDK, so in my opinion Google > shou

Re: JMOD, native libraries and the packaging of JavaFX

Yes, I, like many others have carried around various JNI code in jar files (javax.comm and my own as well), and then copied these out of the jar, into “temp” space, and then used load() to load and bind them in class wrappers. This works quite well, but it is highly customized in how it’s

Re: The baby and the bathwater

I think that Stephen is largely announcing that JigSaw presents more problems than it solves for the community. My list of issues, which I have shared before, goes basically like this. 1. Modules should have versions which new tooling on community toolsets could use for managing details like

Re: why is modularity changing the rules of inheritance?

This is pretty much what was lamented about on the list as the project proceeded. In the end, the restrictions you see are because all the system classes in the Java VM implementation need to be protected in this way to provide the opportunity for evolution of the implementations underlying

Re: Main class in jar

users to use the application. Installers are just not something that we need to start the path to have to support cross platform… Gregg > On Mar 5, 2018, at 9:40 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 05/03/2018 13:58, Gregg Wonderly wrote: >>

Re: Main class in jar

Will java -jar note that the argument is a module and help the user understand how to invoke it, or will it just complain about a missing main-class: attribute? From a practical perspective, why does it matter and demand a different command line? What happens when you double click on a

Re: Module naming for logging implementations

I’d like to reverse this dependency to be that in the end, I want every module in the app I construct to funnel through and use a single Logging implementation so that I can linearize the logging streams into a single stream of details that help me to understand the health and progress of my

Re: Some suggested patches and improvements

> On May 17, 2017, at 3:08 AM, Andrew Dinn <ad...@redhat.com> 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 o

Re: Some suggested patches and improvements

At some level, this is the problem that is paramount on the release of JDK-9. Earlier Mark asked if the Eclipse foundation had to approve or be ready to support all of what JDK-9/Jigsaw supports before it could be released. The statement below seems to stipulate that “all Java software must be

Re: An alternative to "restricted keywords"

Or, would it make sense to make the module name require quotes around it? The subtlety of this notation looking JSON like, and yet being something new, makes me wonder if it should not just be a JSON based structure module : [ { m : {

Re: Need help implementing Java modules

> On May 10, 2017, at 1:58 PM, Alex Buckley wrote: > > On 5/9/2017 5:20 PM, Ralph Goers wrote: >> Log4j already has a robust plugin approach for users to implement >> their own Appenders, Filters, Layouts, and other Log4j components. We >> are not going to modify that

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

If there is not already such an exception, it would seem like a good idea to have an exception that formats such a message from constructor parameters providing the details so that it’s the same everywhere, and so that it can be changed in once place if needed. Gregg > On May 3, 2017, at 9:48

Re: Huge implications of multiple class loaders for application modules

> On Apr 25, 2017, at 8:44 AM, David M. Lloyd wrote: > On 04/25/2017 08:31 AM, Alan Bateman wrote: >> On 25/04/2017 14:16, Michael Nascimento wrote: >> >>> : >>> and also the fact >>> packages must be defined by a single module even if they are not >>> exported, >>>

Re: Disallowing the dynamic loading of agents by default (revised)

I really believe that we can't really flip off working applications with a JDK upgrade. It's developer and deployed cooperation no matter which way the switch are by default. Starting with unknowing developers, deployed and users having to suffer through discovery of what will it take to make

Re: SecurityManager environments

> > On Apr 6, 2017, at 2:07 AM, Alan Bateman wrote: > > On 05/04/2017 20:53, Reto Merz wrote: > To be honest, we don't see a lot of security manager usage on the server side these days. >> >> I'm really surprised about that. How can a app server or servlet

Re: SecurityManager environments

> On Apr 5, 2017, at 12:53 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 05/04/2017 16:26, Gregg Wonderly wrote: >> : >> At the forefront of the failure of the SecurityManager to be an avidly used >> element of Java applications, is the simple fact

Re: Disallowing the dynamic loading of agents by default

> On Apr 4, 2017, at 10:45 AM, Andrew Dinn <ad...@redhat.com> wrote: > > On 04/04/17 15:58, Gregg Wonderly wrote: >> Alan said: >> >>> The issue here is nothing to do with the security manager, assume >>> no security manager in the picture.

Re: Disallowing the dynamic loading of agents by default

> On Apr 4, 2017, at 4:36 AM, Andrew Dinn <ad...@redhat.com> wrote: > > On 03/04/17 21:56, John Rose wrote: >> On Apr 3, 2017, at 12:03 PM, Gregg Wonderly <gregg...@cox.net> >> wrote: >>> >>> Alan, it is exactly this kind of comment from

Re: Disallowing the dynamic loading of agents by default

> On Apr 4, 2017, at 8:02 AM, Alasdair Nottingham > wrote: > One of the problems Java has today is that it is very easy to end up > depending on internals > because the JVM has no modularity. It is one thing to end up using a Java API > that is > visible, but

Re: Disallowing the dynamic loading of agents by default

Again, I want to stress that from my position we are completely ignoring desktop Java users who will update Java to JDK 9 and never know that they’ve broken something by doing that. Java is not a server only enterprise deployed environment… Gregg > On Apr 2, 2017, at 6:39 PM, Stephen Felts

Re: Disallowing the dynamic loading of agents by default

break applications that they are using, and how will those users resolve the problem themselves? Gregg > On Mar 30, 2017, at 4:30 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 30/03/2017 20:47, Gregg Wonderly wrote: > >> Mark, what is the plan fo

Re: How to become a "cooperative troubleshooting tool"?

There has been some discussion on this list which I have never been satisfied with around why the SecurityManager was not used for a large number of the things that are being done with literal JVM changes. Mark Reinhold and others, I believe, don’t know how to use the SecurityManager, or

Re: Disallowing the dynamic loading of agents by default

Mark, what is the plan for people with .jar files on their desktop who just double click on them to run desktop applications? How will they know that their upgrade to Java 9 broke the application and how to remedy the problem by either getting a java-9 compatible version of the app (which will

Re: Better tools for adjusting to strong encapsulation

Better yet, why aren’t the java.util.logging apis used for stuff like this? It seems strange that there is not a nice compact formatter, yet, standard in the JDK. The logging APIs seem highly neglected given that even the varargs access has not been fixed so that you can use varargs without

Re: Reusing module name token `*` in -d

I think this is an important detail to consider as well. If -d’s argument will now have an implied subdirectory before the class hierarchy, simple Java applications/deployment tools will break, unless the JVM knows exactly what to do about this. However, think about the case where I am

Re: New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

I find this text much more demonstrative of the needs of the many. Thanks for continuing to work through things with the community and understand needs that we all have for a good path forward which allows everyone to use JDK9 and for the future to hold a much better view of encapsulation

Re: Privileged module idea

Re: Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

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 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

Re: Multiple versions of a non-exported dependency

is what “Version” points to. Gregg > On Sep 1, 2016, at 10:12 AM, Gregg Wonderly <gregg...@cox.net> wrote: > > Why I was referring to is how will modules find classes from other modules? > How will the different version of the same package namespace that Gili was > ta

Re: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

Sent from my iPad > On Aug 4, 2016, at 11:18 PM, Alan Bateman wrote: > >> On 04/08/2016 10:33, Patrick Reinhart wrote: >> >> Hi Paul, >> >> I was quit busy lately and this comes a bit late, I guess you do not have >> less work ;-) >> >> On 15.07.2016 17:10, Paul

Re: Issue with qualified exports

Would it not be better to provide an option for people who need to do this level of validation so that there might be an option such as —validate-module-presence=B instead to make it possible to get the validation, but not have to do this for common, simple developer builds, but it could be

Re: Issue with qualified exports

I agree, this is not very module like if we are building dependencies to export targets. This is another reason, for me, that this feels wrong. I am just not sure I understand why we care so deeply for “authorization” to use code when there are so many (nearly countless) ways to exploit the

Re: It's not too late for access control

> On Jul 15, 2016, at 3:10 PM, Claes Redestad <claes.redes...@oracle.com> wrote: > > > > On 2016-07-15 20:24, Gregg Wonderly wrote: >> >>> On Jul 14, 2016, at 6:23 PM, Eric Johnson <e...@tibco.com> wrote: >>> >>> At least someone

Re: Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

> On Jul 14, 2016, at 6:51 AM, Andrew Haley wrote: > > On 14/07/16 11:28, Alan Bateman wrote: Yes, indeed, and that is potentially a significant problem. My comment stands: there is a serious possibility that his will make it impossible to use (non-exported)

Re: It's not too late for access control

> On Jul 14, 2016, at 6:23 PM, Eric Johnson wrote: > > 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

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

and why is it that everyone will have to deal with it, if those developers are not 90% of all developers benefiting? Gregg Wonderly > On Jul 8, 2016, at 4:42 PM, Paul Benedict <pbened...@apache.org> wrote: > > For those who are still supporters of preventing non-exported typ

Re: Mutable modules

The runtime environment needs to have a way that developers can impose version consistencies that make sense. In some cases it is just data consistencies which can be managed literally with data construction. But when code versions are mixed in with data versions, the runtime context needs

Re: modulepath spec

Will there be a recursive Jar: content mechanism so that there can be a single file object representing an entire application and all of its dependencies? Gregg Wonderly Sent from my iPhone > On Dec 7, 2015, at 10:46 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > >> O

Re: Conflicting module versions

On Feb 9, 2015, at 9:18 AM, David M. Lloyd david.ll...@redhat.com wrote: Comments inline. On 02/06/2015 11:17 PM, Gregg Wonderly wrote: I'd personally prefer that a dependency graph with branches such as A-C A-B.v1 C-B.v2 be resolved with both version of B loaded and a ClassLoader

Re: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9?

, complete with designation of parent class loaders. It's been a large pain for a lot of people. Gregg Wonderly

Re: Support for jrt-fs.jar in JDK 7 would be very helpful in allowing FindBugs to run under Java 9

that have manifested from there only being a single, closed system for UI improvement. Gregg Wonderly On 11/16/2014 7:47 AM, Remi Forax wrote: On 11/15/2014 11:18 AM, Alan Bateman wrote: On 14/11/2014 16:34, Bill Pugh wrote: Following up on a email thread started by Dalibor Topic… In short, back

Re: Jigsaw prototype, take 2

is actually needed. Dependencies should be a primary thing as part of the development process, and development time dependencies should not become the deployment time dependencies. Gregg Wonderly On Sep 6, 2013, at 10:22 PM, Tim Boudreau niftin...@gmail.com wrote: Gregg, We've worked together and I

Re: Jigsaw prototype, take 2

that Java is not desirable for anything other than large scale application deployment. Gregg Wonderly On 9/4/2013 9:44 PM, Neil Bartlett wrote: And yet, JEP 161 addresses the most pressing requirement from Java developers: a smaller, more embeddable JRE. Furthermore it actually seems