[Development] Repository request: qt/qtbridge-java

[Volker Hilsheimer]

For a general idea of what we are trying to achieve with Qt Bridges, read Vladimir’s blog [1] from May, following the announcement of the plan at Qt World Summit:

https://www.qt.io/blog/about-the-new-qt-bridging-technology

And here’s a recording from this year’s KDE Akademy [2] (including the technical mishaps):

[2] https://www.youtube.com/watch?v=yEZnwkCLa44&list=PLsHpGlwPdtMrmR5QxoSYGbuiy2we0uMmt&index=2

We don’t have a recording of the Qt Contributors Summit this year where we also talked about Qt Bridges as part of the roadmap re-cap, and in a dedicated session [3].

[3] https://wiki.qt.io/QtCS25_-_Using_Qt_Quick_with_other_programming_languages

Perhaps this helps a bit with the context.

Both the blog and Qt CS are from May, at which point things were still in a very early stage. The teams have now pushed the development to a point where we have something to show for each of the languages, which is a good time to start moving the work under the open governance and contribution model of the Qt Project.


Volker



> On 9 Dec 2025, at 13:47, Juha Vuolle <juvuolle at gmail.com> wrote:
> 
> Hi Thiago,
> 
> I believe there may have been some softness in terminology, I'll try to clarify.
> I'll reply from a Java/Kotlin point of view because the details vary
> per bridged language.
> 
>> Are users going to write actual Java
> Yes - users write normal Java/Kotlin apps, using their usual
> toolchains and IDEs.
> 
> Some of their classes, functions and properties can be exposed to QML, and the
> bridge handles the communication between Java and QML through C++/JNI.
> From the developer’s perspective, the C++ layer is an implementation detail
> they never need to interact with.
> 
> Terminology-wise:
> - 'bridged' language is Java/Kotlin (the user's application logic)
> - 'bridging' language is C++ (internal implementation of the bridge)
> 
> Java/Kotlin Bridge provides the handful of annotations and APIs for
> users to mark what&how they
> want to expose/bridge from Java to QML. They annotate normal
> Java/Kotlin classes.
> This includes things like variables, callbacks (~signals), and
> invokable functions.
> 
>> When I read "application logic to Qt Quick application", I think of the C++ backend of that application
> Yes, conceptually this replaces the traditional C++ backend of a Quick
> application.
> But bridge is not a traditional 'binding API' where we 'expose Qt to
> Java'. But rather it's that we 'expose Java to QML'.
> 
> Trivial example (subject to changes):
> 
> MyType.java:
> @Registrable
> MyType {
>    public void doStuff() { /**/ }
> }
> 
> Main.qml:
> import MyQtBridge
> 
> MyType { id: mt }
> Button { onClicked: mt.doStuff(); }
> 
> On Mon, 8 Dec 2025 at 22:42, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> 
>> On Monday, 8 December 2025 09:34:49 Pacific Standard Time Cristián Maureira-
>> Fredes via Development wrote:
>>> Hey Thiago!
>>> 
>>> What I meant with the description
>>> was that we are trying for the module to be as close to Java,
>>> without imposing C++ or Qt code patterns.
>>> 
>>> By "bridge language style" in this case, we meant "Java coding style".
>> 
>> So you're not bridging to Java, you're bridging to Java developers, by making
>> the coding easier for them to get comfortable with.
>> 
>> Python I would understand, since it's a completely different syntax, what with
>> whitespaces being meaningful and the absence of the increment operators. But
>> Java uses the same syntax as C and C++. So how can we get anything closer to
>> Java that isn't Java itself?
>> 
>>> Since the description is the same for the other languages,
>>> an example could be to use decorators, pragmas,
>>> properties, observables, when possible, to replace
>>> some of the Qt functionality that due to its C++ nature
>>> might look strange for 'the bridge language' users.
>> 
>> "Bridge language" is the language with which you implement the bridge itself.
>> Given that these are qt/* projects, those should be C++. Did you mean the
>> language on the other side of the bridge, that is, the "bridged language"?
>> 
>>> If with my explanation, the meaning was better understood
>>> and you have a suggestion in the description, please let me know :)
>> 
>> I don't understand at all.
>> 
>> Are users going to write actual Java, Python, or Swift or Rust? When I read
>> "application logic to Qt Quick application", I think of the C++ backend of
>> that application, which would imply that's what you're replacing. I don't see
>> how you can do that without going all the way: there's no hybrid of C++ and
>> Python syntax. You're either C++ (where "++" is the increment operator) or
>> you're Python (where "++" are just two pluses together not separated by
>> whitespace).
>> 
>> Or are we talking about the language that goes inside of .qml files, replacing
>> JavaScript? How faithful is this meant to be for the actual language? How much
>> of the standard libraries of those languages is this going to offer, because
>> people wouldn't use the JS one?
>> 
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>  Principal Engineer - Intel DCG - Platform & Sys. Eng.
>> --
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
> -- 
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development