Hi Gregg, I am afraid that train is long gone. Once OpenJDK decided the preferred distribution mechanism for Java applications is to embed the runtime, the notion of Java Platform that would allow installation/execution of platform neutral software packages is gone. Bytecode is no longer fashionable as software distribution format - there is much more interest in AOT and distribution of native binaries (Leyden, Graal etc.). I guess we need another couple of years for the current cycle to pass and the industry to rediscover the same old thing again.
Looks like WASM is now the go-to solution for what you want. Michal > On 28 Sep 2021, at 05:21, Gregg Wonderly <gregg...@cox.net> wrote: > > In the end, much of what happened after JDK8 has served to do more at > separating and fragmenting the Java platform than even Android does with a > different runtime for the same textual programming constructs. I’d be > extremely interested in seeing the community focus on getting back to the > focus on write-once, run anywhere as was promised early in the life of Java > when it’s design was one of simplified memory management and unified, > consistent OS interfaces. Android demonstrates that the Java language design > is portable to a separate runtime. But, so much of the Java promise has left > the building. The people involved in the evolution of Java are only focused > on server level performance and large scale software performance constructs, > instead of providing a software system that is portable and usable for > desktop applications where portability across OS is the huge win for Java. > Instead of Java winning on the desktop, everyone now considers Java a server > only system. The fiasco of JDK2.0 drove huge numbers of early adopters away > from Java because they could not get their desktop apps to become functional > based on their expected timelines. Then, we had the JMM creating hoisting > nightmares that invalidated all kinds of software that had not been > malfunctioning due to missing ‘volatile’ declarations. Now, we have lots of > development teams who have the mantra that every class level variable should > either be final or volatile by default because future dev might turn on > non-volatile optimizations that break the software. > > All kinds of other nuances of missing broad focus on language design and > implementation have created a pretty large set of circumstances that have > distanced Java from having near the impact it could of had of finally > providing more portable and dependable software systems. > > Gregg Wonderly > >> On Sep 27, 2021, at 7:07 PM, Samuel Audet <samuel.au...@gmail.com> 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 >> should definitively be part of the discussion. >> >> That said, it's not only Google's fault here, and let's not get into the >> politics here, but even if Android didn't bundle OpenJDK, and we had to >> install it like on other platforms such as Mac and Windows, it is still a >> platform in its own rights with its own particular characteristics that we >> need to take into account. Although it is based on Linux, the kernel, it is >> not the same "Linux" as Fedora or Ubuntu, and if OpenJDK is to go anywhere >> in the future, it has to start considering the needs of Android, regardless >> of the political issues. >> >> Now, in the case of Android, it sounds like what you are proposing is to >> create and maintain a set of tools parallel to Android Studio, but that >> would also work with iOS, etc. Where do you see the funding come from to >> keep up with all the features of Android Studio? Even Microsoft is having >> trouble with Xamarin, their C# attempt at doing this... Frankly, I don't >> think that's the right way to go about it, but I do think that's the kind of >> discussion we need to have! >> >> Samuel >> >> On 9/27/21 5:38 PM, Johan Vos wrote: >>> I'd be happy to see Google joining the discussion, but Android (as in the >>> Java "clone") is totally unrelated to OpenJDK so I think it is unlikely to >>> see relevant input from that side. >>> However, OpenJDK works great on Android-devices (and can be used to create >>> Android apps and upload them to stores), so *developers* targeting those >>> devices are covered. >>> What I hope to accomplish is to first of all get a discussion about the >>> potential options for developers dealing with platform-specific (native and >>> Java) code. It would be great if there was support at the specification >>> level for this best-practice, but that is probably something for the longer >>> term, as it will require more resources and lots of analysis, to make sure >>> backward compatibility is not broken. >>> - Johan >>> On Fri, Sep 17, 2021 at 12:52 PM Samuel Audet <samuel.au...@gmail.com> >>> wrote: >>>> I certainly hope so! But I don't see anyone, for example, from Google >>>> representing Android, so what do we hope to accomplish, exactly? Let's >>>> start by making the goals clear. >>>> >>>> Samuel >>>> >>>> On Thu, Sep 16, 2021, 16:35 Johan Vos <johan....@gluonhq.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Sep 16, 2021 at 2:55 AM Samuel Audet <samuel.au...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> If it wants to remain relevant, OpenJDK should really consider having a >>>>>> broader discussion about this. >>>>>> >>>>> ... >>>>> >>>>>> Please, please, do consider fixing the JDK instead of talking about >>>>>> coming up with incompatible "solutions"! >>>>>> >>>>> >>>>> I totally agree, but I believe this is exactly what we are doing now? >>>>> >>>>> - Johan >>>>> >>>> >> >
