L Foster

Hi, thanks for the post.
I have been coding in Java for many years, and I use an IDE heavily.  But I also think it is very beneficial to be able to code without one.  The reasons are as follows.  IDEs steer you in a certain direction that may be very obvious and common, but that may not be where you wanted to go.  They will, for example try to fill out a for-loop as either iterator or count by default (I forget which) but you would have preferred the other way.  Next thing you know you are wondering what the offset of your item is.  That sort of thing.
Another issue is that you won't be learning the concepts "natively" for yourself.  You can become dependent on the IDE and not be intimate enough with the details of what you are doing.
IDEs could be thought of as "yesterday's LLM", in that they will try and do as much for you as they can.  The best reason of course is to accelerate your work.  But like LLMs, if they throw some code your way and you don't understand it, you will be in trouble at some point.
Even now, I sometimes work without an IDE just because I'll either be working somewhere that is not convenient for one, or because it is just some small project.  I find, however, that I will gravitate toward things I knew before IDEs were common or as powerful as they are now (or Java).  That's another reason to push them aside--as the language grows and evolves, you should still get out of the IDE and practice.
But give up IDEs altogether, no.  They can help you learn those new things, they can accelerate development, they put GUI interfaces in front of debuggers, and so on.
Do learn this stuff independently.  Do get into an IDE later.

I would like to offer my two cents on the no-args constructor.  These have been disdained in recent years because of the issues pointed out recently of making invalid instances.  They would also tend  to make instances that are not thread safe.  That's partly because the creational thread could be part-way through completing the instance' data when the instance is used by another thread, but also because you can never be sure if the completed instance might get changed by one thread while another is using it.

One alternative offered is an "all-args" constructor, which I think you mentioned.  That's a term used in the Lombok framework.  That is fine, but at a certain point you can get an unwieldy number of arguments, or you can end up with multiple "many-arg" constructors (as the OP mentioned).  There is an excellent discussion of this in Bloch's "Effective Java".   What Bloch suggests is that above a certain number (4?), you employ a Builder pattern.  That one has a builder supplying the created object (which can have an all-args constructor with appropriate defaulting for variations you might run into).  This builder is responsible for having setters (which don't have to be called set*) for any parameter you might want, as well as doing validation before returning your completed object from a "build()" method at the end.  This is usually done with a fluent coding style.  He also mentions the use of static factory methods, which can return an instance of an interface, so that for things like testing (maybe) you could return a different implementation.  Under other circumstances, you could return the same object multiple times, etc.

That said, if you are going to be making objects with some kind of automated tooling (you mentioned introspection and newInstance) doing the classic "bean" pattern with no-args + many setters might be just fine.  If you setup packages just right, you might even be able to avoid having anything with access for changing it once it has been populated.  Bean pattern is how many of the older frameworks do it.  It is what Java Beans were initially intended for.

This part the OP mentioned about

I couldn't simply throw a list of values at the class definition and get what I wanted. I had to scan the entire list of available constructors and match the values supplied to the constructor argument lists to see which constructor to invoke.

is something Bloch also describes in his book.  It is what I alluded to above--variations in the arguments needed to make a complete object.  His solution was multiple different factory methods with names like "of(arg1,arg2)" or "of(arg3,arg4)", and each of those is responsible for completing and returning a validated object.  Builder could still work for that as well.  Different names for factory methods specific to the situation could be chosen as well.

I hope that helps

Just replying to Mr. Van Hulst,

The one I was looking at was called "java.activation".   My module file has to "require jakarta.activation"--and that's been there since I moved up to Java 11.  However, I oddly saw this message about "java.activation".

As I said, I wanted to learn about tools here.  Thank you

I found a way to answer my own question.  Not sure if there may be a better way out there, but here goes.
c:blahblah>gradlew dependencies > Configure project : Project : => 'my.project' Java module > Task :dependencies ------------------------------------------------------------ Root project 'my_project' - my_project ------------------------------------------------------------ annotationProcessor - Annotation processors and their dependencies for source set 'main'. No dependencies apiElements - API elements for main. (n) No dependencies archives - Configuration for archive artifacts. (n) No dependencies compileClasspath - Compile classpath for source set 'main'. +--- jakarta.xml.bind:jakarta.xml.bind-api:2.3.2 -> 3.0.0 |    \--- com.sun.activation:jakarta.activation:2.0.0 +--- org.projectlombok:lombok:1.18.12 +--- org.jfree:jfreechart:1.5.0 +--- org.glassfish.jaxb:jaxb-runtime:3.0.0 |    +--- com.sun.activation:jakarta.activation:2.0.0 |    \--- org.glassfish.jaxb:jaxb-core:3.0.0 |         +--- jakarta.xml.bind:jakarta.xml.bind-api:3.0.0 (*) |         +--- com.sun.activation:jakarta.activation:2.0.0 |         +--- org.glassfish.jaxb:txw2:3.0.0 |         \--- com.sun.istack:istack-commons-runtime:4.0.0 ...

Even though there are still issues in the project, these dependencies are still spelled out.  Still have to read it, though ;-)

Just googling "java module graph" did not help.  Good thought, though.  I need to know in this case, because the module was deprecated and now removed in the latest java.  I have other dependencies and one of them is trying to depend on this.  I wish I could just snap in things as needed to a modules file, but even my brief experience has taught me it is never that simple.

I need to know how to figure out which module or class (of my own) requires a specific module.  I want to be "taught to fish" rather than trying to recreate this issue here and receive (the usual excellent) help from others to solve it.  I want this for a couple of reasons:   first, I suspect this will happen again after I solve this one, and second, this only happened after a lot of big changes -- move from maven to gradle + Java 11 to Java 17--which I think will make it difficult to recreate this bug without the whole codebase.  So, I want to be able to solve this myself if possible.

So, when I see gradle claiming

module not found: java.activation

Or any other module, is there some tool I can use that will tell me what code has that dependency?   Yes, I have seen that jakarta.activation is supposed to have replaced this as of long ago.  I have that dependency in place.

Thanks

I see some great posts pointing out interesting things about the example code.

Interesting question in some ways.  If I were asked "how I would optimize it", and I don't guarantee this would win points, I think I would reply that I would paste the code into an IDE, run it a million times, and see how long it actually takes.  Then I would possibly profile it (although this is pretty small) to see where the time is going, and one fix I would consider changing would be the concatenation argument (+) to using of StringBuilder.append().  I say "consider" because there may be some JVM optimizations by this point that handle underlying use of String Builder.  After any such change, run it a million times again and time it.  Multiplying runs like that is a good way to force differences to emerge even if they were fairly small to begin with.  As has been pointed out, this code will not do anything.  As such it will run pretty fast.

What is it you need help with?  Please elaborate.

It is always best to work through problems yourself.  Perhaps what you asked for help with was the "implement your code here" blocks?  If so, think about what the methods are named, and of course the (apparently) requirements list.  Consider how you would make those things happen using Java.  This really is where the fun begins.  You could create something at this point.  Along the way, remember you can always print out the states of things using code like this.   This is an example of how to dump room contents, assuming a room has been declared and has data in it.

   System.out.println(room);

One hint I would give: those "toString()" methods have been commented out.  /* some code */  takes code "out of commission".  Removing those from around the code will allow it to be executed again.

Have fun!

Having seen this and scanned some of the discussion, I want to raise a few points.  Firstly, it has been gospel in OO going back to early days that "static methods are bad".  However, when the designers of Java got their opportunity, they did leave them in.  I have long held that belief because static methods tend to not only bypass the whole encapsulated data notion, but they also stick you with only a single copy of something.  Having multiple instances of a class with different state is one of the things that drew me to OO that long ago.   Static methods also require class members rather than object fields.  Further, if you want to setup the state of a class that has all static methods, it either all has to be in constants or the static members have to be mutable.  Hence, it would discourage immutability.  And on a basic level, without an object, it is as if you are still doing Procedural code.  Why waste time compiling Java at all?

That being said, there are exceptions that are encouraged by industry experts.  In particular, Joshua Bloch's "Effective Java" encourages the use of static methods as a means of improving how objects are created.  Instead of directly hitting the constructor, you use a static method to get an instance.  This comes with it a host of advantages, such as the ability to constrain the number of instances to just a few (sort of like making a "multiple-ton").  It allows one to enforce a builder pattern by making the constructor itself private--which in turn allows one to make an immutable object even when all parameters may not be available at one time.  Further, with a constructor you get only one name -- same as the class.  Using a static method to construct (factory method, actually) you can give a more meaningful name to a constructor to be used for a specific type of configuring of the object.

I have also seen some rather convincing arguments that a static method is acceptable if it does something general to something that is related to a class, but is not using any of the class's state to do so.  Suppose you had a "Person" class, but you wanted to have a method that properly capitalizes person names?  One could argue that the Person class would be a good place to put it, but that it might be leveraged by others.  But it could as easily be argued that "capitalize()" belongs in some utility class.

In summary, I think an ideal question here might have been about when it is advisable to use a static method.  Simply having asked, I suspect it is apparent to the OP that there is more to the discussion than "one is better than the other".

Awesome to have Ken Kousen on the forum.  I have seen him and heard about "Kousen IT" a few times.  That's witty.

I am curious: is it possible for a boss to provide too much feedback?

Thank you

Greetings, All.
I found a nice course on HDPCD certification.  When I say 'nice', I mean informative.  This teacher seems to have all the right information, but is not as slick as some instructors online.

Anyway, although I had never thought of taking HDPCD, I took the course to learn more.  However, the FAQ states that HDPCD is discontinued.


https://www.cloudera.com/about/training/certification/faq.html  this FAQ states:

Will HDP exams continue to be delivered?

The HDPCSD and HDPCD exams were retired on December 6, 2019.

I think the course is still good info (like I said, I did not want to take the test anyway).

The course is "HDPCD:Spark using Scala" on Udemy.

Thanks

Hello, Irvin:

You should take a look at the logic for the third function.  You seem to be expecting it to do a lot, but not giving it any relevant code to do so.  To get you going, you should:
1. Review == and the "equals(Object o)" method in Java.
2. Consider: how could the method ever return anything other than "true"?  You have the default at true, and then you never change the value to anything else.
3. Review some of the methods in java.lang.String.

I hope that helps.

Hello, All.

While I am actually still struggling with a related issue (that is, I am no expert), I can tell you something pivotal to your understanding of this problem.

Java7 and Java8 included JavaFX in their JVM.  As of Java9, that was no longer the case.  Java9 through Java12 (+ assume) requires you to get JavaFX as a module and use that module.  If you are using Maven, you can get past this by including dependencies.  I think these should work.
       <!-- https://mvnrepository.com/artifact/org.openjfx/javafx-controls -->        <dependency>            <groupId>org.openjfx</groupId>            <artifactId>javafx-controls</artifactId>            <version>11.0.2</version>        </dependency>        <!-- https://mvnrepository.com/artifact/org.openjfx/javafx-swing -->        <dependency>            <groupId>org.openjfx</groupId>            <artifactId>javafx-swing</artifactId>            <version>11.0.2</version>        </dependency>

However, the swing dependency may not be needed, and there are other dependencies to do with JavaFX that you may need, such as javafx-fxml and javafx-media.

Please refer also to https://openjfx.io/openjfx-docs/ for further info.

I hope this helps someone.

This is my question for the author of the new book: "Architecting Modern Java EE Applications".

Looks like hope for the future.  My question to you: what motivated you to take the time to write on this particular topic?  I have seen fewer organizations embrace this technology than in the past.   It is far from moribund in my view.  Are there certain developments in JavaEE 8 that really excite you and convince you this is an excellent approach to modern problem-solving?

Thanks