> it's a "low impact" dependency in terms of side affects and complexity.
I wish that were true in my experience. But we have struggled to support {macOS, Windows, Linux} x {x86_64, arm64} with JavaFX and one .jar for our application.
My point about 4 line dependency is to point out that the barrier to entry into FX is low. What you are doing I would consider unconventional, as demonstrated by all of the hoops you're jumping through to achieve it. Packaging, yes, is still a bit arcane at this point.
My project, https://github.com/willhartung/planet packages macOS and Windows installers, and can be run as a fat jar on a Linux machine (tested on Ubuntu). You can look in there to see my POM file, and my build scripts. They're much simpler than what you're doing. I don't have a package for Linux, as I mentioned earlier, it was just a bit to confusing to figure out Linux packaging for my tastes, so I punted. If there was crushing demand for it, I'd look into it deeper.
None of those artifacts are "cross platform". It's not a single artifact for all platforms, they are platform specific. I build the Mac one on my machine, and the Windows and Linux versions on VMs. Currently, the vision for Java distribution is to bundle the runtime with the application. Use jlink and the module system to narrow down your JRE, and jpackage to combine them into an appropriate, platform artifact. jpackage requires to be run on the host OSs. I do not have ARM versions of any of my code yet.
If you want to ship a cross platform jar, then it's probably worth your time to require a JDK with FX already installed. Azul does this, I think there are others. Then the FX, and it's platform specific binaries, are no longer your applications problem.
Also, there is a project, https://jdeploy.com that offers tooling and infrastructure to distribute native FX bundles, it even offers automatic updates. It will install its own JDK in its own directory structure to run your applications. If you have multiple applications, it will share the JDKs among them. It's quite clever, and perhaps worth considering depending on your requirements. I chose to not do that just to make my projects as simple as practical for the end user and myself.
I'll be fair, getting to this point was not drag and drop. jpackage and jlink can be fiddly to get started with. Documentation can always be better.
> What you are doing I would consider unconventional
It wasn't before JavaFX was removed from the Oracle JRE. That is my point. JavaFX used to be a trivial dependency, but now it is quite painful in otherwise identical configurations, definitely not "low-impact."
> If you want to ship a cross platform jar
We do. Isn't that the point of Java, "write once run anywhere"?
This program is also used as a library in autograders. We do not want to distribute 5 versions of each autograder for 2-4 assignments. The autograder should be distributed as 1 jar. Undergrad TAs are creating that jar and may not have knowledge of complex CI pipelines etc.
> then it's probably worth your time to require a JDK with FX already installed.
That is not appropriate here. This is an educational tool, and students are enrolled in other courses that use Java frequently. We should be able to use the same JRE that students already have installed — it is unreasonable to require installing a different third-party JRE to run a digital logic simulator. It also adds another hurdle for freshmen/sophomores who may not have a natural ability for juggling different JRE installations. (Source: We tried requiring Azul and it was painful for everyone.)
> I do not have ARM versions of any of my code yet.
We have >900 students in this class, so it is necessary to support M1/M2; in fact, a large portion of our students had M1/M2 laptops. It sounds to me like you could just provide a fat jar in your case, actually. Supporting aarch64 is where we hit problems with our fat jar[1], since the aarch64 native libraries have the same name as the x86_64 libraries.
To summarize my point: yes you can make the build/install process more convoluted and avoid this problem. But we have an installation flow that has been battle-tested by thousands of students for 13 years (download circuit simulator .jar and run it) we have no good reason to abandon. The combination of the arrival of M1/M2 and JavaFX getting yanked from the JRE has made supporting our existing (extremely reasonable) flow nothing close to "low-impact."
Hi Austin, nice to see you on here! Glad you find it useful. If you want to try out the VSCode.dev experience too, check out https://vscode.dev/quantum/playground/. Let us know what you think!
You know, I suspect most people reading this weren't around for the "XML everything!" era and don't get the joke. They legitimately think it's a post about an experimental markup language.
Not just XML, but I see this article as a direct jab at XAML specifically.
XAML, the famously verbose dialect of XML tied to .NET, which hasn't seen any changes made to the core language design despite its numerous ergonomic failures (e.g. the xmlns mess). I can't explain why no attempt has been made to make it more usable.
> Basically, CSAML is an alternative syntax for C# based on XML and, more specifically, on XAML, the Extensible Application Markup Language that plays such an important role in the forthcoming WinFX and the Windows Presentation Foundation.
Almost as if someone on the inside at MS would have knowledge of what was in development and decided to poke fun at it. 2008 was when it was released, it was in development prior to that.
> I'm familiar with Zotero and Calibre, though both are desktop only
There's a third-party Zotero client for Android named "Zoo for Zotero" that has worked well for me: https://play.google.com/store/apps/details?id=com.mickstarif.... However, I usually use it to read academic papers on my phone that I have already added to my library using my computer. I tried adding something new to my Zotero library on my phone as I was typing this comment, and sadly the interface seems a little clumsy: I can add papers to a collection but not a subcollection
> on a sidenote, why arent authors and researchers publishing on scihub directly?
Many compsci/physics/math researchers already submit preprints (or post-prints even) of their papers to arXiv, which is public: https://arxiv.org/. I'm confused, is there a reason why they should they submit to Sci-Hub too?
They're not always quite the same, often arxiv have doesn't updates reflecting changes during the publication process (not including formatting). Can be annoying, the can be subtle differences and people aren't really careful about which versions they use or cite.
I'm excited to see that the RV32 AES instructions now have separate rs1 and rd fields, because the previous version combined them into just rt, which was kind of annoying from an implementation perspective, since you had some register that was both input and output (iirc, unlike any other RV32 instruction previously implemented on that hardware)
It appears to target "GPGPU" APIs like OpenCL and CUDA via translation, making it more like Xeon Phi in that its architecture and instruction set is vaguely GPU-like, while it lacks video output or fixed-function pipeline hardware for graphics stuff.
Also like Xeon Phi, I'm guessing you could add that hardware, it just hasn't been done because the other priorities were more interesting, and the practical performance would be "disappointing".
Hold on, who is "we"? Personally speaking, git works the way I think it does. Granted, I've written my own (simple) libgit2 frontend, so I understand the git internals fairly well, on a high level at least
I haven't looked into pijul, but why is teaching people a new tool more helpful than teaching people how the tool they already use works? (Like the OP blog post does.)
Am I blinded by the knowledge I gained from writing my little tool and learning about git internals? I get that a tool you need to learn the internals of to use is probably a bad tool, but is asking git users to understand the contents of the OP blog post really too much? Maybe I'm just a git fanboy...
I'm not the GP, but I agree that git should work the way "we" think it does, and I think a reasonable definition of "we" in the context of Git Users is probably SaaS/Startup/SMB software engineers.
Git is popular enough to have many thousands of different use cases, but I would speculate that the distribution of use cases probably follows the distribution of public Github/Gitlab repos pretty closely.
> Personally speaking, git works the way I think it does. Granted, I've written my own (simple) libgit2 frontend, ...snip...
> Am I blinded by the knowledge I gained from writing my little tool and learning about git internals?
Yes.
> I get that a tool you need to learn the internals of to use is probably a bad tool, but is asking git users to understand the contents of the OP blog post really too much?
Yes. Or rather, knowing git's internals is incredibly helpful if you've already decided to use git and now you're deciding what workflow to use to develop software, because you can match your mental model of how to use git to the way git naturally wants to represent your stored work.
However, if you come to git with an existing mental model of software development, and that existing mental model includes the idea of "branches" or "diffs" or "immutable history", then you're going to quickly and repeatedly run into stumbling blocks as your mental model doesn't match git's internal model. Git can do branches and diffs and immutable history, of course, but they're a leaky abstraction on top of the concepts git really cares about.
I used to own a Chevy Prizm and packed it with all sorts of stuff – including carrying a huge whiteboard on the roof – so I agree that strategy works.
But what's nice about having a truck now is that I don't really have to try. I can just plop most things in the bed and go. You're right that it's not 100% necessary, but it's a great tool when you need it. That's one of the reasons they're so popular where I'm from (Georgia).
I wish that were true in my experience. But we have struggled to support {macOS, Windows, Linux} x {x86_64, arm64} with JavaFX and one .jar for our application.
This is a 250-line diff, not a 4-line diff: https://github.com/ra4king/CircuitSim/pull/93/files. We have to manually manage .dlls and .sos by hand.
If you know a solution that is 4 lines, we would be very grateful. All we want is one .jar with JavaFX in it that supports many OSs and architectures.