Modules with platform specific parts

Tue Sep 28 07:52:07 UTC 2021

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 <greggwon at 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.audet at 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.audet at 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.vos at gluonhq.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Sep 16, 2021 at 2:55 AM Samuel Audet <samuel.audet at 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
>>>>> 
>>>> 
>> 
> 