After all these years of experience, do you think Java solves more problems than it creates?

[Lovewyrm]

In other words, is the hassle of dealing with Java as an end user (and developer (in my case someone who loathes Java) ) worth it?

Would the toolkit ever be ported to a compiled, native language? Or, would you be okay with someone else (cought, I, myself, for example ) making a port? (Of course y'all doing it would be easier since that deals with copyright info and whatnot better.)

If you could do it via magic, as in, no work required. Would you magic the entire project to, let's say, C++ & Qt? (or GTK or whatever)

I'm not saying that C++ and platform dependent code etc is not cancer free (and Qt is kind of a titanic slime, too). But I really, really, really, really, really, really, really and absolutely despise Java applications. They're ugly, bloated, and just blehhhh.

So, yeah. I'm curious. P.S.: It would make reuse of already existing libraries easier, too. Vector drawing, raster drawing, etc, it's all there.

Thanks to this kind of modularity, we have MyPaint brushes available for Opentoonz, for example. (And that just really is one example) There are parsing libraries, GUI toolkits, math libraries, etc. pp. Java has them too, but Java, again, is just so damn awful.

[Azhrei]

Heh, another my-language-vs-your-language rant... If you want to convince people that a language change is worthwhile for this project, start by making your case against the status quo, then identifying why another language is a better choice. Be specific in both aspects, and don’t forget to cite references.

I look forward to the discussion, although perhaps a forum post is a better place to do this? (Not Discord, since the dreaded “tl;dr” is common there.) When you’ve started the thread, come back here and post the link so others can follow up there...

[JamzTheMan]

The project is open source. There is NOTHING stopping you from porting it to another language. (Unless you plan to charge $$ for it then you may want to review the licence).

Personally, over the last decade or so, this conversation comes up over and over and I have yet seen anyone actually tackle it. Usually because most people think "Gah, this UI is horrible, let me rewrite it in Xyz" or "Gah, I want to use groovy for scripting, let me rewrite it" or 'insert some other reason'...

BUT, MapTool is NOT just a ugly UI program that does a few things. You have all the UI to handle, the Rendering of vision/fow, display boundless maps, handle drawings and user drawable vbl, then you have a networking layer, and a pretty deep macro language with over 100+ custom functions, then wrap all that up with permissions for tokens and clients. It's a pretty big project to tackle and at that point, I honestly wouldn't know why you would not just start writing a NEW VTT from scratch in 'insert preferred language here' so you do NOT bring in all the inherent flaw that any software has after 10-20 some years of development by a dozen different people.

I can only speak for myself. I personally work in Java almost daily for work. This is a hobby project. I dedicate anywhere from 10 minutes to maybe 4 hours a week on it (usually the lower end) so being Java, I can easily dive into the project to make some quick changes if needed. I would probably never have the time to learn a new language just to port a tool (that largely works for me) just for the sake of it being written in another language.

IF another project opened up that was open source and so dang cool and did what I need it to do to run my Pathfinder weekly game, I would look into joining said project.

I would suggest (if your goal is to persuade people to join you) would be to fork MapTool and present a working Proof of Concept with some points on what is better about said project and why. So far I only see opinions and not analysis.

[Phergus]

Hmmm. A VTT that has been out for 14 years and is used by thousands of people across multiple platforms. Guess Java must have something going for it.

[Lovewyrm]

@Phergus I see where you're coming from, but that argument is a bit on the weak side. There's plenty of truly awful stuff people put up with (and again, quite a few would find my language and toolkit of choice awful) just because it works and rewriting something might not exactly be fun.

@JamzTheMan I have already started the porting process, and I agree, it's very daunting and covers a lot of things, but it is also an opportunity for some refactoring/cleanup. I do not intend to charge anything for it, I fully stand behind free software. (Also, since it is such an extensive project don't expect machinegun like output, I'm not gonna hurry, just a few hours every day or so, but I really would love a natively compiled version)

Anyway, I know my opening post looks a bit hostile, but it really is just for the end user, not for the programmers who did all this excellent work. It certainly is easier to just work on the existing codebase in the language that it uses. But I was curious about if the team perhaps kept a tab (even just 'absentmindedly') on what might have initially driven the choices for putting it as a java application versus the time passed and how many people might have complained about it.

It was mainly "compiled binary package" versus "weird java jar package" kind of curiosity. Especially if a JRE is (now) packaged alongside the toolset.

Anyway, thanks for the replies. Again, I really don't like java, at all, and I stand by my opinion of how unappealing java applications are 'intrinsically' to me , but I don't hate what you all have done with it. Just to be clear. I am also partly biased against it because I use an esotheric (more or less) window manager/desktop environment and java is not always playing nice with, etc, pp.

But yeah, I've started the process and will slowly port things over. If I didn't like your software, I wouldn't care this much, but I do. The more I like it the more it pains me to see it in java.

[JamzTheMan]

The main driving point for Java at the time was multi-os support. At the time, Java was about the only language that you could easily develop in and compile against Windows/Mac OS/Linux. It's still a primary goal today to support all 3 OS flavors. Windows is the largest user base but we have a very very solid Linux user base as well. Two core developers are Mac users as well and only develop within that space.

Native executable is a really nice plus and would like to have them (we only provide native installers) although AOT for Java is in the pipeline (currently beta for linux only)

Granted, that also comes with the issue of signing said executable so it can be trusted by the end user. Currently we don't have that capability because of $$$ but users can still download a JAR version instead (or run from source) if they do not trust the native installs.

[Phergus]

It was started in Java, as that is what the originally developer programmed in at his work and it was cross-platform. There was no long term cost/benefit analysis done as originally it was just for his gamer friends. Trevor himself wasn't really a gamer. Then MapTool was shared with others via the RPTools site and took off from there.

[Azhrei]

@Phergus I see where you're coming from, but that argument is a bit on the weak side.

I think his point is, why reinvent the wheel? On the one hand, I agree — if it works, don't fix it.

On the other hand, I would love to be able to take advantage of some things that a platform-specific application could do (re: libraries and such), but it's such a small penalty as to not be an overriding concern. (Obviously, since what we have now works.)

One of your arguments appeared to be performance. That's a bit on the weak side, too 😉 because the JIT compiler in Java converts Java byte code to native instructions after code has been executed a requisite numbers of times. (In other words, code that runs a lot is native and thus runs faster.) In fact, this has become SOP on Android now. When you install an app on the latest Android releases, the Kotlin byte code is converted to platform-specific code at install time so that the very first use is truly compiled code.

What's interesting about JIT compilers is that they can do some types of optimizations at least as good as a native compiler, and because they're based on platform-neutral byte code, they can be tweaked and optimized without requiring source code to be recompiled or applications to even be redeployed! That's a huge win in many cases...

Java applications are likely to be more secure in general, as it's not possible to play with memory addresses directly, nor is it possible to have a buffer overflow error. Java is just as strict with its type system as C++, so there's no loss of type safety. (There was prior to Generics, but they were added in Java 6 so that's too old an argument to be relevant.)

I do miss some features of C++ when I write Java code, though.

@JamzTheMan Anyway, I know my opening post looks a bit hostile, but it really is just for the end user, not for the programmers who did all this excellent work. It certainly is easier to just work on the existing codebase in the language that it uses.

I didn't consider it hostile, per se. But more of the been-there-done-that-have-the-tshirt type of thing. As Jamz says, it's come up before.

It was mainly "compiled binary package" versus "weird java jar package" kind of curiosity. Especially if a JRE is (now) packaged alongside the toolset.

You haven't said which language you planned to use. I'd be curious to hear you map out your plan. The more detail you can provide, the more help we can provide in getting you there.

C++ & Qt5 might be a viable approach nowadays. There are significantly fewer C++ programmers than Java, however, so your pool of contributors will be much smaller. (This is one reason why the Linux kernel is written in C instead of C++, and it won't be changing.)

Now that C++14 has thread support (in terms of the Boost library being part of the language) and they've fixed some of the constructor issues (like the move constructor), it might be worth a shot. Qt5's "signals and slots" idea is very cool (I did some Qt3 development way back in the day, just before and after Qt4 came out, before I lost interest).

It's much more difficult to turn a regular programmer into a great programmer when the language is C++ than it is when the language is Java. (C++ programmer needs to be great to begin with, because anything else just isn't functional. What I mean is, a mediocre C++ programmer is a hindrance more than a help.) C++ just has too many edges cases that are just plain weird... Ever try to throw an exception in a constructor? Or try calling a virtual method in a base class constructor? And what about compilers that don't properly implement standard template features, such as partial specialization (like VisualC++ — ugh!).

I am also partly biased against it because I use an esotheric (more or less) window manager/desktop environment and java is not always playing nice with, etc, pp.

Ah, the real reason comes out... 🙂 Why not fix the GUI instead? It's possible that (a) the GUI isn't doing things in a standard way so the JVM doesn't work with it, or (b) the JVM isn't adhering to the GUI standard, or (c) some combination of the two. Fixing that would give you immediate access to all things Java, and that's a pretty long list.

[Lovewyrm]

One of your arguments appeared to be performance. That's a bit on the weak side, too wink because the JIT compiler in Java converts Java byte code to native instructions after code has been executed a requisite numbers of times. (In other words, code that runs a lot is native and thus runs faster.) In fact, this has become SOP on Android now. When you install an app on the latest Android releases, the Kotlin byte code is converted to platform-specific code at install time so that the very first use is truly compiled code.

No, it's not a weak argument at all. Yes the VM itself is natively compiled (that's why Java cannot escape platform independence 'at the core' just like Python and other interpreted languages) and so forth, and in a vacuum there is some weight to it, but Java applications aren't exactly seen as trailblazers. And it's not just a mirage or something, it's incredibly easy to make Java applications run like molasses, especially on phones. Simple modern platformers of today often run with performance worse than old 8 bit machines despite having a lot more horsepower.

There are significantly fewer C++ programmers than Java, however, so your pool of contributors will be much smaller. (This is one reason why the Linux kernel is written in C instead of C++, and it won't be changing.)

I don't follow why the Linux kernel being in C and not C++ is an argument for "better programmers in Java" , after all, the Kernel team isn't changing C to Java, either.

It's much more difficult to turn a regular programmer into a great programmer when the language is C++ than it is when the language is Java. (C++ programmer needs to be great to begin with, because anything else just isn't functional. What I mean is, a mediocre C++ programmer is a hindrance more than a help.)

Java is Turing complete and can therefore be told to perform dumb things, too. Otherwise, a bad programmer is a bad programmer, no matter the language. Granted, Java makes it harder to mess up dynamic memory, but, again, you can have "bogosort" in Java, too.

On the flipside, knowing how to deal with computer memory is pretty useful, but not even C++ needs that much of it, especially nowadays.

C++ edge cases and weirdness

Yeah, they exist, but Javas poop doesn't exactly smell like roses, either. And on top of that, you have to also deal with the virtual machine that you either have to tell the user to install, or redundantly ship with.

Which is the actually real real reason I asked about this. Not my issues with th GUI.

Anyway, progress is going pretty well, but also slow so far, it's the reason I haven't replied until now. It's not the only project I work on, so yeah, I am slicing my time thin.

Oh, speaking of sliced thin, though. I'm a fulltime Linux user, and most software used is written in compiled languages, not Java. Also, Java is the property of Oracle, they have licensing rights, etc. That alone makes it unattractive to truly free software.

[JamzTheMan]

Java is not the property of Oracle. They championed it yes but even that has changed. OpenJDK is Open source and you can get binaries packaged by other sources other than Oracle.

If you use the Oracle distro, yes, there are license issues but we are moving to OpenJDK once a JEP we are waiting on is added to 13 or 14.

[Jaggeroth]

What other language is more Open Source friendly? Honest question.

[Lovewyrm]

What other language is more Open Source friendly? Honest question.

OpenJDK completely slipped my mind even though I know about it, so that angle is not really relevant anymore as an argument for me :P

[Azhrei]

You took my quote out of context:

C++ & Qt5 might be a viable approach nowadays. There are significantly fewer C++ programmers than Java, however, so your pool of contributors will be much smaller. (This is one reason why the Linux kernel is written in C instead of C++, and it won't be changing.)

I don't follow why the Linux kernel being in C and not C++ is an argument for "better programmers in Java" , after all, the Kernel team isn't changing C to Java, either.

As you can see, I said that C++ may be a viable approach, but that you'll find fewer C++ programmers than Java programmers, so an open source project might progress much slower. And I referred to the decision that the Linux kernel developers made for staying in C as an example (Linus has said the base of contributors for Linux should stay as large as possible). I never said anything about the Linux kernel choosing to use C as being an argument for "better programmers in Java"?? I don't know where you got that from.

In any case, your argument is still amorphous (to me) as you haven't stated exactly what your concerns are.

I'm a big proponent of using the right tool for the job, and I hate when I see my corporate clients choose a language first and then do their design. That's 100% backwards. The analysis comes first (which may include things like cross-platform support), then comes design (in which a design is created that solves the problem at hand, but which doesn't recognize language requirements), and last, the programming begins which means selecting the best language for the design.

Many times, a client will choose a language out of expediency ("that's what our people know" or "we have a lot of library code already written in that language") and while those are valid business reasons (because they affect the bottom line of the company), they are not valid reasons when there is no "company" involved, as in an open source project.

Free of those concerns, an open source project can focus on The Right Way to accomplish a given task. The concrete benefits of Java outweigh any perceived negatives (there certainly are some!), and when compared to other languages, the Java scores higher for this application.

I admit that C++ has made some headway in the last few years (I mentioned the thread support that comes with the Boost libraries in C++14, for example), but there's a lot of logic behind choosing a language that is widespread so as to attract more contributors.

I haven't seen the specific list of issues that you think Java has, listed bullet point by bullet point, just vague references to your perceptions of Java (your misunderstanding of what "JIT" means in your last post is an example) and egregious statements like, "it's incredibly easy to make Java run like molasses" when we all know that the same is true in any language (expecting the compiler to solve performance problems when the programmer chose a bad algorithm is naive and misguided).

I'm holding off on further comments until you can articulate your specific issues with Java. As someone who has written a fair amount of both Java and C++, I'm sure I can show you that C++ is no savior! But I wish you luck on your C++ implementation, and I look forward to using it in my online games! Cheers! :)

[JamzTheMan]

@azhrei, I agree with most of that, however being an open source project does not make it immune to the same concerns.

If you have 20 developers who now language X and want to contribute but language Y is choosen because it is a better choice to deliver desired goals, you could end up with 0 developers contributing which one could argue is a worse choice. Sometimes (not always) delivering a slow car is better than delivering no car at all (or delivering a car 5 years late, meanwhile everyone moved to using Uber and you have lost your customers)

Sometimes you have to balance things to remain agile. What might be the best language for architectural reasons does not mean it's the best choice for the users.

And this goes with general design concepts as well. The most elegant design doesn't really matter if it never gets built.

[Azhrei]

And that's a perfectly valid opinion. :)

I write code because I get joy from writing code. Whether someone else finds joy in using my code is not really my concern (although it's a nice dopamine fix!). This means my concern is more for the purity of the programming process than for the end result. I guess that makes me an academic. ;)

[JamzTheMan]

I can agree with that as well. :)

[Lovewyrm]

You took my quote out of context:

C++ & Qt5 might be a viable approach nowadays. There are significantly fewer C++ programmers than Java, however, so your pool of contributors will be much smaller. (This is one reason why the Linux kernel is written in C instead of C++, and it won't be changing.)

I don't follow why the Linux kernel being in C and not C++ is an argument for "better programmers in Java" , after all, the Kernel team isn't changing C to Java, either.

As you can see, I said that C++ may be a viable approach, but that you'll find fewer C++ programmers than Java programmers, so an open source project might progress much slower. And I referred to the decision that the Linux kernel developers made for staying in C as an example (Linus has said the base of contributors for Linux should stay as large as possible). I never said anything about the Linux kernel choosing to use C as being an argument for "better programmers in Java"?? I don't know where you got that from.

My bad, better = more. In any case, the point is that the Linux kernel argument is not one for Java over C++.

It's misguided to rely on JIT and compilers to fix bad coding and have that as an argument against Java

That was my response to your words:

It's much more difficult to turn a regular programmer into a great programmer when the language is C++ than it is when the language is Java. (C++ programmer needs to be great to begin with, because anything else just isn't functional. What I mean is, a mediocre C++ programmer is a hindrance more than a help.)

Which is silly. Having to rustle up a response to such things, bullet by bullet is about as much fun as pulling teeth. There's a saying in the art world. If someone tells you your work looks wrong, they're probably right, but if they want to tell you how to fix it, they're most likely going to be wrong.

So, while you can dismiss me all day because I'm not giving the right arguments to make you start dropping your language of love (just like people love PHP, Lisp, MyLittlePony Script or Malbolge). I wouldn't even have brought this up if Java applications werent' such a shitheap to use. Even if the program is a good program. The Java experience is still cancer.

Yeah but people use our program

Yeah, because it's good, not because it's Java. My general practitioner uses some old ass DOS program because that's the gold standard program and it's the suite he has to use because there is nothing else.

Windows user, especially non OpenJDK users, they know the fabled "Java installer 'bonus content' checkmark they get. (Linux is usually just an invocation of the package manager)

Why don't you run a survey on the Forums or something to see if your perspective is the real vision of the users or if it's your own Java loving one.

I mean, ask a Haskell afficionado about the IO monad, which is a pain in the ass for regular mortals, but they'll love it.

Hate this kind of energy vampire bullying. Give me a bullet point list.

Yeah, right. What are you gonna give me in response I wonder. "google is using Java for their huge backends" or something so it's gotta be good. Great. Yeah, I'd love to hear about that At least I'm honest about aspects Like Qt which is kind of a monstrum as well.

this sounds a bit hostile though Yeah, cause I do loathe this specific flavor of argumentation.

Went to the LMMS (a digital audio workstation) Forums some time ago to point out how awful the audio leveling is out of the box and how playing a simple three note chord peaks/blows out ALL the synthesizers and what did crop up immediately? Some guy from Stockholm (yeah, I know, I was amused as well, Stockholm syndrome and all that) being a complete apologists about it.

Like, Nibba what? There is no rationalization possible that will ever make playing a single three note chord being completely ear splitting/sound distorting loud ever be a good thing.

But argue for that he did. Hate that shit. But yeah, there's a possiblity that I'm a snowflake, that I'm the minority with my disdain for having to use Java application. Unwashed pleb and all that.

I don't think that's the case, though. But yeah, thanks for the well wishes for my port. Certainly more motivated to keep on working on it now. Rrrrrrargh.

P.S.: Oh, right right. I remembered something from my own experience, it was so shitty that my mind purged it.

There's a pretty good java program for the GURPS roleplaying system a character creator, gcs is the name. And at one point they switched to Java 10 or something, I forgot the details might be Java 11 or Java whatever, but it removed some tool that made building the project easier, "javapacker" I think was the tool they removed. Anyway, the details aren't that important, what was important to me back then was I had different Java software rely on different Java versions because it was some Java transitional period and it was AWFUL. If it had been a natively compiled language then it would have been significantly easier to fix that, but , again, maybe that's just me. I'm not a Java buff, obviously. So yeah.

It was cancerous, though.

[Lovewyrm]

Hey, wait a minute. I just checked your commit history, Azhrei, and it seems...you ain't doing jack except handling merges and build things, lol. Why did I even talk to you? To think I could have dismissed your disgustingly smarmy ass immediately. Well, shame on me, I guess. Live and learn.

[JamzTheMan]

Well. That got toxic quick...

To the community at large, please try to act professionally at all times. There is enough wrong with the world these days and we all like to escape that reality to play games. There is no room for personal attacks.

Please refer to the community guidelines if you do not know what is appropriate.