No anymore

So now none of the cross platform stuff works in the sdk now that oracle shafted netbeans.

There is no anymore so is there a place in the sdk we can edit to pull in the jre for cross platform stuff rather than downloading this manually?

Also, the obfuscation doesnt work either, there’s this error even though the platform exists and so does the jar.

Can’t read [C:\xxx\${platform.home}\jre\lib\rt.jar] (No such file or directory)

As I work through this nightmare I am seeing this as the best option so far for the JDK.

My reasoning is this release schedule.

I found this for deployment but so far I think this is crap and there needs to be an easier way to get this to the user.

Looks like a ton of work needs to be done to get SDK back in shape or it will need to be abandoned.

I am not sure how this is going to work with netbeans but it should be no problem I would think. Otherwise I guess its eclipse or nothing.

Edit: One more thing,

AdoptOpenJDK seems to be a reasonable source for obtaining pre-built JVMs. That said, I think the source is not all that important as long as it’s handled as part of the SDK build process - there’s always another recent and trustworthy OpenJDK build out there. The most important aspect of this, I think, is keeping the SDK up to date with Java releases. JDKs 9+ have come a long way and offer many tools that could be a huge benefit to game developers (custom runtime images, anyone?), and future projects (like the Graal JIT) are just as promising. Keeping the JDK up to date is going to be critical to the SDK’s long-term prospects, and AdoptOpenJDK seems like a fine source for now - but I’m personally not concerned about what happens if they go away since there are (and will be) alternatives.

Not quite sure I follow. Getting a JNLP-bundled application to run was always kind of a crapshoot in my experience anyway. Despite what the proponents of Web 5,000.0+ would lead us to believe, I’ve never seen a user experience that could rival a reasonably well-packaged native installer and application. I wouldn’t go so far as to call installers “easy” per se, but they are a well-known problem with many viable solutions. Once you have a jlinked runtime for your target platform, it’s all just bundling things in a suitable way after that. In the absence of JNLP we’re pretty much just left with doing what many games do today and building/installing an updater alongside the game application.

Thisis what caught my eye and if I understand this, its saying they dont need the jre now but the openJDK… pre-installed.

Customizing the Java 11 runtime:

  1. Unfortunately, there’s no way to customize cross-platform Java runtimes, so we need an intermediate Windows computer—let’s call it the IWC. (I’m going to come right out and say this is the major drawback of our approach.)
  2. OpenJDK 11 prebuilt binaries are installed on the IWC.

If they need it pre-installed then Adopt has the installer already so thats why I figured they were best option to.

I believe its saying to make it cross platform they had to have a computer that had the openJDK installed so they could use jlink to build the file.

If this is true, how does a person make this work for other os?

Edit: If not true, then where is there a good tutorial on this cause the jlink stuff is pretty short.

So Java 9 added the concept of “runtime images” - unlike the old JRE, these contain only the VM itself and whatever JRE “modules” you specify to include. The result is a custom runtime that (a) runs only on the platform you built it on, and (b) includes only the standard library packages that were in the modules you selected. After it’s built, that’s it - you can’t really customize it per se (although at runtime you can still change the classpath/module path via command line arguments).

Sort of - to build an image for Linux, you need to have a Linux machine to run the jlink on. Same for Windows, Mac, etc. It’s not cross-platform in the sense of building the VM image once and running it anywhere.

What we’d have to do is jlink the runtime on each OS that we want to target (as part of the SDK build process) and include all of those pre-built runtimes as part of the distributed SDK. It’s no materially different than building the jME native bindings for each target platform.

That’s why they’re talking about needing the “extra” Windows machine - the developer was working on Linux but needed a jlinked VM for Windows. Once you’ve built the VM once you don’t need to do it again (unless you want to include more modules or you’re updating to a new VM, etc.).

Adopt has the jre also and I think I read they will continue too so I am going to try and download the jres tommorrow and see if the SDK will work using them.

1 Like

This is part of the problem with SDK.

Hard coded address.

Should be a prefilled box you can alter.

If the JRE stuff works without anything special being needed, maybe this could be fixed in the SDK.

1 Like
> Task :overrideHarness FAILED

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Robert\Documents\NetBeansProjects\sdk\build.gradle' line: 5

* What went wrong:
Execution failed for task ':overrideHarness'.
> Cannot find targetFile: C:\Users\Robert\Documents\NetBeansProjects\sdk\netbean

As is to be expected, always some other :poop: is always screwed up.

I saw this thread, but no idea wtf a soft link is /sac but its expected to throw an exception because of course the file does not exist.

Since netbeans is no longer online at oracle, maybe its related? Not sure how to get this file.

          def patch_file = { f ->
            def g = file("harness-override/" + f.getName())
            if (!f.exists()) {
                throw new GradleException('Cannot find targetFile: ' +  f.getAbsolutePath());

No idea where f comes from or how it gets decalared here since I dont use this lambada crap (java is intended to be an expressive language not terse!).

Any ideas?

it’s a path probably, judging by what it calls and how it’s being used.

Lambda’s are just shorthand declarations of functional interfaces.

It basically means you don’t have to write the whole thing since there’s only one thing you can write.

so instead of writing

app.enqueue(new Thread() {

    public void run() {
        blah bleh blah

I can just write

app.enqueue(() -> {
   blah bleh blah

And since there’s only a single function (the run method) in the interface, it can work that out all by itself.

EDIT: My mistake, it’s a File object, not a path.

patch_file = { } is defining a closure. Normally closures in groovy have one argument called ‘it’… but often it’s more readable if the closure defines a different name for that argument. The part before the → defines that.

foo = { arg1, arg2 ->

Would define a two argument closure with arguments of no particular type.

foo = { File f1, File f2, String arg3 ->

Would define a three argument closure with the types as specified.

Edit: and note, closures and lambda are not really the same thing but they are frequently used interchangeably. Here “closure” is more correct.

Yes a path to a file that doesnt exist. Since this folder gets populated during the build, I have no idea where its supposed to get this. I read this in the harnes-override folder.

Since our SDK is based on Netbeans we download the so-called Netbeans Harness from official sources.

So I am thinking this is related? and maybe since netbeans is no longer exsists at oracle may need to download it somehow from apache maybe?

It’s actually defining a method (A bit like a javascript function, i guess), and calling that method directly below it. .

It’s a closure. Just like it would be in javascript.

This is groovy… so it’s a closure. You can call closures like functions/methods. It’s convenient.

Edit: but yes, you are 1000% correct that it’s being called with file arguments where you illustrate. :slight_smile:

Also, in case “relative to what?!?!?” comes up. file() is part of the gradle API that will resolve a file relative to the project directory.

Yep. Wasn’t trying to say any different, I skipped the part where you explained what it was and just tried to explain how I thought best, was all :slight_smile:

1 Like

All three files exist in the harness-override folder but I am thinking its supposed to download these from somewhere to compare them to those files?

The harness-override lives in the same folder as the netbeans folder.

Note: it constructs the g from the harness-override directory but it’s checking the existence of the supplied file.

And if you are ever curious what these actually point to and are able to modify the .gradle file, you can just print them out:
println f.getCanonicalFile();
println g.getCanonicalFile();

…and so on.

I found these files in the JDK under harness so I copied them over.

Seems to of worked so far. will see if something goes crazy after it finishes.

What a f-n mess.

> Task :buildSdk FAILED

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\Users\Robert\Documents\NetBeansProjects\sdk\build.gradle' line: 6

* What went wrong:
Execution failed for task ':buildSdk'.
> The following error occurred while executing this line:
  C:\Program Files\NetBeans 8.1\harness\suite.xml:187: The following error occur
red while executing this line:
  C:\Program Files\NetBeans 8.1\harness\build.xml:174: Cannot compile against a
module: C:\Program Files\NetBeans 8.1\platform\modules\org-netbeans-api-template
s.jar because of dependency: org.netbeans.api.templates > 1.7.1 found 1.6.1

No wonder no one helps with SDK. Not worth this amount of trouble realy just to try and change a few lines of code.