Simon Roberts

I believe the intention here is

A dict (dictionary, map, associative-array, take your pic, but it's called dict in Python) documents opportunities to buy materials, giving a key that is the price the purchase can be made at, and the number of items available at that price.
Another dict documents opportunities to sell items, giving a key that is the price the buyer will pay, and the number of items they'll take.

So, the goal is to maximize profit. I have no clue if there's a standard algorithm for this, but to me, this consists of (in psuedo-code)

"loop":  find the lowest priced opportunity to buy (call it purchase-price), and the number we can buy (purchase_count)  find the highest price opportunity to sell (sale_price), and the number the purchaser is willing to take (sale_count)  if purchase_price >= sale_price break out of the loop, no more profit opportunity exists  determine how many we can actually transact based on minimum of purchase_count and sale_count (call it transact_count)  (consider that we've sold those for a profit of (sale_price - purchase_price) times transact_count  reduce the number of opportunities to buy at that price by the transact_count    if that count reaches zero, remove the entry from the dict entirely  reduce the number of opportunities to sell at that price by transact_count    if that count reaches zero, remove the entry from the dict entirely go back to "loop".

Another way to think of/phrase this is that Java, like most OO languages (but not, I think smalltalk), exhibits dynamic invocation based on the type of the prefix parameter, but NOT the argument types. Arguments, as Stephan says, are only used for compile time polymorphism (which is so limited that a lot of OO folks don't even use the term polymorphism to describe it, even though much of the formal literature does).

Al Hobbs wrote:If you really have to put it in the JSP you could use the script tags and put what Simon wrote in there.

Which was what I had in mind. Of course, what I believe we're seeing here is one of those all-too-common situations where someone's trying to achieve a goal that requires multiple skillsets at once, and that's compounding the problem geometrically. I see our poor OP as having three (at least!) concurrent problems:

Designing/debugging the algorithm/computation

Coding that as a Java expression

Getting the interaction between Java and JSP-tags correctly formed

And it's quite possible that OP is actually dealing with someone else's code they've been asked to "fix" (whether that someone-else's-code is an example found online they're trying to fix, or a professor's assignment, or company code base a boss said "could-you-just" about). That would mean that OP might well not understand a ton of critical context.

That's a lot to try to answer in a simple text-oriented question

For now, however, I'll add this. If you want to take my code and embed it in a JSP (which I've mostly long-since forgotten how to do), you'll need to solve two small issues.

The imports must be handled "at the top" using a directive--but I don't recall the exact format of that directive. You can probably look it up

The elements that go inside the dollar-curly-brace aspects of a JSP should be valid Java expressions (referencing in-scope Java variables)

To deal with the latter, you'll need:

A sriptlet declaring and initializing the Java variables

and the simple expression(s) -- the stuff in the parens of the system.out.println I showed, in your dollar-curly-brace parts

Not sure that'll move anyone forward very much, but it's the best I can offer right now.

All that said:

JSP/servlets are a pretty passe technology. If you're learning for learning's sake, you might want to reconsider the technology choice. (But if this is assigned work, of course, you get no choice )

Scriptlets are, and always were, nasty. Please don't think this is a good solution, even in the context of JSP. But to make it better, you'll need to learn about (and be able to employ) servlets.

Since you're starting from scratch, you have many unrelated things getting in your way at the same time. This is a bit dated, but the key concepts haven't changed at all (they've been added to, but you can ignore the new stuff while you're starting). This was written for an older version of netbeans, but I think you'll have a fighting chance of following it through to a first success:

https://docs.oracle.com/javase/tutorial/getStarted/cupojava/index.html

Rod Taylor wrote:
1) Can I use the toilet if I need to? If yes, what's the regulation?
2) Can I use scratch pad for calculation? I'm very used to drawing objects, etc for better illustration of the question.

This depends on where/how you take the exam. If you do this at home, then it's a big, unequivocal no for both of these. There is, however, a rather nasty "scratchpad" provided in the test software. Damnably hard to use, but perhaps better than nothing.

If you take this in a physical test center, then in principle, you're allowed both. I have taken a pee in the middle of one of these exams (actually, if I recall it was exactly the 808 / Java 8 Associate exam to which you refer). And they gave me a small "whiteboard" for making notes on. However, they didn't give me any means to erase it!

BUT, both of those things can vary by test center, so if you really need to know, you'll have to ask at that exact center you propose to go to. Frankly, even then, I would be ready to be denied both things even after being told I could, unless you happen to meet the exact same person acting as proctor.

Stephan van Hulst wrote:But seriously, use the command line tools before you use an IDE. You will then form a much greater understanding for what happens behind the scenes when you eventually use an IDE.

As a counterpoint, from a teacher's perspective I must entirely disagree. For sure you'll want to know this stuff in due course, certainly before you consider applying for a job, but since it's clear you're a complete beginner, your best route for starting is the one that has you *succeeding* as soon as possible. There's a *ton* of stuff for you to learn eventually, and you need to pick a path through the woods that doesn't take a detour at every weed and cross track.

Take a stroll around youtube and look for some getting started videos using the IDE that you're looking at. The IDE stuff isn't hard, but you'll benefit from a walkthrough showing the ideas of making a project, then making a class, in a package, within that project. Then in the class, you can create a main method, and there, you can write "hello world".

Words are not a great way to describe visual actions on a user interface, sadly. Of course, the UI changes a bit from time to time, so be careful that you don't have too old of a video.

Good luck

Stephan van Hulst wrote:I could have sworn that I've seen them referred to as "method handles" before. I guess I've dreamt it up.

Anyway, my previous explanation still holds, just substitute "method reference" for "method handle".

Method handles are essentially an API feature that provides for much faster invocations in reflection type situations. The name is real, it's just not the right name for this. But yes, your explanation is totally solid.
 

Rod Taylor wrote: ...  how does JVM decide when to create an object or when to look for the same constant on the pool?

The compiler, and the classloader look for an object in the constant pool. There's some version of a garbage collector that can also do this, but it's not, I believe, enabled by default.
Beyond that *all* string objects that are created as part of the execution of the code will be new strings.

The reason is simple, doing dynamic pooling is expensive in CPU power and it's a waste of that power unless a sufficient number of duplicates can be expected. That's a question for the program's designer, not the designer of the language, nor yet of the JVM.

By the way, this is one of the topics we discuss in my Java certification study classes--I'll be running one of those next week, starting Tuesday. Lots of live questions, discussions, and code (but no slides!) if you in the mood, join me: Java 11 Study Course

Liliane Top wrote:@Stephan I looked up what the meaning is of method handle as opposed to a method call and went down this rabbit hole java.lang.invoke.MethodHandles

Even more confused now.

It's not a method *handle*. It's a method *reference*. Just a typofumble, but a massive difference when it comes to the documentation to which the term will lead!

Very briefly/superficially, these two are exactly equivalent (in this case):

Comparator::reverseOrder
and
() -> Comparator.reverseOrder()

Serpher Onwave wrote:...
My object is to determine number of days between days.

You would likely do well to look at the java.time.LocalDateTime class for this. It has far more features for this kind of thing built in, rather than having to mess about for yourself. E.g.

import java.time.*; import java.time.temporal.*; // ... var now = LocalDateTime.now(); var then = LocalDateTime.of(2022, 7, 20, 12, 00, 00); System.out.println(then.until(now, java.time.temporal.ChronoUnit.DAYS)); // 10 days -- for code run at 15:14 July 30th... System.out.println(then.until(now, java.time.temporal.ChronoUnit.HOURS)); // 243 hours -- as above :)

HTH,
Simon

Paul Clapham wrote:[Both Class.getResource(String) and ClassLoader.getResource(String) have been in the API since Java 1.1.

Exactly. For those of us that first saw Java as an alpha release, and were teaching it when it at version 0.98 pre-release, that's a change But I do need to investigate the significance of your observation about modules. Good catch!

Stephan van Hulst wrote:
...
Finally, you MUST use a type name when assigning a lambda expression or method handle to a variable:
Predicate<String> strippedStringPredicate = s -> s.strip().equals(s);

but you can use a cast, which is delightfully ugly and mostly pointless in this situation, but does also support the generic intersection type if you have a use for it:

var strippedStringPredicate = (Predicate<String> & Serializable) s -> s.strip().equals(s);

Try this:

public class LoadMyResource {  public static void main(String[] args) throws IOException {    URL res = LoadMyResource.class/*.getClassLoader()*/.getResource("/mydata/MyData.txt");    try (BufferedReader input = new BufferedReader(        new InputStreamReader(            res.openStream()))) {      String line;      while ((line = input.readLine()) != null) {        System.out.println(">> " + line);      }    }    System.out.println("All done");  } }

Create a file "MyData.txt" with some text in it. Note this must end up in the directory mydata in the output jar file. How you do that is up to you.

Then ensure that your output binary jar file has this structure:

/resourceuser/
/resourceuser/LoadMyResource.class
/mydata/
/mydata/MyData.txt

Notice this structure won't necessarily happen by default if you use an ide. But, if you use maven you can just put the MyData.txt file in a subdirectory called mydata, and ensure that directory is in the directory "src/main/resources' and maven should do the rest for you.

Note that the commented out ".getClassLoader()" part used to be required, but in more recent versions of the API, they added the getResource method to the Class class, so you can skip it. I don't remember when that happened, probably years ago, but just in case, if you get a "no such method" problem, bring that back into place.