• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Bear Bibeault
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • salvin francis
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Jj Roberts

Ever-repeating question - Java and Netbeans and getting them to work together

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everybody - I am trying to get myself a little bit more Java-knowledgable.

I have set up a brand-new installation of Kubuntu 20.04 on a brand-new laptop to use as a Java development machine.

I have previously run Netbeans with Java on a much older distribution and I had absolutely no problems.

Now, I am tearing out my dwindling supply of hair and have even reinstalled from the bare metal just to ensure I didn't do anything silly.

Anyway - to get to the meat of the matter
I open Netbeans Help and About and see the following:
Product Version: Apache NetBeans IDE 10.0 (Build 20190905-debian-10.0)
Java: 11.0.8; OpenJDK 64-Bit Server VM 11.0.8+10-post-Ubuntu-0ubuntu120.04
Runtime: OpenJDK Runtime Environment 11.0.8+10-post-Ubuntu-0ubuntu120.04

Starting a new project I get the old thing of a message
"Fatal Error:Cannot access java.lang fatal error unable to find package java.lang in classpath or bootclasspath "  on the "package helloworld;" line.

I have used the magic of Google and seen the hundreds of similar problems dating back years, but the fixes of inserting Java directories into the PATH just aren't working.

I have even inserted this into /etc/environment and nothing
JAVA_HOME="/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin"
export JAVA_HOME
CLASSPATH="/usr/lib/jvm/java-1.11.0-openjdk-amd64/lib"
export CLASSPATH


Does anyone have any ideas?

BTW, I have installed the standard JDK and Netbeans from the Ubuntu repositories.

Java is "java-1.11.0-openjdk-amd64"

Thanks in advance

 
Marshal
Posts: 71070
292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

You should omit “bin” from JAVA_HOME. Don't set a CLASSPATH.
 
Campbell Ritchie
Marshal
Posts: 71070
292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What happens if you passas terminal arguments?
I cannot promise that my suggestions will actually work.
 
Rick Meyer
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Cameron,

Thanks for the welcome - I have been lurking for a few weeks before deciding to chance my delicate sensibilities to this forum. It appears uncommonly civilised for a part of the internet.  

I had already done the convulsions and tricks and things with the JAVA_HOME as you said and that did not help - this latest permutation was something I got from the elsewhere and I was desperate enough to try it.

I have now removed it and will reboot, just to get the Path set properly.

I ran those commands and this is the output - the path in the "which" command is linked all over the place - and I will track it and put the info in below

As here

which leads to here

and again


It's a mess, but that's the way it's installed by default .....

And to think that the older version just slipped in and 10 minutes later I was doing my Udemy course.  


 
Saloon Keeper
Posts: 22790
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't go messing with /etc/environment. It's not a good choice for locating a JVM. I use $HOME/.bashrc myself, but any profile script that runs when you login is a good choice.

The home of a JVM, whether JDK or JRE is the root directory you get when you unzip product from Oracle (or wherever). If you use the Red Hat package manager or something similar, it will be a directory under /usr/java. You can have multiple installed JVMs. They're not Internet Explorer.

This would be my stock .bashrc Java code if I were running your JVM:


Note that it is critical that you export these two environment settings or no other shells will see them.
 
Rick Meyer
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, all,

I'm sorry - I was away for a day or so -price of earning a living.

I have tried all these suggestions and am putting them in my .bashrc, but the problem stays the same. I have tried various combinations of $JAVA_HOME with and without /bin at he end and so on. It's maddening when I recall that previously, I just fired up "synaptic" and looked for Netbeans and installed it, allowing it to pull in the JDK it wanted (8 incidentally).

Failing any magical interference, I'm going to peck at this off and on for a while and see what happens, although I'm not expecting much.

Thank you to everyone who gave me advice.

I'll be seeing you around.
 
Tim Holloway
Saloon Keeper
Posts: 22790
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK. Let me step back then. What I previously posted was just to get a default Java running on the command line. If that doesn't work, you have problems, possibly collisions with the OS alternatives subsystem.

But if NetBeans works like Eclipse, the settings for JAVA_HOME and the PATH are of no consequence. NetBeans may have already set its own preferred JVM in a config file which would have to be changed to make NetBeans run under a different Java.

Then there are the JVMs used by projects within NetBeans. If NetBeans is like Eclipse, each project can run under a different version of Java if it likes. The JVM to use is indicated as a project property.

What Eclipse does is use a logical JVM name which is set (using an Eclipse dialog) to reference a particular JVM location on your machine. If you imported a project and that JVM name wasn't defined to your new IDE that could be a problem.

The particular error you're getting smells like the built-in compiler not finding a valid JVM.  So you might want to check your project settings and look to see if you have the desired JVM registered for NetBeans to use.

And most critically of all, the location of a JVM is always the topmost directory that the JVM unzips to and NOT its bin, lib or other subdirectories. Nor, for thaf matter, the directory that the JVM zips into.
 
Rick Meyer
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Tim and the others who have been trying to help me.

I admit that trying to get Netbeans and Java running together has been a total PITA (if I may say such a thing). I have been using Linux since 1995 - kernel 1.2.8 I seem to remember, so I do know my way around it.

I have also been programming and doing software administartion since the 70's so I have been around - not a spring chicken anymore, though

Just wanting to get into Java, since it's the closest thing to a universal language, that uses Objects.

I have done a ton of reading and, honestly, don't see the hype. I know that some of you will be able to educate me.

I was watching an older thread from Junilu who was leading someone through a whole process, containing code to emulate race cars and fuel consumption and so on, and I thought to myself "Self, you should try to restart that old thread".

And, oh yes, I have abandoned Netbeans and installed Intellij and, although it isn't what I wanted, I can get things to run and work - so better something ugly that works than something pretty that doesn't.

Thank you to all. I think we can call this a defeat with a bit of looting on the retreat ...  
 
Tim Holloway
Saloon Keeper
Posts: 22790
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry to hear about your defeat, Rick. NetBeans has been around for a long, long time - I first knew it as Forte, in fact. It really shouldn't have been any harder to get running than IntelliJ or Eclipse. We do have many happy NetBeans users on the Ranch.

I'm not sure which "hype" you're talking about. If it's IDEs, that's really a subjective opinion. They each have particular strengths and weaknesses so it's mostly a matter of preference or shop standard.

If you're not sure why Java and OOP are so hyped, go back and look at some 1970's programs. Most of mine are in assembly language, since I was a Systems Programmer and high-level languages weren't designed to run inside OS internals at the time. But even pre-OOP/pre-structured COBOL is bad enough.
 
Rick Meyer
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

I was referring to OOP actually and I agree about older languages - being a Sysprog for over 20 years, Assembler and all.

I, personally think that the reason so much software was awful in the 80s was that (certainly in my country) many "programming schools" sprang up and offered three month courses where people didn't actually learn anything except how to use the language (mostly COBOL) in a minimal way so that they could find employment.  Most of these people had no idea how computers or the languages worked, had no love or sense of adventure to find anything out and so on.

I recall helping someone debug a COBOL program where they had a table (think array) that they indexed by zero and it was actually overlaying the working storage in front of that table.

That said - a decent programmer could and did turn out decent software and even nowadays bad programmers deliver awful software.

There has been a lot of talk about OOP, but I really don't see the software becoming all that much better. Mistakes still abound, bugs sneak in and so on.  

Nowadays, though, developers certainly need more training that they did in the old days. I taught myself C and Pascal (Needed for University courses) and was productive within a week or so.

I admit this OOP paradigm is evading me, So I will have to work on that.

Can anyone suggest a book that can be relied upon to rewire my brain?

Thanks again to all.
 
Tim Holloway
Saloon Keeper
Posts: 22790
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The hallmarks of programming prior to about 1980 was that most programs were monolithic. COBOL programs in particular were one big long file (and I had to bail one or two out because they got so big that IBM's COBOL compiler couldn't handle them). Fortran knew about subroutines, but they were mostly utility processes. About the closest thing to a "make" service in mainframe shops was SMP. Which was sort of hard-wired for OS maintenance and not for applications programmers.

In the late 1970s, Structured programming caught on (not without controversy) and around 1986, C++ became the first mainstream OOP language, though OOP had been around in some form since at least about 1960.

The hallmark of OOP is that it's based on objects, and where possible, objects model real-world objects. Like cars, rocket ships, chemical tanks, and so forth. Code and data, instead of being separate became joined together, with the data being organized into classes of objects, which also held the code that operated on that data. It became possible to think abstractly about objects instead of tracking every data item and its code separately. Also, you could protect data against accidental mis-modification since the object now controlled how the data was maintained.

The one thing that's noteworthy about modern-day apps is how large and complex they are compared to "big" programs of bygone days like, for example, General Ledger systems. There are usually many more source files, and while the individual methods in an OOP program are (ideally) no more than about 20 lines of code, the methods add up.

This trend took off with the advent of GUIs. A "green screen" app would basically have menus, data inputs and processing logic. A GUI app had all of the above, but it had to be artistic, and instead of just hitting ENTER or a PF/PA key, you had toolbar buttons, hotkeys, application menubars, right-mouse popup menus, mouse gestures and more. And frequently ALL of the above could trigger a specific application event.

So OOP was adopted as much for sheer survival as it was because it was Neat Technology.

I'm far too removed from beginning OOP to recommend any literature or traning myself. I grabbed it in 1986 as one of the early licensees (and resellers) of AT&T C++ and never looked back. I would imagine that you might find what you need in introductory Java books.

On the subject of code quality, however, there is no "magic bullet". As a Systems Programmer, I wasn't expected to grind stuff out in a hurry - when your code can take down a mainframe and send everyone out to lunch early, quality is more important than "productivity". Today, however, you're expected to "just turn it off and back on again", and being full of bugs because the schedule was unrealistic is considered normal.

There is, incidentally, an organization dedicated to quality in software. For all the good it does us.
 
Rick Meyer
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just One thing - and it's way off the title of the thread - COBOL was as usable with subroutines as FORTRAN was - they used the same mechanisms to "attach" the subroutines to the main routine (via the linkage editor), You may remember an entry in the DATA DIVISION called the LINKAGE SECTION, which would be followed by PROCEDURE DIVISION USING ....

Maybe you are thinking of online CICS programs, where giant monolothic programs very often could not be loaded into CICS.

Anyway - far from leaping to OOP, I was having so much fun writing assembler routines that did cross-memory services and setting up VTAM networks and so on, that I thought that OOP was just another passing fad - there were so many in those days.  

Thanks again for the chat, and I will get to rereading Junilu's thread.
 
Tim Holloway
Saloon Keeper
Posts: 22790
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True, COBOL supported subroutines, but the mechanism was really ugly compared to how Fortran and PL/1 did it (at the COBOL code level) and was mostly employed for calling out of COBOL to talk to CICS, IMS, DL/1, and so forth.

The real killer, however, was that there was no "make" utility and the stock JCL was geared towards compiling (and, where applicable, linking) one and only one source module.

In Systems, we were used to keeping complex, often multi-lingual build decks, but our applications programmers were fresh-out-of-school/learn in 3 days people and just getting a compile-and-go job to work was enough challenge for them.
 
They gave me pumpkin ice cream. It was not pumpkin pie ice cream. Wiping my tongue on this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic