Back to the channels

#java

00:36 pr3d4t0r :: yawn ::
00:36 pr3d4t0r Good morning.
00:37 pr3d4t0r dreamreal!! Come to #cime or the other channel when you have a moment?
14:06 dreamreal aaaaand nevet should be back. Still finding transaction leaks. :/
14:06 dreamreal still muted HERE, though. :D
18:55 dreamreal https://bytecode.news/posts/2026/04/boilerplate-three-ways
18:55 javabot dreamreal's title: "Boilerplate Three Ways | bytecode.news"
20:45 mawk hi
20:45 mawk is this calling 'new' under the hood? byte[] a = {1, 2, 3};
20:46 mawk i.e. is this equivalent to byte[] a = new byte[3]; a[0] = 1; a[1] = 2; a[2] = 3;
20:46 DoofusCanadensis doubt it
20:46 DoofusCanadensis byte != Byte
20:46 mawk I'm writing JavaCard and need to avoid 'new' as much as possible
20:50 jbosmans if implementation details like that matter a lot i'd suggest investigating how to validate answers to such questions, i'm thinking it'll lead to reading bytecode (aka jvm assembly)
20:51 jbosmans which i never do because i don't work at that level of detail
20:52 Chronos mawk: Yes, as far as I know, it's identical to: byte[] a = new byte[]{1, 2, 3};
20:52 Chronos So I believe it does indeed call "new".
20:52 Chronos (Corrections welcome.)
20:52 ernimril Chronos, compile it and then check with javap
20:53 Chronos In Java, every array is a full-fledged object.
20:55 mawk hmmm
20:55 jbosmans what ernimril said
20:55 mawk thanks
20:57 sonOfRa mawk: byte[] a = {1, 2, 3};
20:57 sonOfRa oops
20:57 sonOfRa mawk: https://javap.yawk.at/#lnBjVV
20:57 nevet javap pastebin
21:02 jbosmans also, https://godbolt.org ftw
21:02 nevet Compiler Explorer
21:04 sonOfRa true, but javap.yawk.at is made by (former) channel regular yawkat!
21:04 jbosmans kudos for that ^
21:05 mawk ah yes indeed sonOfRa , thanks!
21:05 jbosmans as far as i can see creating a new array doesn't create a new object
21:06 jbosmans static int[] square() { return new int[]{9999}; }
21:06 ernimril jbosmans, what about the newarray ?
21:06 jbosmans 0: iconst_1
21:06 jbosmans 1: newarray int
21:06 jbosmans 3: dup
21:06 jbosmans 4: iconst_0
21:06 jbosmans 5: sipush 9999
21:06 mawk well it calls "newarray byte" so it must be allocating it on the heap
21:06 mawk so I should do that only in the constructor of my applet so it's only called once
21:07 mawk I can technically trigger the garbage collector but it has to be done manually and it's not portable, not every card has it
21:08 jbosmans thanks for unbanning :)
21:10 jbosmans mawk, there's the epsilon gc which doesn't do anything iirc, might be useful for measuring/.. to accomplish your goals
21:11 mawk ah yeah, I can run this on a simulator on a pc
21:11 jbosmans should you want to invest in that approach
21:20 mawk thanks
21:21 jbosmans mawk, assuming sarcasm, understand what you mean (i think). You could make it runnable on a pc if you can separate the dependencies from the code that's actually doing the work (or the work you care about)
21:21 jbosmans overlapping msgs:)
21:35 jreicher mawk: are you really assigning the byte array something known at compile time? Or is that just how you wrote the example?
21:52 mawk yes it's known at compile time
21:52 mawk maybe if I set it as "final" it won't make an allocation
21:54 jbosmans afaik object instantiations are extremely cheap on jvm
21:55 ernimril it is on all modern jvms, yes, has been so for a long time. Also constants are quite often inlined by the compiler
21:55 jbosmans ~jep 519
21:55 javabot 'JEP 519: Compact Object Headers' can be found at http://openjdk.java.net/jeps/519
21:55 nevet JEP 519: Compact Object Headers
21:56 jbosmans also, it was pretty cheap before, too
21:58 jbosmans (before java 25)
22:00 jbosmans also, up to recently, i compiled some tools using docker to an ubuntu 18/debian 10 compatible binary
22:01 jbosmans which really made a difference for cmdline tools
22:02 jbosmans fwiw it was compatible by compiling in dedicated docker containers, i just upgraded the container OS versions
22:03 jbosmans iirc i got java+spring+jdbc+postgres+code down to ~60mb, which was nice
22:03 jreicher mawk: if it's known at compile time then declare it static and don't worry about the new. At worst it will only be done once, but perhaps not at all.
22:03 jbosmans UPX compression could drive that down substantially, but that would take longer to execute (because of decompression)
22:04 jreicher A good rule of thumb IMO is to always tell the compiler everything you know.
22:07 mawk jbosmans: this is running on a smartcard, it's a a very small and slow microcontroller
22:07 mawk with just a couple hundred bytes of RAM to spare, maybe a thousand
22:07 jbosmans mawk, great to be working on that :-)
22:07 jbosmans i actually recognized JavaCard
22:07 jreicher Is it possible Java is not the best language for that kind of target? (Honest question; I have no experience in this area)
22:08 mawk well there's no choice, java is all they run; in your credit card, your epassport, your SIM card
22:08 mawk you can sometimes run C but you need to sell your soul for a NDA
22:08 jbosmans mawk, which context? eid or alike?
22:09 mawk I'm working on a PKI smartcard
22:09 jbosmans sweet, iirc our eid runs JavaCard too
22:09 mawk java is actually a sane choice for the application, the JVM is fully controlled by the OS and can apply all the static checks and security mitigations they want
22:09 jbosmans crazy stuff
22:10 mawk they can do stuff like rolling back transactions in case of tearing, skewing the clock inbetween instructions or running instructions several times to throw off side channel attacks; and also exceptions are an integral part of how the card communicates with the reader, that's how you set the APDU status codes
22:11 jbosmans mawk, what jdk version are you working in?
22:15 mawk it's javacard 3.0.5
22:15 mawk compiling with jdk 17
22:18 jbosmans that's not too bad for such a restricted context
22:19 jbosmans iirc records are already supported
22:19 jbosmans best use those wherever they make sense
22:20 jbosmans because both the compiler and jvm will know they're mean to be (shallowly) immutable
22:21 jbosmans alas way post midnight, sweet dreams
22:57 dreamreal for javacard, eh
22:57 dreamreal That's a little surprising
23:04 mawk why?
23:07 dreamreal javacard's not very common in the wild. What are you deploying it to?
23:34 mawk I'm currently trying to add remote management capabilities with public key crypto
23:34 mawk like SIM cards have
23:35 mawk then you can open a secure channel with the card even through an untrusted network
23:35 mawk then the card will serve as a secure element to hold keys for mTLS or other things, in an embedded product, in SIM format
23:38 mawk and it's running on a JCOP 4 smartcard from NXP
23:45 dreamreal *nod* nice!
23:49 mawk I have half of the secure channel thing working, I can request AES session keys from the card and then continue with AES and CMAC
23:49 mawk but now I need to wrap the AES keys with a public key instead of transmitting them in cleartext
23:50 dreamreal so I have VERY VERY VERY little experience with that profile, but in general you avoid allocations like the plague: new is fine *but* you reuse *everything* you can, so if you allocate an array, you reuse that array for the lifetime of the application
23:50 mawk yeah indeed
23:51 dreamreal It's like you're writing in MUMPS except with java syntax, wooo
23:51 mawk I can request transient arrays which get cleared either on deselect or on reset (like if the application is selected several times on different logical channels or different interfaces like contact vs contactless)
23:51 mawk but then it's not with new
23:52 dreamreal I don't know if there's a GC on that profile at all: you'd want to allocate and preserve
23:53 dreamreal unless things have changed! Like I said, I've got VERY little experience here, like "ooo I tried it once"
23:54 mawk yeah some cards do have a GC but not all of them
23:55 mawk some cards even have ints and not just bytes and shorts
23:55 mawk luxurious
23:55 mawk and you need to invoke the GC manually, and it will maybe run next time a command is received
23:55 dreamreal I think I last did javacard on a lark for javaone 2007? maybe 2008?
23:56 mawk ah yeah the standards were quite different then
23:56 mawk I think the standard was still to use the VISA platform manager instead of being the globalplatform thing of now
23:57 dreamreal Gosh, I don't remember that at all - we had this physical connection to the board, I don't even remember what it was called to install the application
23:57 dreamreal I remember having a GPS available, which I thought was going to be great for basically building the apple tags using java
23:58 dreamreal like how train car locators work: when connected to an open network, send an identifier ("package XYZ is at X:Y at 23:01")