ScriptFunction deprecated?

Ignition 8.3 Early Access
1

Hi all,

We make use of ScriptFunction like so:

    @ScriptFunction(docBundlePrefix=docBundleName)
    public PyObject enterBadge(
        @ScriptArg("assetId") PyObject assetId,
        @ScriptArg("badgeNum") PyObject badgeNum,
        @ScriptArg("logIn") PyObject logIn,
        @ScriptArg("tStamp") PyObject tStamp) throws JythonExecException, ScriptManager.UndefinedFunctionException {
        return enterBadgeI(assetId, badgeNum, logIn, tStamp);
    };```

but it seems in 8.3.0

import com.inductiveautomation.ignition.common.script.hints.ScriptFunction;

is no longer present - what do we do instead?

Thx
2

@ScriptArg is still supported. @ScriptFunction has been replaced by @JythonElement with the same usage.

All described in the Google Doc for the API changes.

3

Phil,

As usual you're a superstar! Really must buy you a beer one of these days. I haven't stumbled across the Google Doc for API changes yet [ only started looking at 8.3 today ] can you supply a link please?

4

Pinned topic: 8.3 Early Access Now Available!

5

Thanks Kevin - just requested access to the docs.

6

Did somebody end up approving your access?

7

Hi Kevin,

I can get to the Migration Guide but I can't access the recommended one that it links to:

8

I'm a bit stumped at the moment - things may get cleared up when I get access to all the documentation but I'm currently trying to get a build going that will work for 8.1.x and 8.3.x using gradle parameters and some final static java flag to control the build. The problem I'm having is with the JythonElement v ScriptFunction annotations as mentioned above.

In C++ I would just #ifdef 83BUILD use JythonElement #else use ScriptFunction type shenanigans but we can't do this in Java - annoyingly.

Anyone got a solution for getting a build to work for both Ignition platforms?

9

You cannot.

Make a branch for v8.3.

1 Like
10

Yep, branch. It's what we do as well.

11

See 8.3 Early Access Now Available! - #3, we've pulled it out of the restricted document and put it into a PDF for now.

1 Like
12

Thanks guys, I was hoping to avoid the need to maintain a long-running sub branch but it looks like it's the way to go - hopefully shouldn't be too painful. I was a bit surprised that ScriptFunction was simply replaced and not deprecated. Just makes it a pain for developers - increased development friction etc. Long time Android dev and the standard pratice from Google was to long term deprecate stuff so that existing apps didn't get too broken by an API update. The 8.3 branch that I now have to maintain puts us in a situation where we'll be maintaing the two branches for years to come since I don't see all our customers jumping to 8.3 anytime soon. If you fancy putting ScriptFunction into a future 8.3 release as a Deprecated annotation then that would be the perfect solution for me....and all other customers that make use of ScriptFunction

13

IA doesn't make any long-term guarantees for SDK users. Not even within a given LTS series. Enough infrastructure changes that branches are necessary. I maintained multi-platform module files in the 7.5 through 7.8 releases. 7.9 broke them all. 8.0 broke everything again, and 8.1 again.

More features => more breakage.

FWIW, cherry-picking across branches works really well....

14

Even if we reintroduce ScriptFunction as deprecated (I'm not totally against this, other than ideologically) I'd be surprised by any non-trivial module that would otherwise be able to compile against both 8.1 and 8.3.

15

Even if we did this, it would just get culled with the rest of the deprecated stuff in the next major release.

We're not google, this isn't android, we're not trying to keep your code working without changes from major version to major version, forever.

1 Like