The new Apple Silicon Macs will be moving MacOS to RISC as opposed to the current x86.
Also (and more immediate) MacOS Big Sur deploys in just about 3 months and has a lot of base level changes to the OS.
Now it is likely that Big Sur in and of itself will run VASSAL still. Apple Silicon is another matter. I understand the program itself can run in their Rosetta x86 emulator but the JVM is likely another matter.
With the large population of users of VASSAL on the Mac platform, will this development see a higher priority placed on getting VASSAL off of Java?
The new Apple Silicon Macs will be moving MacOS to RISC as opposed to
the current x86.
Also (and more immediate) MacOS Big Sur deploys in just about 3 months
and has a lot of base level changes to the OS.
Now it is likely that Big Sur in and of itself will run VASSAL still.
Apple Silicon is another matter. I understand the program itself can run
in their Rosetta x86 emulator but the JVM is likely another matter.
I expect that the JVM will be compiled for the new Apple architecture.
With the large population of users of VASSAL on the Mac platform, will
this development see a higher priority placed on getting VASSAL off of
Java?
No. I cannot place a higher priority on getting VASSAL off of Java,
because it’s already my highest priority for the project. I simply can’t
move on to it yet while there are new bugs in 3.3 to be fixed. Once we’ve
reached the point where we’re only getting reports of old bugs again,
V4 will receive my full attention.
This will be a minor marketing gag for the Java community, to port their already existing ARM JVM to yet another ARM-based archicture. Nothing will change for Vassal, most likely not a single line of code will need to be changed to get both old and new versionf of Vassal running on these new Macs. In fact, existing and future Java applications will most likely have far fewer issues running on the new Macs than applications written in C, ObjectiveC, Swift and whatever else can be natively compiled. If anything, be glad that Vassal is still a Java application and did not switch to C++ yet
That actually makes me interested in… what’s the multiplatform strategy for Vassal 4? (Three different app builds? Some 3rd party multiplatform thing like Unity?) Just curious in a developery way.
That actually makes me interested in… what’s the multiplatform
strategy for Vassal 4? (Three different app builds? Some 3rd party
multiplatform thing like Unity?) Just curious in a developery way.
I will address this question in due time, when we finally have a 3.3
release I can unreservedly recommend to everyone and I am not also
helping the VASL guys become 3.3 compatible. I’m just not that far along
and I need a bit of time to page all of this back into my working memory.
Too many plates being spun at the moment.
I’m presently trying to fix one of the files in VASL which has variables
named in Hungarian notation. This makes me VERY ANGRY and I’m really not
in a state to answer any questions because of it, and in the future I’m
just going to tell anyone who shows me code with Hungarian notation
variables that they can stick it up their l_objAss.
I think the Reddit thread is off base as they are acting like all ARM are the same. Apple Silicon is a very different beast - remember Apple has an Architecture License for ARM. They use the ARM flavor of the RISC instruction set but they also have a lot of custom instructions and their SOC design has deviated a lot from standard ARM (and is a lot more advanced).
One of their posters seemed to get that the JVM would need to be decompiled then recompiled for Apple Silicon (Universal 2 binary). Otherwise the JVM would have to use Rosetta even if the program did not.
As to getting off of Java, there are good reasons why only a small number of tools still use JVMs. JavaScript is alive and thriving but Java for application building has been slowly dying for a while.
Nowadays with modern OSes and modern code development VASSAL is probably best served with separate builds for Windows / Linux and MacOS. The MacOS build will have a side benefit that it will run on both Macs and iPads / iPhones.
Which planet is this about? Ours? On our planet, Java and its JVM keeps running vs. C for #1 on all main programming languages indices, is the main language along with its child Kotlin for Android development, runs behind the curtains at all major corporates. Netflix serves billions of users from a Java-based architecture. Twitter runs on Java.
If you are a Java developer, your job is pretty much safe for at least the next 50 years. It is today what Cobol was 20-30 years ago.
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.
As to getting off of Java, there are good reasons why only a small
number of tools still use JVMs. JavaScript is alive and thriving but
Java for application building has been slowly dying for a while.
Which planet is this about? Ours? On our planet, Java and its JVM keeps
running vs. C for #1 on all main programming languages indices, is the
main language along with its child Kotlin for Android development, runs
behind the curtains at all major corporates. Netflix serves billions of
users from a Java-based architecture. Twitter runs on Java.
I’m in agreement with Yan here regarding the JVM on any new architecture.
It’s another ARM architecture and there will be a JVM ported to that
fairly quickly. The JVM is written in C after all, and there has to be
a C compiler for Apple’s new chips or they won’t be able to do anything
at all.
As much as I look forward to anything which will kill Java, I suspect
that it won’t be the new chips Apple will make.
(JavaScript is totally irrelevant here—the only thing Java and JavaScript
have in common is that they both start with “Java”.)
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).
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.
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.
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.
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.
