| Please do feel free to connect offline if you need some help making inroads into the JavaFX community. I have long standing friends there that would be happy to welcome you into that community.
Standardizing YAML in Jakarta EE is a worthy topic, but I am afraid it’s a bit too early for the Jakarta EE 10 time horizon and perhaps beyond. I would say stay tuned here and see if there is eventual interest from the major vendors. I think gRPC is a good topic worth discussing in the MicroProfile community, but again it may be a bit too early. The best course of action there too may be to simply stay tuned and see if there is any traction independent of yourself. Werner is correct that engaging with the JSON and XML binding related communities under Jakarta EE might make sense. I think if you have specific feedback or enhancement ideas for those communities, that is most helpful.
Hope this helps? Did you have other specific areas of Jakarta EE you had specific questions on? Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. On Mar 27, 2021, at 5:20 PM, Hohwiller, Jörg via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:
Dear Werner,
thanks for your detailed response. I always love feedback and it
is not discouraging in any way.
Thanks for pointing me to JSR 377, I try to get in touch with
people working on this. I am not a JCP Member at all but "just" an
addicted open-source Java developer.
Indeed mmm-ui-* is fully focused on frontends (not only desktop)
and if I understood correctly JakartaEE seems to be the wrong
place for these kind of topics (I was not aware that it is
"backend only", from JavaEE history I understood its all about
enterprise and from my business background frontends are still
very relevant for enterprises but Java is loosing importance in
the frontend and therefore on the long run also in the backend as
fronend developers then also tend to suggest NodeJS and NestJS
backends for instance. That is actually the reason why Microsoft
heavily invests into Blazor fromework to keep .NET/C# in the
market.). I do not know if Java still has a place to discuss
overall standardizations but I can try to get in contact both with
JavaFx and Oracle teams.
In my initial post I was also suggesting to discuss about https://github.com/m-m-m/marshall.
If I am not mistaken JSON-P is a JavaEE standard. So thinking
beyond JSON could be worth a thought. If that is also wrong here
it seems I have a wrong understanding of JakartaEE. However, I can
try to get in touch with JSON and Validation developer mailing
lists and try my luck there.
p.s: I could explain my project structure, versioning, history,
and whether ideas are too late or not, but I think this would also
be quite pointless here. In case anyone is really interested in
this get in touch with me on my project on github. For the record
I also raised my ideas five years ago in Java forums and people
were saying that my plans will never work out, others have already
tried this and failed utterly and I should show up if it really
works. Now it really works and my PoCs already show an impressive
potential. So I will try other places to find alliance.
Thank you for having a look and considering some chances.
Cheers
Jörg
Am 27.03.2021 um 16:07 schrieb Werner
Keil:
Jörg,
I don't want to discourage you but I don't see a lot of
your libraries using Jakarta EE yet, so maybe this could be
the wrong list to advertise it?🤔
Making heavy use of the "Jigsaw" JPMS is a good thing at
least in my opinion but I got quite confused between "base",
"main" and "core" among all your modules sometimes. It also
seems quite odd, that it is still at 0.2.x after more than 20
years (the copyright header says 2001-2021)
Many of those ideas probably come late, the biggest overlap
seems with JSR 377, which not very surprising is now dormant:
https://jcp.org/en/jsr/detail?id=377,
I can't say if you are a Full JCP Member already nor if 377
could ever leave the dormant state, but most of the modules I
see in your library are much more desktop or "RCP" focussed
and only very few of them have anything to do with Jakarta EE.
The "config" module but there are already many "cooks"
involved in that kitchen, so it could be a little late there,
but stay tuned and maybe subscribe to some of the detail "dev"
spec lists for JSON, Validation or (if it came into existence)
Jakarta Configuration.
For all the other stuff like JavaFX or JEPs, you're just in
the wrong place here.
Dear
JakartaEE Community and Experts,
I started on slack and was suggested to send to this mailing
list.
Still I hope I am not misplaced here, but I would like to get
in touch
for what I have created in my OSS project:
https://m-m-m.github.io/
It might look like yet another Java framework but this is
really a
marvellous approach to let Java rock.
Maybe I can find some people here in order to find ways
getting this in
a broader direction and potentially brining in some parts as
JEPs,
candidates for JakartaEE, etc. or so.
In a nutshell, I have created a universal UI API using Java
Interfaces:
https://github.com/m-m-m/ui-api#mmm-ui-api
Then I created implementations for that like ui-fx that allows
to run
the Frontend using JavaFx on the desktop, or ui-tvm to
cross-compile it
to JS or WASM and run it in the browser, also I am working on
ui-android
and there is ui-test for simple JUnit testing of the UIs
without complex
mocking but design for testability.
So with one code-base you can reach all channels.
There are also smaller modules that could be interesting like
mmm-marshall that allows marshalling and unmarshalling to any
structured
format such as JSON, YAML, XML, ProtoBuf from one code. Maybe
that one
could be the starting point to shape a future JakartaEE
standard if
others agree that the idea is good...
Also there is a minimal but very powerful API like Localizable
(https://github.com/m-m-m/base/blob/master/core/src/main/java/io/github/mmm/base/i18n/Localizable.java)
that may be a candidate for a JEP to add to a future JDK
version.
Currently this is fully implemented in mmm-nls. But JDK
MessageFormat
could be extended to ship an implementation directly with the
JDK.
Might all be too much at once and overwhelming or
over-ambitious, but I
hope to find people who are interested to get into discussion
for making
Java even better :)
Thanks in advance...
Jörg
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________jakarta.ee-community mailing listjakarta.ee-community@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
