• cheeser
  • ernimril
  • joed
  • kinabalu
  • lunk
  • ojacobson
  • r0bby
  • ThaDon
  • ricky_clarkson
  • topriddy

« 2021-07-22


2021-07-24 »

Nick Message Date
P1RATEZ [P1RATEZ!piratez@user/p1ratez] has joined #java [12:08]
oxum [oxum!~oxum@] has joined #java [12:22]
luxemboye [luxemboye!~luxemboye@gateway/tor-sasl/luxemboye] has joined #java [12:25]
TechTest [TechTest!] has joined #java [01:02]
Null_A [Null_A!~null_a@2601:645:8700:2290:b978:3dca:9084:7b5f] has joined #java [01:04]
hub [hub!~hub@user/hub] has joined #java [01:17]
jetchisel [jetchisel!jetchisel@user/jetchisel] has joined #java [01:26]
luxemboye [luxemboye!~luxemboye@gateway/tor-sasl/luxemboye] has joined #java [01:29]
upsala [upsala!~zcb@] has joined #java [02:22]
Flonk [Flonk!] has joined #java [02:29]
sbeex [sbeex!] has joined #java [02:39]
sbeex Hi huys, I am writing an annotation processor. For now I can retrieve this `Set<? extends Element> annotatedElements = roundEnv.getElementsAnnotatedWith(annotation);` (and they are classes TYPE) I would like to determine if the class declare a static method called export() and if not generate it. is there a way to achieve that without parsing the [02:41]
sbeex file ? thank you [02:41]
AlanMD_ [AlanMD_!~AlanMD@] has joined #java [02:43]
ernimril sbeex, annotations are not meant to change the class you are looking at [02:52]
ernimril sbeex, if you want to do some hacky solution look at what lombok does internally and see what you can do [02:53]
sbeex ernimril hmmm yes thats exactly what lombok does btw.. [02:53]
sbeex no ? [02:54]
ernimril sbeex, lombok uses every hacky tool to get around the limitations of annotation processing, so if you want "inspiration" it is the way to go. It is not a stable route, but it may work for you [02:55]
sbeex not sure to understand what is hacky there. I have some classes which require a lot of boilerplate code and the goal is to reduce it [02:55]
sbeex so its not possible to read the methods declared in a class from an Element ? [02:55]
ernimril it ought to be, I think you can get the full syntax tree from the things you are passed, but you have to cast to internal javac types [02:56]
qu4nt1n [qu4nt1n!~qu4nt1n@] has joined #java [03:01]
jeukku [jeukku!~jeukku@user/jeukku] has joined #java [03:08]
sbeex ok solved -> .getEnclosedElements() [03:12]
sbeex next [03:12]
sbeex Another satisfied customer. Next! [03:12]
Matthijs [Matthijs!] has joined #java [03:13]
ebullient16 [ebullient16!~ebullient@user/ebullient] has joined #java [03:13]
karm [karm!] has joined #java [03:19]
_ht [_ht!] has joined #java [03:58]
hendursa1 [hendursa1!~weechat@user/hendursaga] has joined #java [04:07]
fstd [fstd!] has joined #java [04:18]
upsala [upsala!~zcb@] has joined #java [04:20]
nicxz [nicxz!~nicxz@user/nicxz] has joined #java [04:35]
jaskal [jaskal!jaskal@user/jaskal] has joined #java [04:50]
marcel [marcel!~marcel@user/marcel] has joined #java [05:00]
sa02irc [sa02irc!] has joined #java [05:04]
sbeex I have a question regarding maven flow. If my plugin generate some java sources is there some way to do so that they get automatically used by the project ? [05:50]
lucifer what do you mean by automatically used? [05:52]
lucifer if its on the classpath, you can use it at runtime. ofcourse, the ide will probably not know about it if the plugin is not integrated with it so it may warn. [05:53]
sbeex basically I parse a project having classes annotated with @MyCustom annotation and then I automatically at compile time via an annotation processor generate a java class which should be added to the built jar [05:53]
sbeex okay so let me rephrase it :) [05:54]
lucifer sure move the class the into the target folder before jar plugin runs. [05:54]
sbeex is there a built in way in maven to have my generated-sources being compiled and added to classpath/jar when I run mvn install ? [05:55]
sbeex okay [05:55]
sbeex thank you [05:55]
upsala [upsala!~zcb@] has joined #java [06:03]
MikeBux [MikeBux!] has joined #java [06:19]
darksun [darksun!~darksun@user/darksun] has joined #java [06:27]
dreamreal sbeex: yes, see how javabot does it [06:38]
sbeex hi dreamreal ok I will have a look [06:39]
sbeex this resume exactly my situation: [06:39]
sbeex I?m working on a plugin for Maven. I need to replace certain lines of code (actually, one annotation) in a source Java file. Of course, I?m not going to edit the original file so I?m creating a new one in my plugin. But I can?t make Maven use my generated source instead of the original one. I?ve tried to exclude a file when from [06:39]
sbeex compilation but it excludes the generated one. Without exclusion I?m getting duplicate class error while compiling the project. [06:39]
sbeex Thank you for any suggestions! [06:39]
dreamreal hmm, interesting [06:40]
dreamreal does NOT do that. Plugins have their own classpaths, though. Hmm. [06:41]
dreamreal dreamreal, what does that even *mean*? [06:41]
sbeex I am flexible basically it's an event library (shared with all our components) [06:45]
sbeex and I like to automate some boring repetitive code / operations [06:45]
sbeex and I like to have it done at compile time [06:46]
sbeex I did an annotation processor so that it generate some modified classes and now I should somehow generate a JAR which contains the "modified class" instead of the original ones [06:46]
sbeex ah maybe a way! [06:48]
sbeex I could via maven-pprocessor-plugin have my generated files in src/main/generated (will add a .gitignore for this) and my original ones in src/main/java now [06:49]
DasBrain_ [DasBrain_!~DasBrain@user/dasbrain] has joined #java [06:52]
sbeex ok the problem stays the same :/ [06:57]
brickfat [brickfat!~brickfat@user/brickfat] has joined #java [07:28]
TechTest [TechTest!] has joined #java [07:47]
Harlin [Harlin!~DonQixote@2603:300b:663:e800:98ff:d1ab:5789:5085] has joined #java [07:47]
hackinghorn [hackinghorn!~hackingho@user/hackinghorn] has joined #java [08:07]
koziad [koziad!~koz@user/koziad/x-1285628] has joined #java [08:08]
cheeser still not seeing the generated sources, sbeex ? [08:08]
cheeser sbeex: [08:10]
cheeser cheeser's title: "sofia/SofiaMojo.kt at master evanchooly/sofia GitHub" [08:10]
cheeser do that in your mojo [08:10]
sbeex i have them in target/generated/sources/annotations and they can get integrated into the build it seems [08:11]
sbeex its just when I try to override an existing class.. [08:11]
sbeex then I have duplicated class for the same classpath which do not really works well [08:11]
cheeser yep. you can't do that. [08:11]
sbeex but couldnt a maven plugin (custom) interfere this ? [08:11]
cheeser you'd have to blind javac to the original source file [08:12]
sbeex yes .. [08:14]
sbeex maybe stupid thinking pardon me if it is but [08:15]
sbeex maven build will compile put the classes to target/classes can I not come in the middle and say ok now my plugin override these 5 classes of target/classes with these ones ? [08:15]
cheeser maven just calls javac on a list of files [08:16]
sbeex hmm ok... [08:16]
cheeser you could try invoking a different run of javac after the compile phase [08:16]
cheeser basically running the maven-compiler plugin with a different set of sources. [08:17]
sbeex okay I will investigate this way [08:18]
sbeex I wanted to avoid going looking into lombok as I think its mega complex.. but maybe in the end will have too huh [08:18]
cheeser to me, it sounds like you're doing it wrong. but i can only see the "missteps" you're making without any of the context or business justifications you have. [08:24]
cheeser but generally, when you "need" to jump through such hoops, something has gone wrong. [08:24]
sbeex I can explain quickly maybe we can find a more elegant way of solving it (probably easier :D ) [08:25]
sbeex in fact we use kafka between our components and to send message to it we have a common lib which contains all our "typed kafka events" [08:25]
sbeex and yes I have to add some static methods to these events class for serialization/deserialization.. [08:27]
sbeex here it's ugly.. [08:28]
cheeser um. what? [08:28]
cheeser why would you need to do that? [08:28]
cheeser do you have a custom serialization library or something? [08:28]
sbeex yes for some reason the analytics department wanted us to use kafka serde stuff and then it was a bit overcomplicated.. [08:29]
sbeex jackson would do all out of the box normally no ? [08:29]
cheeser it would. [08:29]
sbeex (we end having a switch for ALL EVENTS) [08:29]
sbeex if(KEY) { serialize(EventClass.class) [08:29]
cheeser i don't recall kafka's stuff requiring static methods but i've not used it extensively. [08:29]
sbeex well thank you I think we should indeed change that [08:30]
sbeex then the annotation processing would also become much easier [08:30]
sbeex just auto generated classes [08:30]
cheeser it *might* be more work up front (but I doubt it) but it will sure as hell be less work down the line. [08:30]
sbeex but no longer edition [08:30]
sbeex yep thx for making me rethink it a bit (sometimes you are in a thing since year and ... you get "formatted" :D [08:30]
cheeser well, sometimes you get so focused on solving the problem you forget that sometimes removing the problem *is* the solution. :) [08:31]
sbeex haha indeed [08:31]
cheeser i've been there a lot myself lately ;) [08:32]
zeden [zeden!~zeden@user/zeden] has joined #java [08:41]
tang^ [tang^!~DoofusCan@2604:3d09:47c:f970:8d13:b68:18df:3319] has joined #java [08:50]
qilx [qilx!] has joined #java [08:52]
wedr [wedr!] has joined #java [08:57]
magla [magla!] has joined #java [09:17]
javabot [javabot!~javabot@about/java/javabot] has joined #java [12:55]
svm_invictvs_ lucifer, Uh, I may have overlooked that, let me try that. [12:56]
lucifer specifically one of its child interface [12:57]
cheeser the visitor pattern is incredibly useful [12:59]
svm_invictvs_ cheeser, grumble grumble [01:00]
cheeser try writing a compiler without it. :) [01:00]
svm_invictvs_ cheeser, The way doclets do it bug me [01:00]
svm_invictvs_ cheeser, Well. You. Have me there. [01:00]
lucifer upcoming pattern switches eliminate a lot of boilerplate too [01:00]
tang^ [tang^!~DoofusCan@2604:3d09:47c:f970:5570:f1f6:be0d:fc27] has joined #java [01:01]
drant [drant!~drant@2a05:f480:1c00:d82::] has joined #java [01:10]
hub [hub!~hub@user/hub] has joined #java [01:17]
svm_invictvs_ lucifer, Okay, was able to figure it out. You get a DeclaredType and then you visit that with the elements there in. Just really confusing how theis is laid out but makes more sense as I go through it [01:18]
akaWolf [akaWolf!] has joined #java [01:20]
lucifer yeah, makes sense [01:21]
hendursaga [hendursaga!~weechat@user/hendursaga] has joined #java [01:24]
oxum [oxum!~oxum@] has joined #java [01:39]
brickfat [brickfat!~brickfat@user/brickfat] has joined #java [02:04]
jamezp [jamezp!~jamezp@redhat/jboss/jamezp] has joined #java [02:06]
Optimus [Optimus!~risto@] has joined #java [02:19]
Optimus [Optimus!~risto@] has joined #java [02:37]
SFodder [SFodder!] has joined #java [02:40]
brickfat [brickfat!~brickfat@user/brickfat] has joined #java [02:41]
hackinghorn [hackinghorn!~hackingho@user/hackinghorn] has joined #java [02:47]
AgentK [AgentK!~AgentK@user/agentk] has joined #java [02:54]
mbaxter [mbaxter!] has joined #java [03:00]
cation [cation!cation@user/cation] has joined #java [03:03]
Betal [Betal!~Beta@user/betal] has joined #java [03:10]
acidjnk [acidjnk!] has joined #java [04:34]
Betal [Betal!~Beta@user/betal] has joined #java [04:37]
AlanMD [AlanMD!~AlanMD@] has joined #java [04:58]
DaPinkOne [DaPinkOne!~Dap@user/dap] has joined #java [05:19]
Shapeshifter [Shapeshifter!] has joined #java [05:22]
karm [karm!~karm@] has joined #java [05:31]
rorx [rorx!] has joined #java [05:46]
darksun [darksun!~darksun@user/darksun] has joined #java [05:56]
ferdna [ferdna!~ferdna@user/ferdna] has joined #java [06:09]
sa02irc [sa02irc!] has joined #java [06:13]
darksun [darksun!~darksun@user/darksun] has joined #java [06:14]
Betal [Betal!~Beta@user/betal] has joined #java [06:41]
upgrdman [upgrdman!~upgrdman@] has joined #java [06:42]
upgrdman what is the point of ThreadLocal stuff when you can just define a class that extends Thread or implements Runnable, and give it a field? [06:42]
DasBrain_ [DasBrain_!~DasBrain@user/dasbrain] has joined #java [06:56]
Byteflux upgrdman: I may be wrong, but I don't think there are any good use cases for ThreadLocal in a proper design. You should be just passing around dependencies and caching them in thread-specific fields, as you said. [07:01]
upgrdman k [07:02]
Byteflux They are often used for ensuring thread safety of a static API. [07:02]
upgrdman hmm, ya that makes sense [07:02]
Byteflux Like Charset.encode/decode() static methods cache the underlying CharsetEncoder/CharsetDecoder objects per thread using ThreadLocal [07:03]
Byteflux Well, they aren't static methods, but they are statically cached [07:03]
Byteflux This way you can decode/encode using the same Charset instance in any thread without worrying about thread safety issues with the Encoder/Decoder objects. [07:04]
Gaboradon [Gaboradon!] has joined #java [07:09]
darksun [darksun!~darksun@user/darksun] has joined #java [07:11]
upgrdman [upgrdman!~upgrdman@] has joined #java [07:23]
darksun [darksun!~darksun@user/darksun] has joined #java [07:31]
hnOsmium0001 [hnOsmium0001!] has joined #java [07:32]
jeukku [jeukku!~jeukku@user/jeukku] has joined #java [07:53]
ricky_clarkson I used ThreadLocal to build something like OnEdt<T> that would only allow access to a value if you were on the AWT event dispatch thread. It helped with a lot of threading issues a Swing app had. [07:57]
cheeser nice [08:20]
leduyquang753 [leduyquang753!~leduyquan@user/leduyquang753] has joined #java [08:20]
airhead [airhead!] has joined #java [08:24]
jetchisel [jetchisel!~jetchisel@user/jetchisel] has joined #java [08:25]
javabot [javabot!~javabot@about/java/javabot] has joined #java [08:38]
AMcBain [AMcBain!~AMcBain@user/amcbain] has joined #java [08:39]
hackinghorn [hackinghorn!~hackingho@user/hackinghorn] has joined #java [08:41]
hornhack [hornhack!~hackingho@user/hackinghorn] has joined #java [08:51]
hackinghorn [hackinghorn!~hackingho@user/hackinghorn] has joined #java [09:00]
ava [ava!~ava@2600:6c54:7001:400:885:550f:34f1:2e5] has joined #java [09:10]
hackinghorn [hackinghorn!~hackingho@user/hackinghorn] has joined #java [09:10]
jetchisel [jetchisel!jetchisel@user/jetchisel] has joined #java [09:13]
stkrdknmibalz [stkrdknmibalz!] has joined #java [09:21]
hornhack [hornhack!~hackingho@user/hackinghorn] has joined #java [09:21]
hackinghorn [hackinghorn!~hackingho@user/hackinghorn] has joined #java [09:31]
darksun [darksun!~darksun@user/darksun] has joined #java [09:31]
snowdrone [snowdrone!~snowdrone@user/snowdrone] has joined #java [10:20]
kupi [kupi!] has joined #java [10:49]
tang^ [tang^!~DoofusCan@2604:3d09:47c:f970:9832:c11a:40f7:ffbd] has joined #java [10:53]
darksun [darksun!~darksun@user/darksun] has joined #java [11:32]
tang^ [tang^!~DoofusCan@2604:3d09:47c:f970:80fd:5ee4:e0f:e565] has joined #java [11:37]
TechTest [TechTest!] has joined #java [11:51]