important discovery about a probable refactoring in jvm or OS

[Peter Lawrey]

Hello Christian,
   Some quick thoughts.
- while fibres are an important feature I have never found a use for them
in my space due to them being too expensive. I assume there are some very
good use cases for them but the growing number of cpus in a server might
make this less important.
- i agree on unsigned esp 128 bit. Unsigned char is not enough and why byte
is unsigned i van only assume is historical. Unsigned operations are
supported using the wrapper classes.
Personally, i feel BigDecimal should have language support ala C#.
- i think java will evolve to allowing multiple inheritance of classes but
its not needed most of the time. Esp with enhancements to interfaces.
- the JVM already inlines methods and there is an @ForceInline however it's
not for public use afaik.
- the byte code at compile time isn't as important as the code it compiles
to at runtime. Lambdas do take a hit before they warm up and making
capturing lambdas not create garbage is a pain.

I would point out that of the top languages, Java is one of the newest.
What it really needs is features older languages take for granted and are
widely used and understood eg structs.

https://www.tiobe.com/tiobe-index/

Regards Peter.


On 24 Dec. 2017 2:41 pm, "Cristian Lorenzetto" <
cristian.lorenzetto at gmail.com> wrote:

As i descrived in this place https://github.com/boostorg/fiber/issues/161

It is impossible to use JNI interface when c++ code is executing  native
fibers/courotines (calling a java callback). Pratically in future all new
software will use fibers instead threads so java will get a prison.
It is necessary to re design JVM with many changes

c++ native fibers might be the java threads so JNI continue to works

In addition i suggest
- to add new data type for unsigned number
- multyhierarchy (
parent classes can't have a common ancestor(except trially Object class).
This permits to evoid data inconsistency as explained also in Kotlin) This
is the just limitation for evoiding inconsitency.
- inline functions
- redesign lambdas compiler engine to trasforming lambda classes in inline
code (see stackoverflow ho many developers proved the bad bytecode
generated by actual javac)

Pay attention ! Java could die if it doesnt follow the modern software
needs! you can see already now many jdk new languages trying to skip the
java language , but if you talk with the languages teams you can see all
tells JDK doesnt permits do do many things others VM permits(in primis
class multi hierarchy). Java must change before developers change language!