Paul Clapham

I've made a Swedish-English translation of that SQL (using Google Translate), for those readers who may want to guess what you wanted but don't know Swedish:

create or replace trigger aifer_insättning after update or insert of amount on deposit for each row begin update account set balance = balance + (select amount from deposit); end;

Remember though that the SQL doesn't actually tell us what you intended it to do, only what it actually does. So it would help if you told us directly what you intended it to do.

Great!

I looked at the API documentation for the Stream.reduce() method; it mentioned that the operation must be associative. And the word "associative" was a link to an explanation of why that is necessary and what the ramifications are. Did you read that? If not, do you still have questions after reading it?

Likewise with "stateless"; the word in the documentation is also a link to a section which explains further.

Steve Dyke wrote:But if I then use logOn.getObject().userid for example in other places in my code it will create another User object.

Is that a problem? If so, why?

Do I set the public User getUserObject() to final?

If you want subclasses of LogOn to be unable to extend the getUserObject() method, then yes. But that question comes out of nowhere and I don't understand what problem you intend to fix with it.

I have to guess at what your Product Swing table contains, so I'm going to assume it only has information about Products, and quite likely only information about one Product. So I'd think you would just query the Product table to get that.

But I'm still confused. In your response you mention "the Product table" and how you want it to change. That's a Swing table I suppose. Then later you said you were assuming you'd have to make a separate table for your products. You said you have a Product table (or at least you implied it) and the query you posted seems to be using a Product SQL table. So I'm confused about what that separate table might be.

As for how to change the contents of an existing Swing table: you build a table model, similar to the code you already posted. Then you call setModel() on the JTable, passing that table model. So when the user clicks on something in the Invoice Swing table, your code is going to query the Product SQL table for the relevant products and build the new table model for the Product Swing table.

Your questions seem to suggest that you think you're just going to execute one query for the whole program, or something like that, but it's not clear to me whether that's the case.

Start at the beginning by downloading a project from one of those tutorials you saw on line. Install it into your IDE unchanged and see what happens.

Hi Cavan, welcome to the Ranch!

I'm rather baffled by all of that. Let's start at the beginning.

You have an inner join between your tables -- those are SQL tables. It's badly formed SQL but my question is, why do you need that?

Then you want to split "them" into two tables. The only "them" I can see in the sentence is your SQL tables. Are the two tables you want to get SQL tables, or are they Swing tables? My guess is that they are Swing tables because later you mention clicking on one of them.

So I'd propose starting again by sketching out the GUI. It seems to me that you want a Swing table with Invoices in it. This might be all of the invoices you have, or it might be all invoices for some customer, or something else, but anyway start by deciding what you want to see in that Swing table. To fill the table you'd use code similar to what you just posted... Actually I just noticed that your "Invoice" SQL table includes invoice details (Product and Quantity Ordered), which startled me a bit. I would have expected an "Invoice" table to include invoice number, customer ID, and date, and that there would be an invoice details table. You have unnormalized data there, it looks like. But whatever, you need to decide what you see in your first screen. I assume you want to see just the header information, so your query would need a Group By.

That's probably enough to get started with. Post back when you have more questions.

That concerned me too, but clearly TreeSet still isn't the way to go. So I checked the documentation for TreeMap and it says:

The docs wrote:The map is sorted according to the natural ordering of its keys, or by a Comparator provided at map creation time

As you say, using the natural ordering of the keys isn't what you want. You want the natural ordering of the elements themselves, which to me says you have to provide a Comparator when building the TreeMap.

D or E? So your decision is the same as "Map or Set?" And since the requirement is "each element has a unique text id that you want to use to store and retrieve the record" that means you want a Map (where key -> value) and not a Set (where you only have values). So D is correct.

(Your posted example, very competent I have to say, does use a TreeMap.)

If it makes you feel any better: getting your Java application to run on somebody else's computer has always been a huge pain. It's easy enough to write the Java app to run on your computer. But to run it on somebody else's computer, you have to ensure that they have a JRE installed there. And you have to ensure it's the right level; maybe you used Java 11 and they only have Java 8. And once you've got your application and the right version of Java, you have to make sure that the "somebody else" can find your application.

Yes, Java is Write Once Run Anywhere. But it's certainly not Write Once Install Anywhere. For Windows, for example, you either need to produce a Windows installer or else you need to write a page of instructions on how to get the Java environment configured correctly and how to create a suitable shortcut on the desktop, hoping the recipient can understand the instructions and execute them correctly. And no doubt other target operating systems have similar issues, although I'm only familiar with the Windows variety.

Oracle's solution to that was JNLP: you'd put your application on your web site and set up a configuration file (also on the web site) which allowed the consumer to download the application and, if necessary, install a suitable JRE at the same time. I used this a lot at work and it worked very well, at least with Windows. But that all died when applets were (rightfully) thrown overboard and now you're back to square one.

Bear in mind that I haven't had to wade into that swamp for several years now, so what I just wrote should be read in the past tense. In particular Maven is something I haven't worked with. So hopefully you can get it to produce a full package of JRE plus application which can be simply copied to another computer -- check it out.

Nyeng Gyang wrote:I have thought of employing yet another approach to demonstrate that your take on my suggested correction is wrong. However, until I am able to confirm that this your misunderstanding of the suggested correction is due to genuine, sincere misunderstanding, rather than deliberate crafty obfuscation, I fear that I will only waste my time making any such attempt at supporting and clarifying my claim that you have decidedly gotten my suggested correction wrong.

This would be a welcome change. So far you have only been vigorously avoiding saying anything which would support your claim. Instead you have limited yourself to attacking people who would like to clarify it.

And indeed it's likely that my take on your claim is wrong. That's why I have repeatedly asked you to clarify. I have provided several examples; you have done nothing except to reply that your claim should be obvious. The examples were intended to explore the limits of your claim. In other words all of the examples I have provided, in your view, result in a compiler and your assertion is that the JLS says that is the correct behaviour. Your single example, however, is very similar to mine so it's your responsibility to explain what the differences are and how that's related to the JLS.

The other thing to take into account is that if your goal is to demonstrate that the JLS is incomplete and needs repairing, then demonstrating that I'm wrong is not what you want to do. That means nothing. Your goal should be to demonstrate that you are right. So far I have seen nothing like that. So, I look forward to seeing your clarifications.

You surely don't propose to modify the JLS by extra verbiage which only applies when a try block is followed by a single catch block?

I mean, I've already asserted that's exactly what you propose, but instead of bluster you really ought to either agree with that or improve your proposal.

Nyeng Gyang wrote:this claim of mine is as follows: “It is a compile-time error to throw an exception of class E in a try block and place an exception of a subclass of class E in the corresponding catch block”).

Notice the word "the" near the end of your claim. That means that your rule only considers cases where there's exactly one catch block. That's what "the" means. And so it should, because if there's more than one catch block attached to a try block then the rule isn't true. Or at least, a revised rule which referred to "one of the corresponding catch blocks" wouldn't be true. Like so:

public void method likeSo {  try {    throw new Exception();  } catch (IOException e) {  } catch (Exception e) {  } }

No compile time error here.

I suspect that overlooking this case may have contributed to your idea that the Java compiler isn't a faithful implementation of the JLS.

Nyeng Gyang wrote:(2) The correction I have suggested needs to be made to the JLS rule.

No corrections need to be made to the JLS. Remember that the "S" in "JLS" stands for "Specification". A specification defines how something (in this case the Java language) must work and therefore "correcting a specification" is a meaningless idea. If there are differences between what the JLS says and what your Java compiler does, then it's the compiler which is in error.

Your rule is rather pointless, since it includes the assumption that the try statement is accompanied by exactly one catch statement. I mean, yeah, in that particular situation it repeats what the JLS already says, and so it's a correct rule, but that's about all. It's really not worth arguing about, in my opinion.