I feel I should know the answer to this... how do I determine how long the Lucee server has been up for? Having googled, I seem to be able to do this to get how long the whole JVM has been up for:

uptimeInMillis = createObject("java", "java.lang.management.ManagementFactory").getRuntimeMXBean().getUptime()

But: a) wondering if there's a more CFML- /Lucee -idiomatic way of doing it; b) that is not reset by a Lucee Server restart (via the admin), for obvious reasons. This is probably not an issue for what I need, but figured I'd mention it anyhow.

Maybe use Server.cfc and store the getTickCount() into server cope: https://docs.lucee.org/guides/cookbooks/Startup_Listeners.html

Yeah I wondered if I'd need to fall-back to that.

@Adam Cameron

createObject( 'java', 'lucee.loader.engine.CFMLEngineFactory' ).getInstance().uptime()

Hey @bdw429s thanks pal. Have stepped away from my work env for the day, but will experiment with that tomorrow.

@Adam Cameron I can bet that's more of an oversight than anything. Micha loves to use interfaces, especially so the loader can parlance about the objects it's going to have in its method signatures which may come from the core, and therefore aren't available at compile time. The CFML Engine factory uses a static method to act as a singleton pattern for fetching the CFML engine, and its method signature points to the CFMLEngine interface like so

public static CFMLEngine getInstance()

However, at runtime, the actual class instance you get is the

CFMLEngineImpl

class which comes from the runtime (lco. or core file). So what happens is after creating the interface, Micha will add methods to the actual implementation and not go back and update the interface. (He only likes to update interfaces for major Lucee versions, so they tend to stagnate). So this means the compiler wouldn't allow you to use that method from within Lucee's loader since it's not in the interface, but there's really no reason you can't use it in CFML (which is all based on reflection anyway). As far as whether you "should" use it, pretty much all of Lucee's internal classes come with the "at-your-own-risk" sort of disclaimer. The fact that he never added that method to the interface just means things are a bit sloppy, it's not IMO any official statement of whether the method is fit to use.

So this means the compiler wouldn't allow you to use that method from within Lucee's loader since it's not in the interface, but there's really no reason you can't use it in CFML

Yeah makes sense.

changing the loader breaks the ability to update, so we avoid it at all costs. So Micha uses the Pro suffix, like ConfigWebPro to extend interfaces without changing the loader signature. https://dev.lucee.org/t/how-to-code-around-limitations-imposed-by-the-lucee-loader-architecture/8396

I mean... to me... if we're saying that to get the Engine implementation one would use the

getInstance

factory method, and the one calls

getUptime

on that... then

getUpTime

really ought to be in the interface. I get that classes implementing interfaces can obvs also implement other methods, but what we're talking about here seems -as you say - sloppy to me. If

getInstance

starts to return some other implementation of

CFMLEngineImpl

that doesn't additionally implement the

getUptime

method... code breaks. And for purely sloppy reasons, which is kinda counter to the whole idea of interfaces in the first place. Anyway, never mind... I doubt we'll ever be using a version of Lucee after 5.x anyhow, so if it works for now: all good. I'll put some tests on it so we know if it happens to break in the mean time.

i'd say just file a PR asking for start time to be added to the server scope

I don't wanna cause your devs unnecessary work when they should be focusing on important stuff.

nah, that's a good one, it's only a few lines of code and it means lucee devs don't need to dive into java

changing the loader breaks the ability to update

@zackster But this isn't a blanket true statement. Adding a method to an interface in the loader would only break if the method didn't exist in the implementation class from the runtime. i.e., if we dreamed up a brand new method to a runtime class and added it today, adding it to the loader would break anyone • using a newer loader • using an older runtime which makes sense. But this can't be a white flag we just throw up and never keep anything in sync

Note the age

The question then becomes, when is "future"? Lucee needs to have an actual strategy for defining "future" and not just saying blanket things like "we can't break the loader" etc

I doubt that was the right approach at the time. Adding it to the interface first and then to the implementation would be better. Also might suggest if there was no basis to put it in other implementations that it was premature interface extraction.

Lucee actual strategy is just don't break anything unless we have to

(could well have been a good reason, but I doubt it)

Yeah, the entire idea is built around the concept of someone installing Lucee once and leaving the loader jar in place for years while only applying core updates via the admin.

That's not a strategy, Zac. That's just "being a programmer"

should Lucee adopt ACFs horrible update strategy?

The irony is the "bad" scenario is when the loader jar gets "ahead" of the core jars, which is actually not very likley unless you install a version of Lucee, then downgrade it, whcih I actually thought Lucee prevented against

Oh excellent the "whatabouttery" has arrived. I wondered where it had got to

@bdw429s doesn't it... i know the admin interface prevents it

lol, it doesn't need to be a false dichotomy. Just some pragmatism. Major Lucee updates are the only time Micha likes to update the interfaces, and I understand the reasoning. That means Lucee 6 is our chance to update some of this stuff.

Lucee 6 won't being updating the loader interface

That's sort of.... unfortunate

why, as a normal end user of lucee, being able to just update to 6 is nice

Now years later, just kidding-- you never get those, lol

i'm having enough trouble pushing to dump java 8 support lol

Extra irony is that CommandBox users don't even care as every engine download is a fresh loader anyway so the distinction is minimalized

of course

Plus again, is there a serious concern that people will update their servers to the latest Lucee 6 loader jar and then run very old Lucee 5.x core jars? I'm just not seeing this as a reasonable concern

no the main concern is the other way around. at the moment you can update a 4.5 loader to 5.3.9

Do you mean loader or core. because I've never seen anyone update their loader jar only and leave their core version behind.

loader interface errors can be very confusing

That's not answering the question

we are furiously agreeing there

lol

let me try that again, you can deploy a 5.3.9 core on top of a 4.5 loader

Correct, but that's not a reason not to update the 5.3.9 loader, right?

but i'd rather add it to the server scope, avoid diving into java / internals where ever possible

irrelevant

currently we have no plans to rev the loader signature

Thanks for the clarification, tho it does sound like the reasoning changed from "Because it would break stuff" to "well, ok it wouldn't actually break anything, but we just don't want to do it".

yeah the loader often shits me, this bug requires loader gymnastics https://luceeserver.atlassian.net/browse/LDEV-1673