> De: "Jesper Steen Møller"
> À: dev@groovy.apache.org
> Cc: "Remi Forax"
> Envoyé: Mercredi 19 Octobre 2016 01:15:47
> Objet: Re: Lambda expression for Groovy 3
> "Real lambdas" with the full invokedynamic treatment is a big job, and
> requir
- Mail original -
> De: "MG"
> À: "dev" , "Remi Forax"
> Envoyé: Jeudi 8 Mars 2018 23:55:11
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
> Hi Remi,
>
> I have used Groovy exclusively for the last years,
- Mail original -
> De: "Jochen Theodorou"
> À: "Remi Forax"
> Cc: "dev"
> Envoyé: Lundi 16 Avril 2018 22:28:58
> Objet: Re: Building Gant
> On 16.04.2018 21:38, Remi Forax wrote:
> [...]
>> the support of version 5
> De: "paulk"
> À: "Remi Forax"
> Cc: "dev"
> Envoyé: Lundi 3 Septembre 2018 00:26:27
> Objet: Re: Support of Java 11 using ASM 6.2.1 and ASM 7
> Hi,
> Groovy 3.x snapshots use ASM7_EXPERIMENTAL. For Groovy 2.5.x, the current plan
> (subj
Hi Paul,
ASM 9.0 have been released this morning.
regards,
Rémi
> De: "paulk"
> À: "Remi Forax"
> Cc: "dev"
> Envoyé: Lundi 21 Septembre 2020 08:19:47
> Objet: Re: Next releases
> Thanks for the update Rémi. I saw the version number comm
- Mail original -
> De: "Jochen Theodorou"
> À: dev@groovy.apache.org
> Envoyé: Vendredi 1 Avril 2016 18:02:18
> Objet: Re: About the syntheticPublic property of member method node in class
>
>
> On 01.04.2016 17:50, daniel_sun wrote:
> > Hi List,
> >
> >The following code is c
Just a note,
Java has exactly the same bug when loading a class (at least Java before 9),
when a class is not found, the classloader throw a ClassNotFoundException which
may be catched by another classloader down the stack.
The JIT (c2) even try to optimize such case by avoiding to fill the stac
Hi Jochen,
javac doesn't allow you to compile a code with -source 1.7 and -target 1.6
you have to use a tool like ASM for that and i think it was rule out by Cedric
or Guillaume.
cheers,
Rémi
- Mail original -
> De: "Jochen Theodorou"
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Juil
- Mail original -
> De: "Jochen Theodorou"
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Juillet 2016 21:51:18
> Objet: Re: JDK 9 Jigsaw builds
>
> actually, I think I did see somewhere that JDK9 will support only 8 and
> 7 as targets. Maybe someone can confirm that.
not at all !
It
Gradle thinks it can hack the classpath by seeing the application classloader
as an URLClassLoader.
The application classloader is now something that loads modules, so it's not a
subclass of URLClassLoader anymore.
Rémi
- Mail original -
> De: "Jochen Theodorou"
> À: dev@groovy.apache.
dle.internal.reflect.JavaReflectionUtil.method(JavaReflectionUtil.java:224)
>> [12:00:28][Gradle failure report] at
>> org.gradle.internal.classloader.FilteringClassLoader.(FilteringClassLoader.java:49)
>> Which doesn't seem to be URLClassLoader related.
>> 2016-09-18
Env(WrapperProcess.java:110)
> Is this "feature/bug" going to be fixed? Is there any way to disable that
> behavior?
> 2016-09-18 15:03 GMT+02:00 Remi Forax < fo...@univ-mlv.fr > :
>>> De: "Cédric Champeau" < cedric.champ...@gmail.com >
>>>
The real question is why Gradle want to modify the environment of the current
process given that ProcessBuilder::environment() exists.
Rémi
> De: "Remi Forax"
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 16:59:32
> Objet: Re: TeamCity back on track
imanche 18 Septembre 2016 19:09:13
> Objet: Re: TeamCity back on track
> On 18.09.2016 15:03, Remi Forax wrote:
> [...]
>> This one is a new bug/feature,
>> it's part of what we have called 'stronger' (not strong) encapsulation
>> i.e. most of the classes
yes,
note that there are still discussions in the Expert Group (that's one of the
reasons the jdk9 release was delayed) so everything is not settle but i don't
see the stronger encapsulation being something rejected.
cheers,
Rémi
> On Sun, Sep 18, 2016 at 7:56 PM, Remi Forax <
- Mail original -
> De: "Jochen Theodorou"
> À: dev@groovy.apache.org
> Envoyé: Dimanche 18 Septembre 2016 21:14:51
> Objet: Re: TeamCity back on track
[...]
>
> so setAccessible is forbidden, but a subclass from a different module
> can access the method... strange new rules. Anyway...
party library doesn't let a lot of option
apart fixing the library itself or removing the use of it. But the future i see
if we don't do that now is the death of innovation of the Java platform.
regards,
Rémi
> 20
I would say Groovy Closure with the Java syntax.
Rémi
On October 18, 2016 8:21:34 PM GMT+02:00, Guillaume Laforge
wrote:
>Is it actually Groovy closures? or "real" Java lambdas?
>
>On Tue, Oct 18, 2016 at 7:42 PM, Jochen Theodorou
>wrote:
>
>>
>> hah, I knew you can do it ;)
>>
>> On 18.10.20
Hi Cedric,
> De: "Cédric Champeau"
> À: dev@groovy.apache.org
> Envoyé: Mercredi 19 Octobre 2016 09:09:51
> Objet: Re: Lambda expression for Groovy 3
> First of all, great work, Daniel ! I'm confident that making the "lambdas" be
> "closures" in Groovy is enough. I stated it in the past but I'm
Daniel,
you have also to test that Type::method work not only with static methods but
also with instance method.
The awful case being when you have a static method that takes an instance in
parameter that 'overload' an instance method, like Integer.toString() and
Integer.toString(int).
Rémi
-
It doesn't work well on Windows if you do not change the default java encoding
to be UTF8,
says the guy that witness a whole team of students to frantically tries
everything possible the day before a very important release.
Rémi
> De: "Cédric Champeau"
> À: dev@groovy.apache.org
> Envoyé: V
Some OS stubbornly refuses to be UTF8 by default :)
Rémi
> De: "Cédric Champeau"
> À: dev@groovy.apache.org
> Envoyé: Vendredi 28 Octobre 2016 09:15:20
> Objet: Re: replacing jarjar by gradle shadow plugin
> Of course everybody should use utf-8 :)
> 2016-10-28 9:
or a photo of Guillaume dress as Father Chrismas :)
Rémi
- Mail original -
> De: "Daniel.Sun"
> À: d...@groovy.incubator.apache.org
> Envoyé: Mardi 1 Novembre 2016 12:23:55
> Objet: What Christmas gifts for us? ;)
> Dear Groovy Core Team,
>
> There are about 55 days before Christm
- Mail original -
> De: "Graeme Rocher"
> À: dev@groovy.apache.org
> Cc: d...@groovy.incubator.apache.org
> Envoyé: Vendredi 18 Novembre 2016 15:16:04
> Objet: Re: Negative relational operators for Groovy 3
> In agreement with everyone else here.
>
> +1 to !in and !instanceof
> -1 to e
Perhaps only on method reference,
filter (Objects!::isNull) ?
Remi
On November 18, 2016 4:10:24 PM GMT+01:00, Paul King wrote:
>On Sat, Nov 19, 2016 at 12:16 AM, Graeme Rocher
> wrote:
>> In agreement with everyone else here.
>>
>> +1 to !in and !instanceof
>> -1 to everything else
>
>Same for
Hi Daniel,
as you have discovered, there is no flag for specifying a default method in the
JVM spec, hence no ACC_DEFAULT flag in ASM,
a default method is just a non abstract method in an interface.
Also default and static methods in interface can be either public or private.
cheers,
Rémi
-
FYIW, there is already an httpserver with the jdk
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.httpserver/share/classes/com/sun/net/httpserver/package-info.java
cheers,
Rémi
- Mail original -
> De: "Daniel Sun"
> À: d...@groovy.incubator.apache.org
> Envoyé: Dimanche 11 D
There are com.sun classes and com.sun classes :)
These ones are exported
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.httpserver/share/classes/module-info.java
so ok to use.
Said differently, they are not part of Java but part of the OpenJDK.
Rémi
> De: "Cédric Champeau"
>
Felicitation !
Rémi
- Mail original -
> De: "Uwe Schindler"
> À: dev@groovy.apache.org, pa...@asert.com.au
> Envoyé: Lundi 16 Janvier 2017 16:20:11
> Objet: RE: [ANNOUNCE] Apache Groovy 2.4.8 released
> Thank you very much!
>
> Release process of Apache Lucene/Solr already started on S
I agree with Jesper,
solving all the cases is an uncanny valley.
The JEP 302 [1] has a good introduction on what javac does or not in case of
overloading
(and what currently does not work but is expected to work with java 10).
Also the warning proposed by Jesper exists in javac under the nam
Also note that in Java
Integer[] o = { 3 }; and int[] o = { 3 };
both work but
Object o = { 3 };
does not compile because the syntax '{' '}' with no explicit array type do
inference (and here Object is not an array so the inference fails).
Supporting only explicit array initialization seems
The other problem i see is that the fat arrow => is used by several mainstream
languages ; C#, Scala, JavaScript at least ; for declaring a lambda.
This will confuse people in my opinion.
Moreover as Jochen said , implies is a lazy operator, like && and ||, so the
operator should be more =>=>
> De: "Alessio Stalla"
> À: dev@groovy.apache.org
> Envoyé: Mardi 31 Janvier 2017 11:04:00
> Objet: Re: [VOTE] Apache Groovy Roadmap
> Sorry if outsiders are not meant to chime in :)
> Why not
> - 2.5 as Cédric proposed (so Java 7 + macros)
> - 3.0 with Java 8 and Parrot
> - 4.0 with Java 9 and
Hi Daniel,
On February 7, 2017 5:20:11 PM GMT+01:00, Daniel Sun
wrote:
>Hi all,
>
> Jesper and I discussed the *real* lambda expression(i.e. Java8's
>lambda expression) just now. As Jesper found, Java8's lambda expression
>is
>implemented in Java as an invokedynamic call which makes use of
- Mail original -
> De: "Jochen Theodorou"
> À: dev@groovy.apache.org
> Envoyé: Mercredi 22 Février 2017 22:49:01
> Objet: Re: Help with pitching Groovy and Grails
> On 21.02.2017 22:51, Raviteja Lokineni wrote:
>> Hi Devs,
>>
>> I was trying to pitch using Grails for one of our projects
Technically,
Python was not the first language to introduce the idea of using a plain string
at the start of a function as documentation, all LISPs do that :)
Rémi
- Mail original -
> De: "Daniel Sun"
> À: d...@groovy.incubator.apache.org
> Envoyé: Vendredi 24 Février 2017 03:46:53
> Ob
Jochen,
technically, you do not need the jdk 9,
you can compile with jdk 8 and have a jar that contains the declaration of
methods of the jdk 9 you want.
JRuby had worked that way when it was jdk 6 compatible but optionally uses the
java.lang.invoke API.
regards,
Rémi
On April 8, 2017 10:11:51
On April 8, 2017 7:35:18 PM GMT+02:00, Jochen Theodorou
wrote:
>On 08.04.2017 16:29, Remi Forax wrote:
>> Jochen,
>> technically, you do not need the jdk 9,
>> you can compile with jdk 8 and have a jar that contains the
>declaration
>> of methods of
Hi Jochen,
jshell, the equivalent of groovysh for java included in 9, does something like
this,
it stores the content of all variables declaration as fields into a synthetic
class and all statements as method so statement have access to the content of
the field.
But because you have bindings in
Use reflection,
have inside groovy a method needSetAccessible coded like this
private static final Method tryAccessible;
static {
Method method;
try {
method = AccessibleObject.class.getMethod("tryAccessible", ...);
} catch(NoMethodFoundException e) {
method = null;
}
tryAccessible = met
A standard annotation for generated code was added in Java 9:
http://download.java.net/java/jdk9/docs/api/javax/annotation/processing/Generated.html
Rémi
> De: "Andres Almiray"
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Septembre 2017 11:41:18
> Objet: Groovy and code coverage
> Hello
Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
> On Fri, Sep 8, 2017 at 3:00 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@
d [1] which is in a
module what will be removed [2] from the modules of Java SE,
so a long time ago :)
Rémi
[1] https://docs.oracle.com/javase/8/docs/api/javax/annotation/Generated.html
[2] https://bugs.openjdk.java.net/browse/JDK-8152842
> 2017-09-08 15:00 GMT+02:00 Remi Forax < [
Cedric,
the illegal access flag will still be present in 18.3. It will be removed
later, it's not clear when exactly (it will depend on the adoption).
Rémi
On October 4, 2017 4:25:28 PM GMT+02:00, "Cédric Champeau"
wrote:
>I would say a good step forward is to report errors people see with
Hi Paul,
multi-release jars are not well supported by the ecosystem yet,
eclipse and idea do not support it well, junit do not support it (all tools
that does annotations scanning in fact), maven do not support it well,
proguards do not support it, etc
Rémi
> De: "Paul King"
> À: "dev"
>
Maybe it's because if you do not specify a GC, the default GC is not the same
between 8 and 9 (CMS vs G1)
G1 tends to consume more memory because it delays the collection to avoid long
pause.
Rémi
On October 24, 2017 8:02:10 AM GMT+02:00, Jochen Theodorou
wrote:
>On 23.10.2017 14:14, Paul
Do you have a problem with those people ? :)
Rémi
On November 22, 2017 10:06:48 AM GMT+01:00, Russel Winder
wrote:
>On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote:
>>
>[…]
>> I don't see the old callsite caching still working properly in a
>> Java9
>> world, so it is time to cut l
And to be fully lost, there are several ways to be sure that a fatjar can not
be used as a module dependencies.
By example,
- create a module-info with a module name that you can not write in java, use
an exotic character like '+' in the module name, it's legal in the classfile
[1] but not in th
Cedric,
you can not have a dash in the name if you want the module name be referenced
in a module-info.java.
so it should be org.apache.groovy.json
cheers,
Rémi
On December 3, 2017 10:31:27 AM GMT+01:00, "Cédric Champeau"
wrote:
>Hi fellow Groovy devs,
>
>We had 2 different conversations in
> De: "Jesper Steen Møller"
> À: "dev"
> Cc: d...@groovy.incubator.apache.org
> Envoyé: Vendredi 22 Décembre 2017 11:26:06
> Objet: Re: About the native lambda
>> On 22 Dec 2017, at 10.48, Daniel.Sun < [ mailto:sun...@apache.org |
>> sun...@apache.org ] > wrote:
>> The problem I am trying to re
yes,
when some dependencies are using asm-all and some are not, with the classpath,
it was working after sacrificing a goat, it does not work with modules so we
have retired this artifact.
Happy Christmas,
Rémi
> De: "Cédric Champeau"
> À: "dev"
> Cc: "dev"
> Envoyé: Mardi 26 Décembre 20
You should try to reuse the LambdaMetaFactory instead of generating your own
proxy,
- generating a proxy means you have a way to define a class in module that do
not own, so you have to use lookup.defineClass (or worst unsafe.defineClass),
so you need to generate an invokedynamic
- you can gener
- Mail original -
> De: "Daniel Sun"
> À: "dev"
> Envoyé: Mardi 30 Janvier 2018 01:14:25
> Objet: About the callable native lambda
> Hi all,
>
[...]
> In addition, have you any idea about the issue[1]? If you do not know
> off the top of your head, I'll have to investigate whe
Hi Jochen,
- Mail original -
> De: "Jochen Theodorou"
> À: "dev"
> Envoyé: Vendredi 2 Mars 2018 00:57:16
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
> On 01.03.2018 16:39, Jesper Steen Møller wrote:
> [...]
>> |int numLetters = switch (day) { case MONDAY, F
- Mail original -
> De: "Jochen Theodorou"
> À: "dev"
> Envoyé: Jeudi 8 Mars 2018 19:51:57
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
> On 08.03.2018 17:34, Remi Forax wrote:
> [...]
>>>> int ac
- Mail original -
> De: "Jochen Theodorou"
> À: "dev" , "Russel Winder"
> Envoyé: Lundi 16 Avril 2018 21:22:36
> Objet: Re: Building Gant
> On 16.04.2018 19:16, Russel Winder wrote:
>> I know no-one (including me) really gives a about Gant these days
>> – except perhaps Bob Swift fo
s :(
Rémi
[1] https://github.com/forax/pro
- Mail original -
> De: "Jochen Theodorou"
> À: "dev"
> Envoyé: Jeudi 14 Juin 2018 23:50:05
> Objet: module information creation for Groovy 3
> Hi all,
>
> I just found https://github.com/moditect/moditec
- Mail original -
> De: "Jochen Theodorou"
> À: "dev"
> Envoyé: Vendredi 15 Juin 2018 17:38:29
> Objet: Re: module information creation for Groovy 3
> Am 15.06.2018 um 08:58 schrieb Remi Forax:
>> Hi,
>> moditech provides two different
yes,
JAXB has to be pulled from Maven Central now.
Rémi
- Mail original -
> De: "Russel Winder"
> À: "Uwe Schindler" , "dev"
> Envoyé: Samedi 18 Août 2018 19:33:36
> Objet: Re: Cannot build Groovy "out of the box"
> On Sat, 2018-08-18 at 15:42 +, Uwe Schindler wrote:
>> Hi,
>>
>>
Hi all,
Java 11 introduces several new forward incompatible features* in the class file.
Currently javac only uses one of them, nestmates [1], which allows to declare
that several classes are part of the same nest thus allow access to private
members in between them, obviously changing the seman
Forget to ling to the related bug:
https://issues.apache.org/jira/browse/GROOVY-8727
cheers,
Rémi
- Mail original -
> De: "Remi Forax"
> À: "dev"
> Envoyé: Dimanche 2 Septembre 2018 18:04:12
> Objet: Support of Java 11 using ASM 6.2.1 and ASM 7
> H
Hi jochen,
- Mail original -
> De: "Jochen Theodorou"
> À: "dev" , "Keegan Witt"
> Envoyé: Lundi 3 Septembre 2018 22:34:01
> Objet: Re: Old bytecode targets
> On 03.09.2018 14:33, Keegan Witt wrote:
>> I'm working on adding Java 9, 10, and 11 bytecodes to the 2.5 branch,
>> and 9, 10, a
t;Jochen Theodorou"
> À: "dev"
> Envoyé: Mercredi 5 Septembre 2018 12:44:45
> Objet: Re: Old bytecode targets
> Am 05.09.2018 um 12:36 schrieb Remi Forax:
> [...]
>>
>> it's not free if you ask ASM (COMPUTE_FRAMES) to do the fix point algorithm
>> (w
- Mail original -
> De: "Jochen Theodorou"
> À: "dev"
> Envoyé: Samedi 8 Septembre 2018 14:22:25
> Objet: Re: About type inference of method return value
[...]
>
> "var" is a bit a different story. It will lead to surprising types being
> used and partially violates the paradigm that yo
The history from the ASM point of view,
starting with Java 6, the VM starts to use a new bytecode verifier which is
linear in time and not exponential like the previous one but it requires to
annotate with a StackMap attribute the bytecode with the state of the local
types and the stack types m
- Mail original -
> De: "Daniel.Sun"
> À: "dev"
> Envoyé: Samedi 19 Janvier 2019 16:44:43
> Objet: Re: [PROPOSAL]Provide an option to generate stubs in in-momery file
> system for better compiling performance
> Use `ClassLoader.getPlatformClassLoader()` instead to solve the issue.
>
>
This was reported on the Java bug tracker but it's a Groovy issue (a
groovy-json one),
https://bugs.openjdk.java.net/browse/JDK-8218540
The JsonSlurper has not being updated to work with the new Java 9 String
implementation that uses an array of bytes, containing either a 8 bits
representation
And answering to myself,
it seems this issue has already been fixed,
sorry for the noise.
Rémi
- Mail original -
> De: "Remi Forax"
> À: "dev"
> Envoyé: Mercredi 13 Février 2019 11:50:45
> Objet: JsonSlurper doesn't work with Java 9+
> This
Stephen reharsh what Cay Horstmann said two years ago :(
The main issue is that there is still a lot of switch on string/characters that
are using fallthrough for a good reason.
You can put your blinkers and pretend that those switches never exist, that
falltrough is the root of all evil and tha
ASM is backward compatible since ASM 4.
Rémi
- Mail original -
> De: "Jochen Theodorou"
> À: "dev"
> Envoyé: Mardi 12 Novembre 2019 23:15:40
> Objet: Re: Upcoming releases
> On 12.11.19 08:14, Cédric Champeau wrote:
>> Just saying that using external ASM is an option now. Back then we
Several things to know:
- you can rewrite all access to a field marked @Lazy to use a constant dynamic,
that part can already be implemented. If you want to keep the compatibility
with Java 8, it means that you have to have two translations one for Java 11+
and one for Java 10-.
- if you want
Native image support neither the reflection nor java.lang.invoke/invokedynamic.
Are you suggesting to implement a new backend based on an interpreter, while
it's possible, it's a very big project ?
Rémi
> De: "MG"
> À: "dev"
> Envoyé: Mercredi 5 Août 2020 17:04:19
> Objet: Groovy as a JVM-
ASM 9 should have been released this week end but we have an issue with our
nexus requiring human intervention on the hardware,
hopefully, this should be fixed soon.
Rémi
> De: "paulk"
> À: "dev"
> Envoyé: Lundi 21 Septembre 2020 03:47:13
> Objet: Next releases
> Hi everyone,
> I hope to
Hi,
we (the ASM Team) have released, a few weeks ago, a new version of ASM, ASM
9.1, that support Java 17.
Given that Java 17 is the next LTS, having the next Groovy releases already
able to run on Java 17 may be cool thing to add.
Rémi
> De: "Milles, Eric (TR Technology)"
> À: "dev"
> E
- Mail original -
> De: "Christopher Smith"
> À: "dev"
> Envoyé: Mercredi 28 Avril 2021 01:37:14
> Objet: GDK retrofit for Java functional interfaces
> Since Paul is now threatening us with a 4.0 beta, I wanted to float an
> idea that I've been thinking over for a bit now that might be b
> De: "Christopher Smith"
> À: "dev"
> Envoyé: Jeudi 29 Avril 2021 19:38:27
> Objet: Re: () call-type syntax for functional interfaces?
> Also an object implementing multiple functional interfaces. In dynamic mode,
> you
> wouldn't know which method to invoke.
if that object is a lambda proxy,
> From: "Milles, Eric (TR Technology)"
> To: "dev"
> Sent: Wednesday, May 11, 2022 3:29:54 PM
> Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning
> Is there a compelling reason to drop support for Java 8? I don't see it
> holding
> us back quite like Java 7 support in Groovy 2.5 means no use o
- Original Message -
> From: "Milles, Eric (TR Technology)"
> To: "dev"
> Sent: Tuesday, July 5, 2022 4:59:52 PM
> Subject: RE: [EXT] Re: [DISCUSS] Groovy 5 planning
> I was interested in native interface default/private/static methods
> (GROOVY-8299, GROOVY-9801, GROOVY-1) for Groov
Hello,
reading the proposed enhancements for Groovy 5.0
I've several remarks,
the proposed destructuring syntax is ambiguous
switch(point3D) {
case (a, b, c) -> ...
}
It's not clear if a, b and c are existing local variables (declared above) or
fresh new bindings.
Choosing fresh new varia
> From: "Manas Marthi"
> To: "dev"
> Sent: Sunday, August 27, 2023 8:18:39 PM
> Subject: Re: Unable to setup workspace
> Hi Paul,
> thanks I did not get the response email. I found your response by visiting the
> group link
> I updated master branch and the issue is resolved, and build succeede
- Original Message -
> From: "Jochen Theodorou"
> To: "dev"
> Sent: Saturday, January 27, 2024 12:35:40 PM
> Subject: Re: [EXT] Re: ClassFile API
> On 23.01.24 19:33, Milles, Eric (TR Technology) via dev wrote:
>> An API like this works fine for straightline code. But if you need to add
- Original Message -
> From: "Jochen Theodorou"
> To: "dev"
> Sent: Sunday, January 28, 2024 1:19:24 PM
> Subject: Re: [EXT] Re: ClassFile API
> On 27.01.24 18:58, Remi Forax wrote:
> [...]
>> The classfile API uses sealed types, once those w
- Original Message -
> From: "Jochen Theodorou"
> To: "dev"
> Sent: Sunday, January 28, 2024 10:38:24 PM
> Subject: Re: [EXT] Re: ClassFile API
> On 28.01.24 15:05, Remi Forax wrote:
> [...]
>> Hello,
>> before i answer to your question
- Original Message -
> From: "MG"
> To: "dev" , "Jochen Theodorou"
> Sent: Monday, November 25, 2024 11:48:54 PM
> Subject: Re: [EXT] Re: Using `var` as method return type placeholder
> Hi Jochen,
>
> I am so glad that you are finally coming around to adding variable type
> inference to
- Original Message -
> From: "Jochen Theodorou"
> To: "MG" , "dev"
> Sent: Monday, December 23, 2024 10:39:55 AM
> Subject: Re: Replacing javax.* with jakarta.*
> On 21.12.24 16:43, MG wrote:
>> Hi Jochen,
>>
>> 1. that sounds like a good idea, but I am just wondering if ppl who are
>>
85 matches
Mail list logo
