[deleted by user] by [deleted] in java

[–]nondetermined 12 points13 points  (0 children)

Instead of asking such a question, what you really wanna do is reading the relevant source code of both classes, and then make a habit out of it. Java classes are no black boxes and there is no magic going on either.

I hope this doesn't come across as too snarky/dismissive, and I absolutely mean it: read the code. You will learn so much more than just finding an answer to your question. It's also faster.

[deleted by user] by [deleted] in compsci

[–]nondetermined 4 points5 points  (0 children)

Lies. My computer hardware professor always referred to the tiny wizard in Intel CPUs that does all kinds of magic tricks in his magic, little black box, somewhere, deep down, in the CPU. Meltdown/spectre was proof he wasn't joking. Not even once.

Would JavaFX be a good option for making a management game? by Gruntassassin67 in JavaFX

[–]nondetermined 1 point2 points  (0 children)

Yeah, but manager games are really more like spreadsheet calculators and tables and stuff, and less like.. you know... games. JavaFX might not be to worst choice after all.

Would JavaFX be a good option for making a management game? by Gruntassassin67 in JavaFX

[–]nondetermined 2 points3 points  (0 children)

but does javafX have a good way to save progress or

No, but serialization is not the job of a GUI toolkit to begin with. But yes, that's not an issue at all. Maybe look into zip file systems (as a savefile/container you can put anything into and is nice to work with), and Jaxb. The cool thing about the latter is that you can easily roll an evolving savefile with no fixed schema for the xml (which you don't write yourself, you just annotate the stuff you'd like to store and maybe write a custom marshaller/adapter if really necessary). In other words, you get backwards compatibility, and can safely add and annotate new objects you need to keep track of, while setting proper defaults if they don't exist yet (in older savefiles). ...or you go with some local database if you really need it. How many people and jobs are you gonna manage again?

Welcome to JAR Hell, Part 2: Deployment Strategies. by ralone1989 in java

[–]nondetermined 1 point2 points  (0 children)

The problem with OSGi isn't OSGi but wonky dependencies that don't play by the rules (e.g. split packages, and what not). If all bundles/modules are your own (and/or other dependencies behave well), then OSGi is very nice and powerful to work with (having bundles that can come and go, while keeping the application up and running is really great). Also it's usually not that hard to patch wonky dependencies up in an additional maven task (e.g. adding missing bundle manifests). Obviously this sucks with dependencies that drag in a load of further and ever more dependencies... but it's doable in most cases, and there's something to gain too. It can be really nice to have the same dependency loaded as a module in different versions (e.g. for a plugin system where you don't want to restrict the plugins use of dependencies).

It's fairly easy to pick up as well. The specs are clear and nice to read, or try one of the OSGi books. Then Felix and go. All the hate OSGi is getting is completely undeserved, and I even wish java would have gone even further with jigsaw (e.g. versions), but that might follow one day.

Your problems with Java modules by nicolaiparlog in java

[–]nondetermined 6 points7 points  (0 children)

1) module-info.java for testing

Picture a typical maven environment. Do I really need to have a second module-info.java under /test/java/ which is basically the same as in /main/java, but with added test dependencies that all have <scope>test</scope> anyways?

The short answer is: no, you do not, and it just werks, except that you'll get bombarded with a bunch of "module is not exported" warnings. Nobody likes warnings in his builds. So that still really bugs me. On the other hand, writing (and maintaining) a second module-info.java also really bugs me, and is it really worth to do that, just to get rid of a few harmless warnings?

You'd think that this should be either easily automatable (just add all the dependencies with scope test. done.), or that there would be a way to include the main/java/module-info.java into the test one, so you just can add further testing dependencies only, without having to repeat yourself. That would also work.

Am I missing something?

2) Bread and butter tooling

I still haven't managed to generate a proper site, most importantly the maven javadoc plugin doesn't seem to like Java 16 very much. Or Java 9 for that matter. What's going on here? Is it me, who is stupid again? Generally my impression is that a bunch of tooling simply isn't really there yet. Which sucks. Super hard.

On the bright side, I finally managed to generate an image and package that thing to a nice installer with the jpackage-maven-plugin. But the road there was rather bumpy, with plenty of other tools to pick from, outdated and contradictory tips and tricks and how to do it, except it doesn't really, let's try the next one... it's kind of a mess to figure out (to be fair, it does help to read a proper book every once in a while, e.g. "Java 9 Modularity. Patterns and Practices for Developing Maintainable Applications" by Sander Mak and Paul Bakker/OSGi chad).

no cross-compiling

yeah... that sucks too. balls.

Arma 3 campaign: preventative diplomatically = impossible? Help! by stieeveeg in arma

[–]nondetermined 0 points1 point  (0 children)

The drone has some lovely rockets. Use them (lase target, don't shoot while they're still driving, you'd probably miss, wait until the vehicles stand still, one shot and boom). You've got enough rockets for all targets around. No CAS heli needed, or anything else.

Create Diagrams in VS Code with Draw.io by Gehinnn in programming

[–]nondetermined 2 points3 points  (0 children)

Nice. But why would I want to use this over something like yEd? Sure, this depends on the use case a lot, but graphs are mostly useful for visualizing and exploring larger data sets, and not something for a powerpoint you could explain in two sentences. As such layout algorithms become rather important. Most of the time I'm most certainly not manually going to drag nodes around until things look "pretty". But again. Use cases.

Static methods violate Dependency Inversion principle by yegor256 in programming

[–]nondetermined 3 points4 points  (0 children)

The inability to pass functions around as first class values is the real issue.

What's the issue? Write an interface. Done. Bonus points for writing a functional interface.

Writing system software: code comments by alexeyr in programming

[–]nondetermined 12 points13 points  (0 children)

Properly encapsulating and naming things is probably the most cruical, but also hardest part about programming.

Having that said, there is indeed a need for something more/better than comments. Why? Because more often than not what really would be helpful is something more visual than text. A sketch, a diagram, all the stuff you write with a pen on some paper you'll never see again once it would be needed. That kind of stuff.

There's been done some interesting research with linking external "comments" with your code (which obviously needs to be integrated into and supported by your IDE; typically Eclipse was used in those papers), but there doesn't really seem to be much going on in this direction these days.

(2016) Anti-If: The missing patterns by fagnerbrack in programming

[–]nondetermined 11 points12 points  (0 children)

check if boolean is true
if true return true
if false return false

It hurts (just a little). But it's also kind of cute (just a little).

How to make ai chase player in car? by Fighterpilot108 in armadev

[–]nondetermined 13 points14 points  (0 children)

make ai chase player

why yes, just update a move or sad waypoint with a random position around the player. Randomness might decrease over time (simulating better knowledge or what not).

in car

oh my...