Thus spake Flint1b:
And if it wasn’t for the incompetence of many users, Vassal could be a
single build that would run on all systems. A single .jar file. Only
reason why Vassal comes in several packages is the installer which is
not really needed.
That’s not the only reason. You don’t get various native-looking niceties
on Windows and Macs with just a JAR (e.g., file associations, icons in
the dock, some other things I’m not remembering at this late hour).
–
J.
I’m looking forward to anything which will kill Apple or at least push them back into the 5% niche where they came from. If there won’t be a JVM for their new architecture, this might just be the reason for half the world’s developers and companies to stop buying Apple computers and for Apple to go back into their cave.
But sadly there are JVMs for all major computer manufacturers, there are JVMs for SPARC machines, JVMs for IBM’s mainframes. Apple won’t be so dumb and drop support for the #1 programming language.
I look at (and laugh at) those same indices. Remember when Java was at 26% on Tiobe? Now it is at 16% and even Tiobe admits some of that share is their method can conflate Java and Javascript in cases. Meanwhile the major OSes have become decidedly less hospitable to JVMs.
The reality today is developers use the language that gives the best performance and results on the target platform. And languages that run natively as opposed to a VM get preference for reasons including speed and security. So, when we are targeting MacOS we use Swift and/or Objective-C and when targeting Windows we use either UWP, C++ or C# if the Windows environment relies on .NET.
I’m not trying to start some sort of fight. I just think the reliance on JVMs is a millstone around the neck of VASSAL in the longer term.
It’s been a millstone ever since Vassal started, let alone into the future 
Well I am a developer and no, we don’t care about performance else we would use assembler/C. Java’s performance with modern VMs is almost as good as C++. The programming languages are not picked for technical reasons at all, it is most often a business decision, startups want a fast time to market and go for interpreted languages like python or PHP. Startups that made it switch to Java since it runs fast enough, its compilers are good enough to protect the code from incapable developers, and the availability of developers is the best. Big old companies have 20 years worth of Java code to maintain and to add features to and they can’t really choose anything other than Java. Even older companies have 30-40 years worth of Cobol code to maintain and to port to modern languages, and they choose Java for that most of the time.
If you are talking about desktop applications, they are only a niche market, and while Java never did shine on the desktop these kind of applications slowly die out and get replaced by web applications, where Java really shines in the backend while serving a JavaScript frontend.
Sooner or later the native languages will only really be needed for development on embedded devices, OS and system drivers. Even VMs are sometimes written in their own language now, there is a Java VM that is written in Java and not in C and it works pretty well.
That’s an excellent explanation of why Java is unsuitable for Vassal 
A Java backend that serves dynamic HTML5, JavaScript and WebGL content to browsers would be most suitable. Look at how Freeciv does it freecivweb.org/.
But Java is not the main problem of Vassal, the main problem is the project management, and what is called the “bus factor” in project management 
I strongly have the impression Joel is seeking to hand over once 3.3.x is stable. It might be an idea if volunteers came forward and they and Joel started working on a handover plan whilst getting 3.3.x stable.
I am helping where I can by automating as many things as possible, this whole new CI setup should relieve the whole team of many tedious duties.
But this “bus factor = 1.2” problem will be taken along to the new C++ Vassal from what I understand, nothing will change there. And many other problems that come with developing desktop applications i.e. dependency on GUI frameworks, need to install the application locally, user errors when installing, and there will be a whole new set of problems that have to do with platform dependency of native binaries.
Thus spake Flint1b:
I am helping where I can by automating as many things as possible, this
whole new CI setup should relieve the whole team of many tedious duties.
Which duties? Being on GitHub and using Maven and Travis are improvements,
but they’re not time-savers.
But this “bus factor = 1.2” problem will be taken along to the new C++
Vassal from what I understand, nothing will change there.
What excactly do you suggest? I’ve tried very hard to keep things which
need not depend on me from depending on me.
–
J.
Well for now you already know for every PR that a) it doesn’t introduce compile errors b) it doesn’t lead to failed unit tests, and there is more coming up, one of the next steps is failing builds when the formatting is off so you won’t have to personally check every PR and tell the contributors to format those elses and catches differently.
How to solve the bus factor issue, that’s a difficult question, in fact in most enterprise projects this factor is around 1.2
From a technical perspective, I think the releases should be automated as much as possible so they are only a click on the right button in some web interface, and anyone with the proper credentials is able to do it, and the C++ Vassal should be like that from the beginning. Also all the code for the website and for the backend systems could be published, like VASL has the code for their website published under their Github account.
From an organizational perspective, not an easy question. Short- and mid-term duties, maybe kick some butts and force others to do some of the things that you have to perform now. I mean of course to delegate, that’s how this is called in modern project management speech.
For long-term duties and decisions, I’ve seen some opensource projects use some kind of voting system, but I also know very well how it is if people who have been aboard for a week get the same vote that people have that have known the product inside out since decades. Maybe some kind of weighted voting system.
Another important thing is to actually have developers who you can delegate duties to, and with C++, I dunno… Some kind of cool modern web-based thing would probably attract more devs, the Java freaks like me would work on the backend, the frontend node.js jquery CSS people would be happy on the GUI side of things. If C++ is really necessary then the core could be written in C++ and served by a Java backend to the browsers.
As usual take anything I say about engineering with a 20-year-old grain of salt, but on the other hand I’ve worked professionally with web-based platforms for games and it has the huge downside of usually-terrible-interfaces and user experiences by comparison with applications. And the two things it does best: (1) allowing hundreds/thousands/millions to play in the same game at the same time and (2) allowing the rules of the game to change and evolve from day to day, really don’t apply to the 2-, 3-, and 4-8 player boardgames that we do here. So Java I can work with, C++ I can work with, C# I can work with, but web-based doesn’t sound like a good fit for these games.
The “bus factor” isn’t going to matter for now unless the bus actually hits. What you can see affecting Vassal right now is more what I’d call a pipeline problem – enough things are currently bottlenecked with Joel that he’s both constantly backlogged and has to push back stuff he’d rather be working on. But the solutions, if they exist, are basically the same ones Yan describes.
Since I’m at heart a designer, in this case of interfaces, modules, and features, I want the usual thing that designers and designer/programmers want on a team which is to be able to keep building a steady stream of new stuff. To the extent I get to weigh in with any suggestions about it, I’m just desperately hoping that Vassal 3 cleanups/small-improvements won’t have to come to a halt for the “let’s call it a year” that it will surely take to get a Vassal 4 engine to where it would make a meaningful difference to the games I do modules for.
Brian
I believe all the work I’ve been contributing to VASL for 3.3 compatibility is finished, as of last night. (At least, there aren’t any issues anyone has brought up that I haven’t solved…)
That should free up some time for tending to everything else.
This makes it seem like Java will be fine?
Thanks for all you do! VASSAL would be DOA without your efforts.
As to Freeciv, it is nice for what it does but has a big weakness - you cannot play it offline. VASSAL can be played offline and for those of us who have to travel a lot that is a godsend.
It’s been a millstone ever since Vassal started…
User Experiences with Big Sur?
Is this a good thread to fork into user experiences with Big Sur?
I usually wait at least a week before installing any new major macOS upgrades, but I find this one more compelling than I do most (at least recently).
I’m more than 100 turns into an Axis Empires game and don’t want to do anything that will break the module. If people face challenges after installing Big Sur I’d really like to hear about it.
Perhaps obviously, I’m not running Apple Silicon, but my hardware is relatively new.
I’m not sure that anyone will be able to answer you definitively, so I would be cautious. There was at least one report of a problem installing Vassal on Big Sur beta a few weeks ago. I am not sure how that resolved. Anyway, I will be trying it on a spare machine first.
The thread started by marktb1961, [url]https://forum.vassalengine.org/t/user-experiences-with-big-sur/11343/1] “User Experiences with Big Sur” is exactly the kind of stuff I was hoping for.
Seems to be working fine on 27" iMacs. Tentatively the only issue identified was on a smaller screen, and that seems to be resolved by changing a display preference.
Sorry about the clumsy HTML.