Piet Souris

Hi Jeff,

the book sounds very interesting. Can you tell something about the mathematics you use in your book? What level can we expect!

I took the liberty of rehearsing my file reading abilities (not something I do every day) and rehearsing the LocalDates that Rob mentions, and try the new 'var' from java 9.

Well it turned out to be a big struggle that took me hours, and I noticed a few things that I could not handle.

First of all my code:
public class MarkRichardson {        public static void main(String... args) {         new MarkRichardson().go();     }         private void go() {         var input = getInput();         if (input == null) throw new RuntimeException("Can't read inputfile");         var dateMap = input.stream().collect(             groupingBy(                 LocalDateTime::toLocalDate,                 TreeMap::new,                 toList()             )         );         dateMap.entrySet().forEach(System.out::println);         System.out.println(dateMap.values().stream().mapToInt(List::size).sum());     }         private List<LocalDateTime> getInput() {         var dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSSSSS");         var p = Paths.get("D:\\JavaProgs", "DatesInEenRaarFormaat.txt");         try (var stream = Files.lines(p)) {             return stream.map(s -> LocalDateTime.from(dtf.parse(s))).collect(toList());         }         catch (IOException e) {             System.out.println(e);             return null;         }     } }
The big problem, that took me hours to find out, was that:
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSSSSS"); String s = "2018-10-12 09:24:30.123456"; LocalDateTime ldt = dtf.parse(s);
gave an error: ldt could not be converted to LocalDateTime.
After a while, this worked:
TemporalAccessor ta = dtf.prse(s); LocalDateTime = LocalDateTime.from(ta);
Hmm, it worked, but not very intuitive...
But the biggest problem was yet to come.

I had copied all Marks String dates into a Notepad file and saved it as UTF-8 to disc.
Whatever I tried, I could not read them in as Strings. It was maddening.... I got the much saying error that the read in strings could not be parsed at index 0, although in the debugger they looked exactly as my typed in string.
Saving the file as ANSI did work, without any problem. You read it in with Files.lines(path) and although the API says that it then reads the file as UTF-8, it worked without a hiccup.

And lastly, something that took me also quite a while to solve (if I solved it)
The API for Files.lines (or readAllLines) rells that you are supposed to use a try-with-resources. Okay, but how?
Files.readAllLines returns a List<String>, and
try (List<String> result = Files.readAllLines(path) {...}
gives an error, since a List does not implement AutoClosable.

So I resorted (see my code) to
try (Stream<Integer stream = Files.lines(path) {     // see the code }
Hmmm... this was an exercise not to be forgotten any time soon!

A shock for me: I thought I knew my way with LocalDates and Files, but now I'm standing with two legs on the ground again, as we say in Holland.

Can someone far more knowledgeable that me explain how this UTF thing works, and how to handle Files.xxx with try-with-rexources?

Well,

it is an ever going on discussion about beginners and an IDE. I used an IDE right after I tried to compile my first program and couldn't believe the misery I got on my screen. See for instance this old discussion:

old discussion

Four years ago I followed the Scala course at Coursera, from Martin Odersky (one of the finest courses I've ever had, thoroughly recommended), and there I used an Eclipse version with a Scala REPL, and I found it really great! I made all my assignments in the REPL, sometimes trying to send in my REPL instead of a decent Application!

But using a decent IDE is fine enough for me as well, have never missed a Java REPL. Wonder if I have to change my opinion.

Rob Camick wrote:Again, I repeat you should not be using the getGraphics() method to draw onto a Swing component. You use the Graphics object passed to the paintComponent() method of the component.

Interesting. I just stated that that technique works, and you state that one should not use it. But let us not pollute this topic, I hope OP has enough information to solve his problem, and maybe we can come back on this subject later, in some other topic, perhaps.

Well, had to adjust JAVA_HOME and my Path, but then JShell in the cmd worked first time!

And so far, works a treat.The only thing really missing is when I type, say, 'IntStream.' and being used to a popping up list of all that I can type, I now get nothing and have to do it from memory. Culture shock! But I have just started investigating, who knows what I will discover...

I will, but as a convinced command line hater I must first find out how that works!    

You're welcome! Since this all is a bit unusual, please let us know about your experiences, whether there are other problems that were unforeseen.

I see. If editability is not relevant for your application, then I would go with Rob: use a BufferedImage to do your drawings (ironically, you must use the bi.getGraphics() for that as well), and in your paintComponent draw that bi. I guess the examples will make it clear how to do that.

For text input, I was thinking of adding a JLabel for that, or use the Graphics method g.drawString(...). Well, let us know if you need more help.

Hmm... it IS working, but that JShell looks to be bug ridden. I've had lots of null pointer exceptions. If I want to type 'var a = 9', I get the NPE after typing 'va'.

Anyone using NetBeans 9, having such experiences?

If done carefully, the technique of using both the getGraphics to do direct drawing and using paintComponent certainly does work beautifully, in my experience. Just make sure that whatever you do in the getGraphics, is reflected in your data structure, so that in a later paintComponent that same situation can be restored.

For instance, if you are drawing lots of shapes on some panel with other components on it, then you could have a List<MyShapes> and a currentShape. Change the current shape with the direct method, and in the paintComponent you simple redraw the List. Is relatively easy to implement, and relying solely on the paintComponent would be far too slow. If anything of that is applicable here, I don't know, but I could have a look.

Enjoy the lead (and a cow) while you still can... I'll be catching up real soon!  

Hmm, solved it, I hope,

It is about the file 'C:\Program Files\NetBeans 9 RC\etc\netbeans.conf'. Near the bottom there is the outcommented line:

#netbeans_jdkhome="path/to/jdk"

that must be changed to

netbeans_jdkhome="C:\Program Files\Java\jdk-10.0.1"

(or whereever you put your jdk)

But o horror: whatever I tried, I lacked the right to save that editted file! So I messed around with privileges and similar things, not knowing what I was doing, but finally got it somehow working. Hopefully, next time Apache delivers some decent installers... Brrrr.

hi all,

Today I installed java 10 and NetBeans 9 RC, on both my PC and a laptop.

However, whatever I do, I see no sign of JShell, both on laptop as on the PC. Not in the Tool menu, not in the test library's, not in my run configuration. Spent hours on the problem, but in vain, sofar.

Looking at Google, it seems as if I am the only one suffering from this problem. Is there anyone who has any idea what I might have missed or where I should look for possible problems?

Thanks in advance!

Now that you've come to mention it....

In the insurance business reporting and pricing are based on what we call market consistent valuation. The regimes, like IFRS4 and beyond (especially the current IFRS17) and Solvency II, are extremely strict. Every simplification that you make in your models, every approaching way has to be clearly explained and the least thing is that you come up what the financial impact of such a simplification is (even in the cases where you make a simplification because the real thing is far too complex to model, or would require too much time to calculate). And the reviewers (be it the accountant offices or the insurance government institues) are very very strict.

For the calculations: think about a large insurance portfolio that you calculate the cashflows for the next 80 years, using tens of thousands of scenario's and assumptions for the coming 80 years.

But so far, no reviewer has ever come up with the question what the impact is of using 64 bit doubles, compared to using infinite precision floating point (no idea how we are supposed to do that). And how could we? At the moment the deadlines are very strict. To gather all the data, to make the many million calculations every month, do the reporting, we only have about 5 working days available. So speed is of the utmost importance. But interesting question, though.

I'm content with the current longs, doubles and (hardly ever use them) BigDecimals. If ever, getting rid of the primitives, operator overloading, scala's type and being able to write a.method(b) as a method b, and a Tuple class would be my priorities.