Tim Holloway

Probable the easiest way to do that is to use Maven to build your executable JAR. Maven can automatically include those jars as dependencies.

For the names and versions that Maven supports, see here: https://search.maven.org/search?q=com.amazonaws

Famous M. Ighodaro wrote:

Campbell Ritchie wrote:Welcome to the Ranch

Maybe our web services forum will be a better place for your question.

Oh, I didn't see that initially, I will ask same question there now since I can delete this one.

No, don't do that. We can move topics. Deleting things isn't really how we work here. Too much stuff vanishes from the Internet as it is.

There's actually two kinds of patching, and the type referred to here is the older and uglier one.

Back in the Cretaceous Period I worked on IBM mainframes as an OS-level programmer. We did some original work, but a lot of what we did was install and configure vendor packages - both IBM's own OS and other products and some third-party products. Those mainframes had less overall power than an Apple Watch, so building a major system could indeed take several hours. But since bugs were no less common back then and you can't just "turn a mainframe off and on again" every time something goes sour, we needed a way to update the products we had installed. Rather than have IBM rebuild the entire OS every time something needed tweaking, we'd use a program called "ZAP" to alter the loadable code (equivalent to a class). Often the patch that we'd ZAP in would be a jump to a spare area of memory, do what it needed, and then go back to where it came from. Frequent offenders even had a pre-reserved area of memory to patch into.

It's not that bad when everyone's doing assembly language and the instruction set is tidy enough that you can assemble/disassemble code in your head. It gets much uglier when working with high-level languages, and uglier still when optimizing compilers are used and the generated code no longer linearly follows the source code.


The other kind of patching is still done, primarily on Unix-like systems. The Unix "patch" program takes the "diff" output of two text files and applies them as a series of text edits (using "sed" or the like). This isn't so much a bug-fix strategy as it is something that distro package builders do to tweak source code to make it more inline with the quirks of that particular distro, allowing a common source code for all distros. It has also been used to ship trial changes from one developer to another.


But, as I said, the patching in question is of the first kind, not the second, and I cannot recommend it either. The Java world is just not set up for that.

Exceptions in C are much nastier than they are in Java. The only thing nastier was its predecessor: setjmp/longjmp. You can also throw anything in C++, including ints. There's no formal base class for exceptions there.

Nevertheless, in Java, just as in C. there's a fair amount of overhear in throwing and catching Exceptions, so no, it's not recommended to use them casually.

Microservices or otherwise, my position has always been that the creation and maintenance of user security data should never be in the same application as the business services.

As a general rule, putting both functions in the same app requires elevating the data access rights for the user data and thus opens more options for exploitation. Separating them allows a more restricted security environment on the business services. And, in fact, you might even be able to limit the account management all to in-house access only even when the business services are public Internet services.

The dialect classes are part of the JPA implementation. Either you didn't pull in all the libraries, or you didn't capitalize the class name correctly.

Is it supposed to be "MySqlDialect" or "MySQLDialect"?

You've got me. I've never seen an error like this before.

My best guess is that the code reweaver wants to get access to some stuff and the target won't permit it. Either because you've got a property or method whose scope is protected when it needs to be public or because of constraints in the new Java Module system.

Shades of the dinosaurs! You're actually proposing to patch a Java class?!!!

Jesse, gotos are an inherent part of bytecodes. Bytecodes are the assembly-language of Java and are too low-level to support structured programming constructs.

Brennan, if you are using an intelligent build environment like Maven, only the initial build should take "hours". The system is smart enough that unless you do a "clean" operation between builds, only the changed parts should actually get recompiled.

Hours seems a bit exaggerated, though for Java. I've built some pretty big projects and probably had them take no more than 20 minutes, absolute tops. For hours, I'd have to build in something like C, where, for example the FreeCAD project probably takes at least half an hour and I don't want to think about doing that on a slow machine like a Raspberry Pi! I'm pretty sure I can build a Linux kernal in less time!

UML does have a logic flow component. It's somewhat different than flowcharts, though.

Most UML I've seen has been actor diagrams (I knew a major company who wasted way too much time on those) and class diagrams.

The most useful part of UML for me has been Swim Lane diagrams, since it can be used to chart interactions between clients and servers.

Jesse Silverman wrote:
So yeah, porting can be tricky, but what intermediate would you elsewise use?  Pseudo-code?  UML?

I would use anything that works. Generally on the back of an envelope. I might even use CRC cards, which is a lot like UML class diagrams.

Bitwise operations occur in a surprising number of places. For example, the low-level implementation of multiplication consists of add-and-shift sequences.

They are also extremely important in both encryption and error checking-and-correcting systems where they facilitate the processing of binary polynomials.

Here's the polynomial expression used for CRC-32 computation (32-bit Cyclic Redundancy check)

x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1

Functionally, you can consider the input to this function (x) to be a very large binary number (say 1024 bits). Each exponent listed in this formula corresponds to the number of bits to shift the original number. This may look intimidating, but disk drives and network cards can do this sort of stuff on a streaming basis, so it can be done very fast.

Spring uses annotations on POJOs, so those aren't separate considerations. As a general rule, use annotations instead of XML files - it's fewer files to co-ordinate. XML "annotations" these days are generally reserved for resources where there's no Java class that can be annotated or when you have a generic annotated POJO and you need to override the default annotation values.

(Betcha that left you with more questions.)  

Not sure what you mean by "the whole Spring system". I've used Spring on Tomcat to provide support for JavaServer Faces. I've used it with JPA, Neo4J, Spring Scheduler/Quartz, mail services, and more.

There are a lot modules in Spring. I doubt you'd ever use all of them in a single app.

As far as AWS goes, there were 3 options last I counted:

1. Run Tomcat stand-alone in a VM

2. Run an Amazon elastic Tomcat(s)

3. Run Tomcat in an Amazon container(s)

Options 1 and 3 also allow for Spring Boot.

Well, again, I'm unclear. Yes, an HTML displayed webpage is often built from many resources. But the URLs of those embedded resources generally will not reference the backing beans - they'll either be resolved via direct WAR resource paths or via JSFs own internal resource resolution/skinning system (from JSF2 and up).

When a View is first rendered, non-existent backing beans will be instantiated, but those beans will not be instantiated again for a given render-response process - the original instance will be used in all cases.

Rendered Views are HTML and there's no magic in them. Postback refers to the fact that when you post a form, the same URL is used every time you take an action on that page. For example, if you enter data and it re-renders the view with validation failure messages and such and makes you re-post the page until you get it right. Or give up and go elsewhere.

Postback probably also applies to AJAX, but here again, there's no magic. If you have some sort of automated display update mechanism, then yes, the page will submit requests, but a JSF page is otherwise no more going to send unrequested requests to the server than any other HTML page would.