You could try asking around on Stack Overflow (e.g. stackoverflow.com/questions/528 … ktop-class). Some java guru there might have hints how to knock things into line on your specific platform.
Thus spake slimy:
nicholas@leonhartsberger:~/VASSAL/test$ java Main
Cannot start browser
Yep.
This is almost certainly not our bug, in that case.
I do know there has to be some way to make it work—I also use Linux
and I’ve never had to do anything to configure it.
Keep us posted on what you find.
–
J.
Okay I have found that the following works:
[code]import java.io.IOException;
public class Main2 {
public static void main(String[] args) {
try {
Runtime.getRuntime().exec(“xdg-open http://www.vassalengine.org”);
}
catch (IOException ex) {
System.out.println(ex);
}
}
}
[/code]
I had a look through the java code and as far as I can work out it might be looking for gtk3 on my system and I only have gtk2. My system adheres to the xdg specification.
So what would be nice is if 3.3.1 fell back to using xdg-open after checking java.awt.Desktop.
Thus spake slimy:
Runtime.getRuntime().exec("xdg-open
Oh boy. That raises some security concerns. My understanding is that there
are shell injection issues with Runtime.exec(), so we’d need to use
ProcessBuilder instead.
I’ve opened a bug for this:
vassalengine.org/tracker/sho … i?id=13083
This is a great example of how Java has always worked—it gives the
appearance of providing a facility, but then sometimes doesn’t, so you
have to do all the work yourself anyway.
–
J.
Okay I have reached a certain point. My latest (and possibly final) version of Westphalia is approaching upload readiness.
I need to do at least one more play through and once I cannot find any issues I should be able to upload.
That leaves me with 4 options.
- Someone tests the pdfs for me.
- Someone works on the bug and produces a version of VASSAL I can test with.
- I get upto speed with building and developing VASSAL.
- I come with a mini up java test case, that is security compliant and can just be slotted into the VASSAL code by someone else.
From my point of view 2.) is the perfect solution. Of course it may be less perfect for the person working on it who is presumably unaffected by the bug.
Solution 1. is fairly quick and easy. In fact I have put this request out on Boardgamegeek so it may not require the cooperation of anyone on this site. Of course it leaves the underlying issue unresolved so I would be unhappy. But then what do I matter when the eventual heat death of the universe is inevitable as the physicists tell us. Given that I am not ready to upload yet anyway and it may not be necessary, I suggest nobody considers this one.
Solution 3. is doable but simply daunting. Looking at the threads on this board there does not even seem to be a consensus on how to start. I have done Java in the long and distant past but it was always my worst programming language. I would need to go right back to the beginning even if I was able to race through the learning process.
Solution 4. is possibly a nice workable compromise, where I maximise my contribution. The downside is I still need to refresh my java knowledge. I just can’t do it with what I have at my finger tips. At which point it may be that I might as well do 3.
So unless anyone has any better ideas, I ask if someone can give me some useful pointers to get started. We’ll leave it open whether I adopt solution 3 or 4 for now.
What was the problem exactly?
Anyways, in that module on google drive, I can open the vassal module pdf and the game rules pdf.
Running Vassal 3.3.0 on linux (Ubuntu 20.04), Java 11 openjdk (OpenJDK 64-Bit Server VM GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02, mixed mode, sharing)).
Why don’t you have gtk3 installed? The first version of gtk3 came out 9 years ago…
And about bug 13083, which Linux versions are supported by Vassal exactly? What if someone comes around with a Debian 1.1 Buzz with kernel 2.0 from 1996 and wants Vassal to run on it?
I am not 100% sure it is a gtk3/2 issue. That was based upon my digging around in the java code and hints I saw on the internet.
I can describe more exactly what I do know. The current VASSAL code relies 100% on that java Desktop code. It uses a number of heuristics to determine if it is willing to launch a browser or not. I believe it does not actually try. I believe my system is falling fowl of the gtk2/3 issue. If correct this is a pretty arbitrary heuristic because it probably tells you nothing about whether you can launch a browser or not.
The work around approaches the problem from a different angle. There is an XDG standard that Linux Desktops are supposed to conform to. If you system conforms then the xdg-open script is guaranteed to be able to launch a browser. Obviously the XDG approach won’t work on Windows machines, but a 2 pronged approach that is guaranteed to work on all windows, Mac and compliant Linux systems seems like a good thing to me.
Thanks very much.
I am using the latest version of Stable Debian with an XFCE desktop.
Why would anyone want to run such an old version of Linux?
Anyway that is a red herring. The problem is not that I am running an outdated version of Linux. The issue is that VASSAL is relying on a Java class that uses some arbitrary and undocumented heuristics. Probably that Java should be updated, but that would not really help either unless people upgraded to that specific version of java which might cause other problems.
I exaggerated, but the question still stands, what is the minimum version of linux that is required? I know Vassal is a Java application but what if Java needs a certain minimum setup on a linux machine?
That is a whole other problem, Vassal uses the swing component of Java, and this desktop integration to open the browser that was added to Java in 1.6 IIRC. Both are kind of like unloved and unwanted children of the Java community, have not received updates since years and will not receive updates anymore. We can be glad they are still parts of Java and that Vassal still runs at all.
Thus spake Flint1b:
“slimy” wrote:
Why would anyone want to run such an old version of Linux?
I exaggerated, but the question still stands, what is the minimum
version of linux that is required? I know Vassal is a Java application
but what if Java needs a certain minimum setup on a linux machine?
It may, but in usual slipshod Java fashion, there is nothing to tell
us what that setup is.
Falling back to xdg-open (via ProcessBuilder) would work, and fits in well
with all the other workarounds for ways that Java has dropped the ball over
the years.
–
J.
Well, don’t blame Java, it’s working as designed 
From docs.oracle.com/javase/tutorial … sktop.html:
This whole Java Desktop API was mainly written for Windows, just remember how back in the day Linux and Mac desktops were a niche occurrence. They never guaranteed it to work on every Linux installation, they said up front that this API will not work without the proper Gnome libs being available.
And since the Desktop API uses JNI to access C stuff, I think C++ developers should be able to find out which Gnome libs are needed exactly, here for instance someone used strace stackoverflow.com/questions/332 … e-on-linux .
The xdg-open solution is good, it will work around this Gnome requirement and use Desktop API if the proper Gnome libs are available, and xdg-open if they are not.
If you want to call out Java and the mistakes they have done, call out the real ones like the Clonable interface, its glorious sibling the clone() method, or well meant optimizations that inline static final strings into every class that references them. Or the memory leaks that can happen when beginner developers try their hands at implementing equals/hashcode, or use static fields for java.util.List.
Have a look at this PR:
Thanks. This works fine. Looking at the code I notice a couple of things.
-
You were wise to get to this yourself rather than letting me try it. My knowledge of Java is so rusty I would have been just fumbling around wasting your time.
-
I am not entirely clear what security benefits merely using ProcessBuilder confers. I thought you needed to validate the inputs as well. I am not clear how one could meaningfully validate the url argument and that is something we control anyway. With the case of “xdg-open” we are trusting that noone has tweaked the PATH environment variable. Perhaps we should hard-code the path to “/usr/bin/xdg-open” to make sure it has not been redirected to something else. Or perhaps override PATH to something sane. I would have suggested cleaning out the environment variables but it legitimately relies on quite a few of those (BROWSER, HOME, XDG_…, KDE_…, GNOME_… etc )
Thus spake slimy:
- I am not entirely clear what security benefits merely using
ProcessBuilder confers.
I believe ProcessBuilder.start() is wrapping a call to execvpe()
internally. I’m not so sure about Runtime.exec().
I thought you needed to validate the inputs as
well. I am not clear how one could meaningfully validate the url
argument and that is something we control anyway.
I don’t know what we could possibly do there for validating the URL.
With the case of
“xdg-open” we are trusting that noone has tweaked the PATH environment
variable. Perhaps we should hard-code the path to “/usr/bin/xdg-open” to
make sure it has not been redirected to something else. I would have
suggested cleaning out the environment variables but it legitimately
relies on quite a few of those (BROWSER, HOME, XDG_…, KDE_…,
GNOME_… etc )
If someone has set the PATH to something bad, that’s happened before we
ever got there, and xdg-open could also be in /usr/local/bin. I’m not
seeing any injection possibilities here, as ProcessBuilder isn’t starting
children via a shell.
–
J.
Okay. Well I have nothing further to say and it works for me.