Simple Auto-Updater/Patcher Library

Networking & Multiplayer
#21

In my opinion this just seems a lot simpler. Besides that, I don’t see a huge difference. I would prefer this however since I can accomplish updating in 2 lines or if I want the user to accept or deny an update, 3 lines. It isn’t as configurable, but it gets its job done.

Also, I will try to update the README with the new changes I have done soon because the README is out of date and it is rather disappointing for anyone wanting to use the library (though I assume I’ll be the only one who does in the long run).

EDIT: The README is updated. I will add a license file if I learn that it is important. I feel like the framework of the library is very good though :smiley:

#22

#23

Yes. Why don’t you use Java Web Start / Icedtea Web Start / NetX or Getdown? Your solution is simple but you’ll have to maintain it by yourself. I think a JAR used at runtime can make a copy of itself, update this copy and run a script that stops its execution, overwrite the JAR and restart the updated program.

#24

I didn’t do much research about other libraries for auto-updating. I just wanted to program it, I guess. I probably should’ve used a well-established library I guess. But since I ended up making this, I’ll use it.

#25

[quote=“Sammidysam,post:21,topic:41206”]
That’s cool ;D I was just curious. Actually I’ve thought about doing the same a couple of times.

#26

I found a pretty embarrassing bug 3 days ago that I’ve forgotten to mention here. I forgot to subtract one from the month variable to set it up so that January = 0 and so on when setting up Calendar so at the ends of months it could ignore updates submitted at the beginning of months. I believe I added one to the month results to maintain compatibility with the C# version of the library (so that the two could work together), but I’m not sure. Nonetheless, it is now fixed. If anybody out there uses this though, be sure to update your launcher! I also added a simple LICENSE file because I guess it should be done.

#27

Aye, but mine is a standard in absolute simplicity, everyone else wants to be a standard that covers all logging usage, evar. Why should I need to learn a DSL so I can edit a config file? That is, if I can find which of the 6 config files in 8 different JARs and 3 classpath locations I actually need to be editing. I’m looking at you, log4j! Then you have the crazy people who come along and tell me I need a layer on top of the horrible mess I already have which will abstract away the mess… it’s just logging!

#28

Log4j has exactly one jar, and one config file and it’s anywhere in the classpath you want it to be. slf4j means the rest of the world doesn’t have to use log4j, they can direct it to whatever they’re already using. And it’s one or at most two extra jars. My build system takes care of it. Would it be nice if there were a nice generic logging API using SPI the way JDBC does and not some pale imitation also-ran like j.u.l or this weird slf4j thing? Sure. It’d be nice of a lot of basic stuff came with the JDK.

Sure, I can see the use for a light drop-in logging system in an app that doesn’t need to get along with everyone else’s libraries, I’m not disparaging a tiny logger. But it’s really no excuse for outright refusing to learn something so gobsmackingly simple.

#29

Except you’re wrong, of course. :smiley: JBoss/Tomcat often has log4j config files in multiple places. I’ve seen people copy them around because they couldn’t figure out how to get their log config picked up. I’ve seen dependency JARs with a log4j config file inside, then it’s a crap shoot which file actually gets picked up. It’s still a DSL to learn just to log properly. Then you have JULI, whatever the hell that is. I’ve never used slf4j, but I’m traumatized. Also, the JDK does come with logging, it just sucks. :slight_smile: It’s not that I haven’t used these things when forced to, I just find them ridiculous and won’t let them near my pretty, pretty projects.

#30

It’s entirely possible that JBoss, Tomcat, and Log4J aren’t all the same thing.

java.util.logging is a steaming pile of garbage. The Tomcat folks decided it wasn’t horrible enough and actually made their own independent implementation of it called JULI in order to make it even worse. No one uses it unless they’re stuck with Tomcat’s brand of idiocy.

For all its features, log4j has its own serious problems in environments like app servers because of classloader leaks. So the author of log4j created slf4j which is a generic API that lets you switch out different logging backends and use the same API for each, similar to how you use the same JDBC API for different database backends. That was eight years ago. The landscape has not significantly changed since except for more people using slf4j. This is not a chaotic ever-changing landscape, unless you consider eight year old technology to be bleeding edge.

#31

Fair enough. :slight_smile: I still hope to never have to work for The Man again, in which case I can remain as ignorant as possible, even if slf4j doesn’t such. :smiley:

#32

I dunno, my experience with The Man is that they just demand all The Cogs (read: you and me) just conform to The Standard API that their apps use, which is usually some homegrown piece of junk worse than anything I’ve mentioned above. Case in point, I’ve got to deal with some 100K lines of perl code that uses its own logging API that just writes to syslog, nothing else, and to a hardwired syslog facility of local3 at that. No one would tolerate that kind of thing in a module on CPAN, they’d insist you used something like Log::Any or at least Log::Dispatch.

So yeah I suppose I had an axe to grind about logging in particular :persecutioncomplex: … Now excuse me, I have a crapton of someone else’s perl code to rewrite, emphasis on the crap. :stuck_out_tongue:

#33

Hehe, poor bastard. I’m loving not going to work! :stuck_out_tongue:

#34

To any who use this library, I have just fixed a bug. You can see the commit here. The library JAR has been updated as well, and the link is in the first post.

EDIT: Another bug fix commit here as I forgot to add my new method in all places necessary. The necessary files have been updated.