• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Stupid Terminology Thing (Again) - Sybex OCJP

 
Saloon Keeper
Posts: 1328
40
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I mentioned this before way back...it is sort of dumb, sort of obvious, but I find myself thinking it again...

in all the summary stuff like on page 481 of the 815 book, we refer to classesToCompile and classesToCompileIncludingModuleInfo.

Yes, I know what it means, but I find them sub-optimal names for two reasons.

While the most common case is certainly one Class/Enum/Interface to generate from each Java Source, even in that case we are naming Java Sources, not .class files.

Like, module-info.java rather than module-info.class or MyInterface.class or simply MyClass (as specified when using JAR or running with Java -- except single-file-run-from-source).

The exceptions, like when there are Inner Classes or Nested Classes, or some top-level-but-not-public-helper-classes so there is no longer a one-to-one between sources and artifacts aren't really all that rare.

In these cases, you are listing all the sources, not all the artifacts, which will be larger in number.

To my shame, I don't know Ant, Maven OR Gradle as well as I should, but I have been using cmake/gmake/make since I was a kid, and so have some other people who have Java as a second or third language and are trying to learn it well.

In gmake, all your command lines actually DO have the targets of what you want to build appearing in the command line.
What needs to get compiled in order to make these things you ask for is buried in the make files, and does not get specified on the command line, the opposite of the javac commands.

It would be more consistent with the classical Java docs:
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html

They seem to have switched terminologies to say sourceOrClassFiles here:
https://docs.oracle.com/en/java/javase/13/docs/specs/man/javac.html

I think because you can be processing .class files for annotations purposes with the javac command, not just compiling .java sources to .class files.

Not a big deal, but each time I read it I do say "Well, of course, we are specifying the SOURCES, not the resulting CLASSES, here" and if I go back to C/C++ at least, that isn't true there, I am actually listing the targets I want built, not providing the list of sources which is hidden away in make files, so I do keep noticing it.

Whatever.  
 
Jesse Silverman
Saloon Keeper
Posts: 1328
40
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I posted this, the site reminded me of the post I made back when I had first noticed this:
https://coderanch.com/t/736440/certification/Sybex-Chapter-Compiling

Apparently I remembered Gradle enough to be sure as I was typing the post that my Gradle command lines mentioned the artifacts they wanted, like minestrone soup, not the ingredients: carrots, potatoes, celery, pasta, chickpeas, seasonings like you do with javac.

javac in this regard is not like running gmake or gradle, but like cc except that order-of-compilation-problems are resolved by javac, not by you before you type and enter the command.

Probably because java sources compile against each other's .class file outputs, e.g. "reality" not just the (possibly untrue) "promises" found in .h files at compile time, so it actually matters.

Subtle but noticeable when moving back and forth between compile paradigms.
 
Saloon Keeper
Posts: 13282
292
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not sure that I agree with your notion that a .class file contains a class, and a .java file doesn't.

A class is an abstract concept. A .class file contains a binary representation of that concept, whereas a .java file contains a textual representation.

It reminds me of the famous painting by René Magritte. A painting of a pipe may not be a pipe, but we surely will be wasting a lot of time if we keep insisting on it.
 
Jesse Silverman
Saloon Keeper
Posts: 1328
40
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is really poetic, and pretty, but getting away from poetic visions to prosaic reality, what about this .java source file?

NotJustOneClass.java:



I like that Java sources can only contain one public, top-level class, and that it needs to be named the same thing as the source file name.

I like the stylistic convention that we strive to only define one top-level class, enum or interface per Java source file.
People complain about that as being stuffy, uptight and constricting.
But I've spent probably weeks worth of hours at work figuring out where in the world, source-wise, various functions and methods were coming from in "Other languages" that don't organize things as such.

Yet the above represents a bunch of .class file artifacts, but is a single-source.  I don't love that convention, but it is quite legal and not that abnormal.
Of course, nested and inner classes literally can't be saved in a source named the same as their class.

So it was to that phenomenon I was referring.

That is going to result in five .class files, on disk and at run time, but is one source to javac.
 
Jesse Silverman
Saloon Keeper
Posts: 1328
40
Eclipse IDE Postgres Database C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The point of invoking a Belgian Surrealist was to remind me that neither the .java source nor the .class bytecode was the class itself, which is a pure and abstract notion?

I am reminded of one book at the top of my "Sitting on my bookshelf making me feel guilty I haven't practically committed it to memory because it has so much great stuff in it" list.

When facing me, it looks like this:



The captions are "This is not a sailboat" and "This is not a sailboat".  I only realized this for the first time now.  For all these years I thought the one on the left said "This is a sailboat".

Like, Wow, man!  I also found 81 cents and my missing second pair of eyeglasses when looking for it...

That is not a book cover?
 
Stephan van Hulst
Saloon Keeper
Posts: 13282
292
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:The point of invoking a Belgian Surrealist was to remind me that neither the .java source nor the .class bytecode was the class itself, which is a pure and abstract notion?


Yes, that was the first half of my point. The class is an abstract concept that lives in the mind of the programmer, or in the memory of the JVM once the class has been loaded. However, my full point was in opposition to Magritte. We KNOW that he is right, but that's not how language works. We often use language to refer to abstract concepts, and not depictions of those abstract concepts. If give a child a picture of a cow and ask them what it is, they will say "cow" and not "picture of a cow". For this reason, I believe it's just as valid to refer to Java source files as "classes" as it is to refer to Java bytecode files as "classes".


Jesse Silverman wrote:That is really poetic, and pretty, but getting away from poetic visions to prosaic reality, what about this .java source file?

NotJustOneClass.java:


Well then, it's good that the original phrase that got you to start this discussion was classesToCompile, and not classToCompile.


The captions are "This is not a sailboat" and "This is not a sailboat".  I only realized this for the first time now.  For all these years I thought the one on the left said "This is a sailboat".


Haha, wow that was a great coincidence, and also a great book cover. I wonder what the designer of the cover was thinking when they created it.
 
Jesse Silverman
Saloon Keeper
Posts: 1328
40
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am taking tests all day today, so I guess I do have my lawyer hat on.

Not that it is super-important, but you are indeed supplying a list of sources there (I see there are weird cases outside of the scope of the exam where you are possibly actually supplying classes for annotations processing, but someone who just knows the test stuff doesn't know that can happen.  If you don't use wildcards, each item in your list corresponds to exactly one source, but to one or more classes that will be output.  The names will match the sources, but classes may come out of the output that aren't mentioned on the command line...

Then I realize when one uses wildcards for doo/wah/diddy/*.java my argument falls apart, because you aren't providing any explicit names, and each argument you provide may wind up meaning any number of .java sources, let alone any number of resulting .class files.

I still feel it is a little confusing that when so many command line commands have you specifying the names of the target things you want to get out, but cc and javac have you naming (perhaps with wildcards) what sources you want to compile (into whatever they may compile to, not specified) to be calling them <ClassesToCompile> rather than <SourcesToCompile>.

At this point, we have talked it over so much I will never actually be confused again in the future, even when answering javac questions after using gradle or gmake all morning.

Cheers!
 
I'm all tasted up for a BLT! This tiny ad wants a monte cristo!
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic