Coremod changes

[kindred crow]

I want to change coremod to support isolated Java code. Note: coremods will not have access to the game or other mod code - but rather than keep going with the javascript stuff, we migrate to using Java instead. It's a better dev experience, and with the way classes load now, this isn't as big a risk as it used to be to have the coremod code in Java.

[turbid river]

thank god, writing js was horrible

[vernal spire]

yes please

I don't mind the js per se but the lack of code completion is just ugh

[kindred crow]

heh

[narrow frigate]

makes me wonder how the dev experience will be, for writing these Java-based coremods

as in, is the access enforced only at runtime, or (somehow) enforced at compile-time too

[vernal spire]

could be a separate sourceset, without mc dependency present

although not sure how you'd enforce that

mixin uses the annotation processor to verify at compile time that mixins aren't doing things they aren't supposed to

[kindred crow]

yeah, it'd probably be some sort of isolated sourceset with just the asm libs

[thick breach]

there is no way to enforce that sadly

[foggy orchid]

would this sourceset be conditionally set up by NG?

[kindred crow]

im guessing it would be yes

certainly the artifact will be a secondary jar

[tawdry slate]

i mean, it sounds like the true enforcement would be at runtime since coremod mod jars would be loaded in their own classloaders

though keep in mind, eclipse's finest level of distinction is the project, not the source set, so for those folks maybe it'd be sensible to have coremods be their own project?

[kindred crow]

that's only for trying to hint to people writing coremods that they don't have access to stuffs

at runtime, it'll just barf

[naive shoal]

the finest and the only

[vernal spire]

yeah, avoids mistakes

and misunderstandings

[naive shoal]

screms internally

[thorn scroll]

They'll have access to stuff on the same layer though, right?

[thick breach]

I don't think so

They will likely run in an isolated classloader

Maybe with something like guava or apache enabled for useability

Allthough.....

[thorn scroll]

That seems... less than ideal. Is there any actual risk to giving them access to other stuff at the pre-class-transformation layer?

Or rather, this would seem to imply that there is, so what is it?

[tawdry slate]

everything they can access is something that is not transformable by them

so if you want util libraries, they should be shaded + relocated

[thorn scroll]

Yes, I am aware. Isn't the advantage of modules that if they're running in the right layer, they can access all the stuff that they couldn't transform anyways and none of the stuff that they could?

[foggy orchid]

Pretty sure accessing the service layer is safe

[thorn scroll]

That was my thought, so long as the coremods are isolated from any layer with transformable stuff they should sorta be able to do whatever

[thick breach]

They are part of the service layer as far as I know and they are not allowed to touch each other....

But yeah referencing each other

Is probably fine

[thorn scroll]

Referencing each other and referencing... honestly, anything that can't be transformed should be fine I'd think

[oak canyon]

return of the coremods folder /s

[kindred crow]

I will start with minimal possible access

If we can support increasing scope a bit, we'll see.

[thorn scroll]

Is there any reason the service layer shouldn't be accessible?

[kindred crow]

But, for example, see #1155583613115568298

That's an escape

[thorn scroll]

discord mobile please actually take me to the right message

[kindred crow]

And that would 100% fuck the world hard

So, no, we start minimally or just forget about it IMO

[thorn scroll]

What's the escape exactly?

But yeah, I suppose it's easy enough to add stuff later

[kindred crow]

You can just add anything to anything via the mechanism maty documents there

Which is 100% antithetical to coremods philosophy

So minimal scope.

[thorn scroll]

Coremods philosophy, in contrast, is...? Just so I understand

[oak canyon]

I wonder if we could start locking things down with modules but that's a huge ask and people would probably agent their way to victory

[kindred crow]

Change only the class you are asking to change and nothing more

[thorn scroll]

Yeah, locking stuff down is never a good option. This is a modding framework. Give people the freedom to do hacky shit, just help it be done sensibly

[kindred crow]

Coremods are literally a classloading extension

[thorn scroll]

Ah, got it

So anyone who wants to change more classes or do mass ASM will be stuck with other approaches?

That's fine honestly if that's not the goal of coremods. That makes sense

[kindred crow]

If you start fucking around with everything else, when you're supposed to be injecting or otherwise modifying the incoming class byte stream, you're doing it wrong

You can ask to modify more than one class luke

[thorn scroll]

Yes I'm aware. You still have to ask

[kindred crow]

But on an invocation you will be presented with a single class structure

[thorn scroll]

Yeah. Okay. Makes sense to me. So, leave the other use cases to other tools

[kindred crow]

Yes

What other usecase?

[thorn scroll]

Anything that can't be done with just that, whatever that may be

[kindred crow]

That's not helpful

[thorn scroll]

I think trying to get some service layer or higher stuff in is still smart - I'd like to try to get libraries that can't be modified by coremods available if possible

[thorn scroll]

Hmm, I'm actually uncertain now if there are any. In which case I'm once again confused why coremods need to have minimal access. Can't they theoretically safely access stuff on the service layer?

[oak canyon]

I have no issues with locking down internals of the framework itself IMO people shouldn't be ASMing core parts of the thing, minecraft they can do whatever but the compatibility framework shouldn't be messed with at a core level, issues should (in an ideal world) be brought up as an issue/PR people hacking the internals is a failure on our part and should be addressed as such

[thorn scroll]

I guess I'm confused because I don't think that would be ASMable even if it were made available?

It can still only modify stuff that's in a modifiable layer

And that's mods and the game, unless I'm mistaken

We just don't want it classloading any of that

Because that is Very Bad

But because of modules, you should be able to give it access to the service layer while making it impossible to classload the mod/game stuff

But regardless, that's always something that can be added later

[oak canyon]

I remember wishing in the past there was a way to stop a mod from ASMing another mod if the mod author didn't explicitly allow for that

[thorn scroll]

Like, giving coremods access to the service layer and whatnot doesn't let them hack into it and ASM those classes because they're just not loaded on the right classloader

[oak canyon]

but that's beyond the scope of this

[thorn scroll]

That's a shitty thing to do. If a mod wants to ASM another mod that's on them, but they should be able to

[oak canyon]

I disagree a mod author should be the arbiter of what happens to their mod

[thorn scroll]

After all, you have to for certain coremods to work - "change every usage of XYZ to ABC" fails terribly if some mod author doesn't want their stuff touched for some reason

[oak canyon]

if a mod author says no I don't want anyone to modify this via ASM we should follow their wishes

putting locks on a door isn't an immoral thing to do

[thorn scroll]

Except now that mod has some weird interaction with mine that I can't fix without ASMing it, because they've decided they don't want to fix it

[oak canyon]

and?

it's not your mod

[thorn scroll]

I have to agree with Su5ed here. Putting locks on doors should only be done when you know that stuff will (not "might") crash and burn if the thing behind it is touched

[oak canyon]

I understand it sucks personally

[thorn scroll]

Let me ask a better question: why shouldnt I be able to ASM random mods?

[oak canyon]

It's not your work

full stop

[thorn scroll]

...and? Neither is Minecraft and I'm ASMing that

[foggy orchid]

And now the mod author is officially an ass

[thorn scroll]

This is modding. Slightly dangerous ASM fuckery is unfortunately the bread and butter of anything vaguely non trivial that can't be solved with tools like mixin

[oak canyon]

I agree but it should be their right

[thorn scroll]

Sounds like the sort of thing what's their face did back in the day. Whoever made Chromaticraft

[ripe bison]

Allowing mods to yeehaw and hack into a bunch of unexpected shit is how you get stuff blatantly overreaching like Opti; now you have to deal with that stuff in modpacks because two devs are having a measuring contest

[thorn scroll]

Why? Why should it be their right?

[oak canyon]

it's their work and their blood sweat and tears

we should respect that

[thorn scroll]

They can't stop users from opening up the jar and shoving stuff in it. And they shouldn't be able to stop modders from ASMing it

[thorn scroll]

And John Deere tractors are the blood sweat and tears of that company, and yet when they threw a fit when people tried to mess with the internals everyone was (rightfully) saying "that ain't how it works"

[oak canyon]

I'm not asking for DRM im asking for an option to opt out of being ASM'd

[thorn scroll]

Right to repair is a thing and in this context that's "right to dangerously ASM"

[kindred crow]

Sadly that breaks a lot of stuff. You can't do events, for example

[ripe bison]

IMHO if a modder refuses to fix something that clearly has issues, the community will naturally call that out

[oak canyon]

yeah that's where my thoughts are too :/

[thorn scroll]

Beyond all I've already said it's a bit too close to the likes of DRM for my taste

[kindred crow]

It sounds lovely in theory (tho why is your mid so precious 🤔) but it basically breaks before you even start

[ripe bison]

The entire point of a mod loader/framework is to encourage cooperation, not taking hammers to each other >.>

[oak canyon]

Yeah call it out fork it remake it whatever! but I do think there is merit to having a consent of the author

but that idea seems to be the minority

[kindred crow]

There's some weird bunnies in modding who would probably use such a mechanic to be a deliberate troll

Sadly illy

[thorn scroll]

Yes, and the only reason I can think of for preventing ASM on your mod is "i don't want to be compatible with other mods". People are going to be ASMing your mod, most likely, if they have to do some sort of mass "turn XYZ to ABC" sort of thing. If you opt out, you're saying "fuck you, I don't want to be compatible"

[oak canyon]

I agree 100% yeah

[kindred crow]

You know that's ok right luke

People don't have to play nice with everyone else

[thorn scroll]

It's okay to say "fuck you I'm going to be intentionally incompatible"?

[oak canyon]

Yes!

[ripe bison]

I'm arguing that if you, as a developer, see people asking for XYZ and openly refuse, that should label you as the issue, not anyone else

Get out of the sandbox if you don't want to share space

[thorn scroll]

I... sure, I guess, but in those contexts it's also okay to take out the sledgehammer and ASM stuff anyways

[oak canyon]

I don't like incompatible mods but if that's what the author wants then yeah

[kindred crow]

Yup

[thorn scroll]

And we shouldn't give people the tools to fix those incompatibilities themselves?

[oak canyon]

we are framework builders it's up to the modders to create with it we can only encourage and shouldn't force

[thorn scroll]

Sounds a bit too close to DRM for my comfort, once again

[ripe bison]

Because decade+ here is this: no single modder or mod is that special. The community can and will move on if you're an ass to it.

[thorn scroll]

Once the jar is in the hands of the user, as long as they don't redistribute it or do something borderline illegal it's basically a free for all. Internal use isn't really highly limited

[oak canyon]

100%

[thorn scroll]

Yes, so why give people the tools to be an ass? When I haven't really seen a use for stopping ASM beyond being an ass

Like, imagine forge had done that before the fork and stopped people from ASMing forge

[ripe bison]

"I don't like Botania today. Time to utterly break mana because FE is clearly betterer"

That's the kind of stuff that can happen

[thorn scroll]

Yes, it can?

[ripe bison]

And now nobody gets to play that modpack because two devs are fighting. Nobody wins.

[thorn scroll]

But my point is that I don't see a use for preventing ASM on mods, other than giving people an alley to get to do that sort of stuff

Like, allowing mods to block ASM gives them a tool in their toolbox of ways to fuck with other devs if they have a disagreement, and it doesn't really have any other use that I've seen shared here

[ripe bison]

I'm not hearing a direct argument against a major con here, only "BUT I WANNA"

[thorn scroll]

Major con: #1155582283839983658 message

Mod makes a change that requires mass ASM to every user of XYZ. Now some random mod is incompatible because it didn't want to be ASMed because the modder wishes they could have DRM and this is the second best they can get

Beyond which, I'm not seeing a major benefit beyond "BUT I WANNA"

[round wadi]

Mod becomes incompatible... mod is incompatible?

i'm not seeing a con here, i'm seeing a broken mod

[oak canyon]

but that's ok it's not what I would like personally but if that's what the modder wants that's what they should have the poragative too do we aren't the moral authorities how people should mod ASMing someones mod because you don't like it or think they're an ass is just a week argument

[ripe bison]

Too many ways here to break the ecosystem worse than what you can fix

[thorn scroll]

You could make the same argument the other way around about a mod wanting to ASM some other mod

[oak canyon]

No I can't make that argument

it boils down to I wanna

[thorn scroll]

Can't you? We shouldn't be the moral authorities about judging if some mod wants to ASM some other mod

[thorn scroll]

So does the argument for locking down ASM!

[ripe bison]

But Neo, offering coremodding, IS setting the authority here

[thorn scroll]

Like, why should mod A have any more of a right to prevent ASM than mod B has a right to do hacky ASM?

[oak canyon]

that's why I'm saying the modder should have the right to say "no I don't want that" it's not OUR choice

[ripe bison]

And if the core (kek) goal is compatibility, don't give people a sledgehammer when all they need is a chisel

[thorn scroll]

Yes, and the modder should also have the right to say "yes I do want to ASM that other mod" it's not OUR choice, by the same logic...

[oak canyon]

anyway the point is moot it's impossible technically

[oak canyon]

SO break into their house because you want to make their bathroom door not squeak

[round wadi]

🤔 as analogies go that's rather drastic

[oak canyon]

to me it's the same logic

[thorn scroll]

No? It's a jar on some users machine. It's not their house at that point. They have some rights to it, yes, but that isn't one of them

[ripe bison]

I will stand by the argument that MC is the only thing that should be targeted, and if a mod has a big enough problem that others want to hack into it to fix it, you have PRs, Issues, and the community opinion to do that instead

[thorn scroll]

That's, like, the core of right to repair

[oak canyon]

I don't like this so im forcing my ideas onto your mod

[round wadi]

i didn't say it's incorrect, just drastic :P

[thorn scroll]

I'm saying that right to repair applies to software too

[ripe bison]

And if you, as a mod author, refuse to look at what people are (begging) for, and choose to openly ignore that, then you shouldn't be surprised when you get taken out of the sandbox for a nap

[thorn scroll]

They're not though, that's the great thing! They can't forcibly upload to your curseforge page or anything

[oak canyon]

are you ASMing without consent?

then yes you are

[thorn scroll]

It's all happening only on users computers, and users have chosen to install both mods

[oak canyon]

that's my core argument

[thorn scroll]

Consent of who? The modders consent doesn't matter here... the users does. That isn't a right the modder has once the software is on a users machine. They get IP rights, and that's about it

They don't get magical rights to their specific instance of that specific software beyond what copyright gives them

[oak canyon]

soo it's ok to for people to just change whatever without the modders consent becuase of a disagreement

[ripe bison]

What's stopping, say, JEI, from adding a few dozen "fuck you REI, Creative, and half a dozen popular mods" ASM hack in, and utterly shattering the ecosystem?

[oak canyon]

if that's your argument we have no where else to go because it's just insane to me

[thorn scroll]

Yes? Literally yes. If its okay for a user to open up the jar and modify it, then its okay for another mod to ASM it

[oak canyon]

welp ok there have it

[thorn scroll]

The fact that people would stop playing with them, and that it violates CFs ToS

[oak canyon]

It is morally ok to break into people mods because "I wanna"

[ripe bison]

Or worse - my mod doesn't update frequently. I have a patch to fix a temporary bug somewhere (good intentions! I'm playing nice!) but I get hit by a bus and I'm in the hospital for half a year. Targeted mod gets a bugfix in a wildly different way. No nobody can use both those mods because now I'm incompatible and nobody can do anything about it

[thorn scroll]

And it fundamentally is okay for a user to change a jar locally. That's the right to repair, and it is a thing that I believe applies here. Letting other mods ASM the mod just let's users do that easier, in an automated fashion

I don't really see an argument for allowing mods to lock down ASM in this fashion that isn't "right to repair is a terrible idea"

Which isn't an argument

[thorn scroll]

Yes, that's a possibility. That's also fully possible without ASM into other mods so it's a moot point

[thorn scroll]

You're not breaking into anything. The modder has no rights to what users do with their mod, beyond those given to them by copyright and IP laws. That's just how it works. Period. If you don't agree with that, I don't know what to tell you - that's obviously a large difference in morals between us

[oak canyon]

I'm out for two reasons so lets drop it

1. asking consent is the moral and correct option
2. It's technically impossible to do so arguing to a brick wall is useless

[thorn scroll]

It's like if I buy a bicycle. And I buy some cool decals for the bicycle from someone. You're saying the bicycle manufacturer should be able to tell me that I can't apply the decals to my bike

[oak canyon]

I'm not moving on these

[thorn scroll]

That's where I'm coming from here. That's what your argument looks like to me. If there's a difference there, I'm not seeing it. Beyond that, I don't appreciate being called a "brick wall"

[oak canyon]

We're both brick walls

or im an immoveable object

whatever

[thorn scroll]

And frankly point 1 here is the most out of context interpretation you could possibly have made

[oak canyon]

I've used authors consent multiple times if you choose to ignore it it's on you I'm out

[thorn scroll]

But I genuinely don't see how this is different from the bike scenario. Or if, say, my mother in law gave me the recipe for something. And then got mad when I used a modified version of the recipe, at home, cooking for my family and nobody else

[thorn scroll]

It's not about the authors consent. Consent implies that they are at risk of being personally affected somehow

Let me ask you a different question: do you think modders should be able to, if they choose, somehow lock down their mods so that users cannot open them up, modify the jar, and play with them?

Because that sounds like DRM to me. And ASMing other mods is just a distributable, automated way of doing exactly what I've described in that scenario. So when I say that what you're arguing for sounds a heck of a lot like mod DRM, that's why

And for why that's bad, I refer to my recipe or bike scenarios. The ASM patched version isn't being redistributed or anything

[kindred crow]

I agree in principle with illy. In practice it's a completely moot point because it's literally fundamentally breaking how everything works and would require a core redesign to even start thinking about it

[thorn scroll]

Wait @ripe bison now I'm worried about that reaction. You actually think mod authors should have a forge-endorsed way of implementing DRM in their mods?

Well I suppose that would make sense why we don't agree then

[ripe bison]

You keep saying DRM

I'm not arguing for DRM.. I'm saying modders shouldn't be able to fuck with other mods

[thorn scroll]

Nano that thing you reacted to is literally DRM. It was nothing about modders fucking with other mods, it was about users fucking with mods

[ripe bison]

Users DEFINITELY should not be able to fuck with build artifacts

[thorn scroll]

...so DRM

Or close enough to

DRM, minus the "prevent redistribution" bit which is the only bit with any moral standing

[thorn scroll]

Yes, exactly. Close enough to. The morally terrible part of DRM without any of the bits that are actually morally possibly okay

That's... alright. If you truly believe that modders should be able to prevent users from messing with their mod jars in production I'm not going to have this argument with you any more, because it's obvious that it won't go anywhere.

[ripe bison]

It goes back to JAR signing and knowing you don't have something that has been maliciously tampered with

Shit like 9minecraft adding viruses and stuff

[thorn scroll]

This case has nothing to do with that. I'm talking users modifying stuff. On their own machine

Open up jar, change XYZ, repackage, play

In my opinion users should be able to do that if they want, which I thought was a given but apparently isn't

[ripe bison]

Listen. I had a user come in and try to add 1.7-era config code to a serverconfig the other day

do NOT let users fuck around in built code

you're gonna allow way worse and more frequent breaks allowing modification than preventing it in the first place

[thorn scroll]

So, if they mess stuff up they mess stuff up and nobody has to support them. Doesn't mean they shouldn't be able to. That goes back to the whole "users are stupid" thing that you saw here all the time which was frankly pretty disrespectful

[ripe bison]

if you need a fix, FUCKING SUBMIT A PR

Because I as a modder won't know about it!

[thorn scroll]

My point isn't that users should do that, it's that they should be able to do that

[round wadi]

Okay, both of you, either quit it or move it, this is WAY off topic

[versed finch]

I prefer the old form of CoreMod(1.12.2-1.6.1)

[slate dock]

Going to have to take cpw's word on allowing coremods to be written in java again as I'm certain someone will try to break out of the sandbox just to say they did.
I'd like the coremod audit logs to be more thorough/verbose (don't ask me what that means, I haven't decided on that yet) as well, and the holy grail would be some system that would allow us to dump, deobf and decompile the final in-memory jar

[naive shoal]

mixin already does class dumps

[slate dock]

I've heard that but not seen it, how hard would it be to trigger that feature on a user's instance?
If I have to rebuild the whole pack in deobf to get the same bytecode I'm not going to bother and juust keep saying "Remove all coremods and add them back one by one" when the audit line gets to a mile long

[vast wharf]

The mixin dump is pretty much trivial to trigger: -Dmixin.debug.export=true. It doesn't deobf, but in my experience that's usually not necessary anyway.

[thorn scroll]

Certainly not necessary in 1.20.2+ where we'll have runtime Mojmaps

[tulip marsh]

rojmaps

but yeah, that’s true

[slate dock]

Trivial to trigger in a dev environment there... need something easy to activate on the user end for log-reading purposes

I assume we'd just need to have FML set that flag early enough

[thorn scroll]

I mean users can add that flag too. But yeah, if it could be extracted into a config that would be great

[slate dock]

Either I'm missing something or you are... where would a user add that flag?
I'm talking about CF users that need to be taught how to navigate their filesystem... I need something DEAD simple

[thorn scroll]

Ah yeah, FML config seems like it'd work then

[swift thorn]

Coming back to this, and related to the mcml discussion... how crazy would it be to load Java coremods from the PLUGIN layer?

[vernal spire]

are mod jars already enumerated by the time the plugin layer is constructed?

I assume mixin also runs there so that's a yes

[swift thorn]

Plugins and mods are enumerated at the same time

I think mixin plugins are on GAME which is very concerning - not sure how that works

[naive shoal]

it's not crazy, we can have both normal coremods and mass asm loaded from there

[vernal spire]

what's the goal for java coremods

would there still be a coremods.json file of some kind, or service loaders?

[swift thorn]

Yeah that's what I am thinking

Service loaders probably?

[naive shoal]

fuck json

service loader lol

[vernal spire]

so how would a coremod specify which class it targets, would it "subscribe" to the class, or would it accept() each classname at will?

[swift thorn]

It would have to provide a list of class names

Essentially you'd register something like a list of ITransformers

[vernal spire]

cos I was wondering, does there need to be a difference between "mass transformers" and single-class coremods?

public class ChangeSomethingToFixAThing : ICoremod
{
    public boolean accepts(String className) {
      return "com.mojang.whatever.TheClass".equals(className);
    }
    public ClassNode transform(ClassNode classNode) {
        //do the thing
        return classNode;
    }
}

I guess if there's a few dozen coremods that's a few dozen calls to accepts() for every single class in the game

no idea how that compares with a Map<> lookup

[swift thorn]

Well single-class wouldn't have accepts

It's probably kind of equivalent

But I prefer keeping them separate in case we can optimize classes that are not targeted

@naive shoal @foggy orchid maybe we should add "all classes" targets instead?

https://discord.com/channels/313125603924639766/1155583613115568298

[vernal spire]

yeah

[foggy orchid]

are there any risks to having no filter whatsoever?

[vernal spire]

hmmm ...

public class ChangeSomethingToFixAThing : ICoremod
{
    public void initCoremod(CoremodManager mgr) {
        mgr.transformClass("com/.../Thing", this::transformThing);
        mgr.transformMany(<something to represent a class filter>, this::transformMany);
    }
}

no filter means all the classes are parsed using ASM, then turned back into byte[]

[naive shoal]

something something onlyin

[thorn scroll]

Mixin plugins have to be there because there's no declaration of what other classes within a mod jar they might need to poke, and they're in the same jar as normal mod classes - so it's hard to pull them out to a safer layer, unfortunately, without, like, loading mod classes from two different places or something? IDK, maybe that's not unfeasible

[naive shoal]

we could probably look into trying to design this new api with visitors in mind

[thick breach]

It should be trivial, if we isolate them properly

Maybe even give them their own classloader / layer

[swift thorn]

I think PLUGIN should be fine? if we instantiate them before the GAME layer is built they have no chance of loading a class from there

[thick breach]

Poeh

I think so

The idea is that they don't touch each other

In my opinion coremods should exist and be easy to use

But they also should not be able to roam free

And should be isolated to a particular area

[swift thorn]

how so exactly?

[thick breach]

It was the core concept of coremods from the beginning

Arguably

With Mixins currently the way they are

It does not really work like that

[swift thorn]

if we load them in PLUGIN, they will be able to touch any mc or mod code, but not any other plugin-level or higher code

[thick breach]

I am not sure if it is reasonable these days to still ask that

Yeah that is the problem

THey are not supposed to touch MC code in the first place

[swift thorn]

I think the most important feature is that they cannot load classes from the wrong classloader - but this is solved by the module system

oh I mean transform, not load

[thick breach]

Hmm

It could work

Practically speaking you are obviously right

It will likely work

But realistically speaking......

I wonder if there are any stability risks to that

[swift thorn]

in principle they can only affect the higher layers to the same extent that any other PLUGIN library can

[thick breach]

Probably right

[naive shoal]

people can obviously bypass it if they want to, but that's not our concern

[thick breach]

What can they bypass?

The module layers?

[naive shoal]

yes they can if they try hard enough, restrictions are a joke for the jvm

[swift thorn]

as long as Unsafe is accesible, yes

in the future this might change

[naive shoal]

when mods can do moduleinfo, mods will be able to requires sun.misc anyways

[thick breach]

Is there a way we can restrict access to Unsafe in a particular module layer?

[thick breach]

We have full control over all module info that gets loaded

We can strip that particular statement for PLUGINS

[swift thorn]

realistically no

I'm sure the openjdk devs are slowly working towards this, but it will probably be a few years still

[foggy orchid]

imo we should think of these restrictions as "guidelines" rather than hard limits. If someone wants to bypass them, they'll find a way. And that's at their own risk.

[thick breach]

I am not of that opinion, I am of the opinion that this is at the players risk...... And I think especially with coremods we as the platform provider should provide firm and secure "guidelines" which should not be breached what so ever

[swift thorn]

as long as java doesn't lock Unsafe access behind some jvm flag we can't do anything

[thick breach]

I generally have no problem if modders come to us and say: Hey I can't do X with your system. Could you make that possible

[thick breach]

It is probably true

[swift thorn]

you can always add module reads reflectively and so on, even if it gets stripped from the module-info.java file

[thick breach]

Yeah

I wish we could simply not classload certain classes

[vernal spire]

https://tenor.com/view/guidlines-pirates-of-the-caribbean-hector-babossa-georffrey-rush-gif-7844913

[swift thorn]

I think the first POC is to try to move forge's own coremods to a jij'ed plugin-layer library (from another source set)

that will give a noticeable improvement to forgedev startup time because instantiating nashorn scripts is very slow

(cc @jovial geode because we talked about coremods slowing bootstrap down a lot)

[thick breach]

Can we somehow "compile" those on the fly

And then store them in some cache?

[swift thorn]

you mean reuse the compiled version from another game launch?

the ideas I had to reduce this startup time impact, by order of preference:

• introduce Java coremodding API (as discussed)
• move the most common coremodding patterns to a combination of Java code + data-oriented configuration (not sure how feasible, probably unnecessary if we can do Java coremods, can always come later to make modders' life easier)
• load coremodded classes in parallel without initializing them at the start of the game - to compile the javascript code in parallel (requires the least changes, but basically this is just a hack)

reusing compiled javascript code from another launch could be an idea, but it seems complicated and I'm not sure nashorn allows it atm (we're using nashorn as a black box - not sure what is happening inside of it)

[thorn scroll]

The thing to keep in mind with unsafe is that there's legitimate uses beyond breaking boundaries of things, that Java is slowly trying to move into other classes - but many of those still use Unsafe. Limiting it is a terrible idea. For examples of such uses, see, like, fast atomic counter implementations, or wherever else you want manual memory management, or proxies, or lots of other bits and bobs

If you try to lock that stuff down, there's consequences. Let Java do that at their own speed - it looks like they're trying to move most possible uses of Unsafe to other things instead anyways

Like, VarHandles helped with the memory stuff, etc

But they're still working on it and trying to prematurely lock stuff down on this end is a terrible idea

You also have to appreciate that this is modding. Modifying things you're not supposed to is the name of the game in modding. The goal should always be to provide tools so that modders don't have to access stuff, or so that they can access stuff safely, not trying to completely lock stuff down. Encapsulation is a guideline

[jovial geode]

I don't think Nashorn allows this

I looked into it quickly once, but I forget the details

[swift thorn]

I'm well aware, I'm just saying we can't do anything about it

[thorn scroll]

Can't and shouldn't, that's the only point I was making

[patent kelp]

is it theoretically possible for a coremod to classload stuff it's not meant to?

and can coremods bundle their own libraries for use in that coremod? (for example a library with some util methods, marked as a LIBRARY)

[round wadi]

JS core mods are designed around complete classloader safety, making it fundamentally impossible to classload stuff you're not meant to. Ideally Java Coremods would have the same restriction, since... you know.

[swift thorn]

Most importantly, they're designed against the pre-module system

[patent kelp]

are java coremods forbidden to use reflection to do so anyways? for example, classloader scans for illegal accesses, or does it just explode in runtime?

[swift thorn]

java coremods won't prevent you from doing that, no

[vernal spire]

if you use reflection to bypass the safety measures you will break things, though

[swift thorn]

correct

[vernal spire]

I was thinking, in 1.12 there was a strong suggestion, so to speak, of having the coremods be a separate jar included via jar-in-jar.
as I understand the current system doesn't allow a lower layer jar (eg mod jar) to embed an upper layer plugin but if that limitation didn't exist, how unreasonable would it be to require that coremods are on a separate jar

[naive shoal]

coremods folder? /s

[swift thorn]

we're going for separate jar yes

and yes a mod jar can embed a plugin jar

what you cannot do is embed a boot or service jar

[vernal spire]

ah 👌

[thorn scroll]

Hell, I already have a tool that could do those hacks /hj

But yeah, you're never going to stop stupid hacky stuff. You're far better off putting systems in place that make it obvious what's going on so people don't go bug the wrong mod devs

[patent kelp]

that could be done, via a coremod lol (as well as some hacky classloading)

[errant seal]

Does this coremod change include mixin, mixin has special permissions, it is packaged with normal mods but doesn't cause errors like service does, can we allow mixin like this library (https://github.com/Lenni0451/ClassTransform) does to pass ClassNode/MethodNode?

[thorn scroll]

Wut? Bit confused what's being asked there. Mixin already transforms a ClassNode

[errant seal]

It's just a matter of writing my transformer and mixin together so that I don't have to write another service coremod just because the mixin doesn't support certain modifications - they're both mixins, just a lower-level one (

[thorn scroll]

So what exactly are you asking for?

If you need both a coremod and a mixin, you can write both a coremod and a mixin

[errant seal]

i mean ,why we can't use mixin class to receive a asm node, using coremod is complex than using mixin. It's easier to write Transformer and mixin together, isn't it?

[narrow frigate]

when you say "use mixin class to receive a asm node", are you talking about a @Mixin-annotated class receiving the ClassNode for their target class?

[errant seal]

yep

[narrow frigate]

nah, that doesn't fly with Mixin's design and architecture

the main point of Mixin is to do transformations that are valid, safe, and reliable
which is why Mixin has a whole special DSL (all of its annotations and such) for defining Mixins

that would be defeated quite a lot if the raw ClassNode was passed to the Mixin willy-nilly

[thorn scroll]

That just isn't how mixins work, yeah. The mixin class never gets loaded

It can't be, fundamentally

If you loaded it to apply stuff you'd load vanilla classes you shouldn't load then

Mixin comes with a degree of classloading safety despite everything being in the same jar (and hence on the same classloader), and trying to pass in a ClassNode to the mixin class would require loading it, which would defeat that

[errant seal]

so mixin just read mixin class bytecode as data source?

[thorn scroll]

Yes

[jovial geode]

you can transform the class your mixin targets in the postApply method of a mixin plugin

[narrow frigate]

@forest fox is https://github.com/neoforged/FancyModLoader/pull/79 meant to be an initial draft for this?

(so we can pin it here)

[forest fox]

It is

[narrow frigate]

👌