Using JOSM on Linux requires XWayland.
This is already suboptimal, but might even cause functionality issues.
There are other Java projects that also all use XWayland, it seems that this native Java GUI library has no Wayland support?
Do you know what will happen with this? JOSM is also visually far behind iD, which I currently use exclusively.
As Iâve understood it, Project Wakefield is attempting to produce Wayland-native Java environment.
For reference, I use JOSM under Debian Stable (and thus, now, with Wayland). Iâm a happy camper, though. In my opinion JOSM visuals are a feature, not a bug. Itâs a far more capable editor than iD under the hood. Donât fix what ainât broke (regarding the visual side of things, not the Wayland stuff 
).
Iâll note that the IntelliJ IDEâs use that code in production now. I think it still needs a flag, but I wouldnât be surprised if Java 26 or 27 have that code merged and enabled by default.
As far as âvisually far behind iDâ goes, you may want to try the flatlaf plugin and change the JOSM Look and Feel (âLaFâ) in settings.
Am i right that that just changes/adds the swing backend bindings for Wayland so running with a newer JRE it âmagicallyâ works on Wayland native ?
Flo
Yes. I have already tested Wakefield (GitHub - openjdk/wakefield at jdk21.0.1-wayland) with JOSM and it actually only uses native Wayland, I can confirm that Xwayland is not used.
There are still bugs and missing features, but it looks promising.
Who cares. It doesnât need to look pretty, it just needs to do the job. Personally, Iâd rather the JOSM team spend their time adopting the basic software hygiene practices that the entire rest of the world are using. I wish that Java developers can meaningfully contribute without having to use ancient tooling.
Iâm doing free software development for more than 30 years now. Never in this long time did somebody really contribute anything after I fulfilled the wishes which âprevented contributingâ.
Somebody who canât use ant or maven to build josm wont be able to do any meanigful contribution anyway to a stable software like josm.
It does? still using X/plasma and everything works.
Frankly, this attitude is exactly the problem with the JOSM program. Iâve been coding Java for over 20 years myself (i.e. Java 5 was released during my professional career), and Iâve transitioned from CVS to SVN to git, ant/maven/gradle build systems, the rise of CI, many different enterprise frameworks, etc etc. The world has changed over these years and JOSM is stuck in a time warp by, and Iâm struggling to keep this within the etiquette guidelines, leaders that throw up every possible roadblock against anything new.
Yes, you are losing developers that would otherwise contribute. You have a silly versioning system, refuse to move off SVN and patches, your awful bug reporting system, archaic wiki, perpetually out of date layer index, and a general hostility to any new technology which the rest of the open source software development world now regards as normal and expected.
You do not see the people that arenât contributing. You donât see them because theyâre not there, and theyâve chosen to spend their valuable free time on other projects, where their skills are welcome.
Yes, it is stable. Fortran 77 is stable. And stability alone does not equate to progress. Stability without adaptability leads to irrelevance. JOSM may function well at a user level for those who have been using it for decades, but that does not mean it is a healthy, thriving open-source project.
A strong open-source ecosystem thrives on contributions, not gatekeeping. Modern developers expect streamlined workflows and maintainers who encourage innovation rather than dismiss it. The idea that âif you canât figure out our outdated and convoluted setup, you shouldnât contributeâ is both self-defeating and a surefire way to guarantee stagnation.
If the goal is to preserve JOSM as a functional but increasingly legacy tool maintained by an ever-dwindling group, then by all means, continue resisting change. But if the intent is to build a sustainable project that remains relevant and attracts new contributors, then the hostility toward modern software practices needs to stop.
Iâm surprised to hear you say that. In my experience, worthwhile first-time contributions are often made by people who arenât particularly experienced developers on that platform, but have an itch they want to scratch. Putting tooling barriers in their way prevents them ever making that first contribution.
Yes you tell them same as all the others. If only, then we wouldâŠ
Now, JOSM is nearly 2 decades old and still one of the two most important tools in OSM. I has 12 releases a year and constantly improves.
And it seems you have no idea what JOSM ecosystem is. There is git, there is CI. JOSM adopted many improvements over the time. But contrary to what you feel is necessary I only adopt stuff which actually brings JOSM improvements. I donât simply adopt stuff because itâs new.
Your assumptions about what attracts useful helpers are simply false. I got told that again and again from people who never themselves managed such an OpenSource project for a longer time. As said I do that for quite a while and JOSM is only one of many many projects Iâm involved in with different roles. What attracts helpful developers isnât whatever you assume. The main reason to contribute is to fix an itch which troubles the users. Now the more the software matures, the harder it is to find new people this way.
The type of people I could attract with the âuse the recent shitâ approach usually causes more harm than they do good. It takes months to fix the half-baked code contributed by that type of people and usually they are not willing to do it themself. They rather went somewhere else to do some other âhot shitâ. I rather have very slow development than this.
Ah now. Contrary to what you expect JOSM has no ever-dwindling group of developers. It NEVER had a large development group.
Well and they expect that I invest all that additional time to present them âstreamlined workflowsâ for the tiny bits of contribution they will do. Or what?
I donât want to attract such people at all. They are more trouble than help. I want to attract people who are able to solve problems themselves and improve the software. And that worked pretty good.
If your assumptions would be true the situation of the JOSM plugins would be totally different to the JOSM core. Plugins would be thriving, attracting developers and improve core functionality in every which way. True is the opposite. Plugins ALWAYS are neglected after a certain time when the initial developer looses interest. Core team has to take over. Plugins use whatever fancy technology is en-vogue. And: No difference, always the same result.
But Iâm pretty sure that your opinion is fixed and no amount of facts can change that. Success isnât enough to overcome the feeling that âI would contribute if onlyâ. Because it would feel bad to accept that it is âI donât want reallyâ instead of âI want, but canâtâ.
ant is an long-time established default build system for Java. Maven is the current established default build system for Java. I wouldnât call that tooling barriers.
And somebody who doesnât get that running:
wont be able to do anything worthwhile in the code because JOSM today is much to complex to do something right when you canât even start such a build. I donât know that many tools which offer two fully working build systems to choose from.
And if the build system really would be a bigger issue we would see tickets of the form âbuild didnât workâ. Donât see such type of tickets. Only tickets of the type âyesterday someone released a pretty new build system much better than everything else, you need to support this instead of your old crapâ (i.e. gradle). Some years later you need get rid of that now old crap again.
Taylor did a lot of work to get maven running for whole JOSM (including plugins) and that may replace the ant builds one day.
Yeah, no. JOSM has a git mirror of SVN which completely misses the point of what people are complaining about. If you want to contribute to JOSM you need to make a patch file and upload it to trac. Please donât pee on our leg and tell us itâs raining.
Also, Iâm glad you responded in long form. It perfectly lays out exactly the hostility that is the root of the problem on the project.
Now then please enlighten us. What is the root of the problem? That JOSM is a successful, actively developed, extremely reliable software and one of the two main editors and survived compared to a lot of the competitors?
Oh yes. Real big problem.
No, what is expected is that a software maintainer open the door to contributors that are willing to do the work. One of the hardest things for a maintainer to recognize is when itâs time to take a step back. Itâs a common trap to want to micromanage othersâ contributions.
I think anyone reading this thread can judge that for themselves.
I think a certain amount of resisting change is ok - during my own brief
time as a JOSM maintainer I resisted a lot of âthis should all be
re-done with shiny new framework X which will streamline developmentâ
calls. But I, too, have gone on record suggesting some changes (in
https://lists.openstreetmap.org/pipermail/josm-dev/2023-November/008459.html
and following) and thatâs still what I think.
You have simply NO idea of how JOSM development works. You didnât even try. Your comment here makes that clear. The more you write the clearer it becomes, that youâre exactly one of the category described above. And BTW if you want that I spent time to provide useless additional fancy stuff which anyway wont attract new developers. Thatâs easy: Send a request to my company and they will give you a quote. You then can order my time. Weâre also doing request work.
You ignore anything I say and you bring no arguments. You only blame and donât even say what the problem should be. A discussion with you makes no sense.
Sorry Frederik, but I consider that post of you as rather poor. I even thought that somebody used your mail and sent that, because I couldnât believe that you actually propose to switch a working development system which is not vendor-locked without any need and move it into the hands of a Microsoft operated company and do a vendor lock-in and in that process throw away anything which is not the core software itself. Because essentially thatâs also what ZeLonewolf requests: Move everything to GitHub because weâre all so used to GitHub. Ever heard of SourceForge?
Again here I need to ask: What would be the benefit? What problem would it solve to throw away many ten thousand hours of work? There is already enough stuff of JOSM depending on GitHub today.
Did any of you have a look at what Taylor did a lot of the time of the last year? He did deep analysis of small issues, delays and other quirks and resolved them by optimizing the code. Iâm extremely grateful for that work, but it will be nearly impossible to encourage anybody to do this work. He also did some big improvements, but most of them under the hood. You wont notice it, except it would not have been done, because that would be noticed. Little of the work on current JOSM is visible to users. There isnât much anybody can do which doesnât need weeks of work to implement. For current JOSM it sometimes is much more important to decide what NOT to do.
And yes, Iâm aware of the bus factor issue (I even had a severe accident some years ago): But this is OpenSource and life is life. All candidates to take over maintainership of JOSM left for personal reasons (and not because Iâm the big bad dictator). That is sad, but thatâs the way it is. Iâm pretty sure there will be new people coming and maybe one day one of these actively working people will say yes to my proposal to take over and I get rid of that burden. Or the OSMF could consider it important enough to pay somebody for it.
But in no way I would pass over JOSM to somebody like ZeLonewolf, because that would ensure a step decline in a matter of few years. I spent to much effort on JOSM that I donât want to see that happen. Do you really think it makes sense to encourage somebody to work on a software which needs hours of work to fix issues who thinks it is too much work to open a bug report in the official bug tracker and post a link to the GitHub change there?
Kind of a tangent, but Iâm sad to see that @vorpalblade-kaart was recently laid off his JOSM development job all of a sudden. I think he wouldâve liked to continue working on all these positive improvements.
Yes. Very sad. I hate to see Taylor go and I hope he will find a bit time in the future to spend for JOSM. But especially I wish him the very best whatever he will do.