Kristina Hansen

Rancher
+ Follow
since Oct 16, 2019
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
9
In last 30 days
0
Total given
0
Likes
Total received
29
Received in last 30 days
0
Total given
7
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kristina Hansen

It only would make any difference if you take out any DNS lookup at all by using InetAddress.getByAddress(byte[]) - any other way of creating a socket will perform at least some sort of DNS look up.
Also be aware of TLS - when you want to use something like SNI you have to do it on your own - wich quickly end up in a 20-line mess. Just using URL does it all for you.
TLDR: Unless you do it all low-level by yourself - nope - it doesn't make any significant difference.
4 years ago
Valid points - but in java.io File handling in particular for me is flawed if you look at the other "discusion" about "Errors, checked Exceptions and unchecked Exceptions" - IDK if you read it, but for short: for me unchecked Exceptions are all what the programmer has to account for upfront to let it happen - or to say it the other way around: if an unchecked Exception is thrown the programmer did something wrong and should rework the code. So for me, a FileNotFoundException should be a RuntimeException as the dev has several methods upfront to check if the file exists and if it can be accessed - but as it is an IOException for me that's flawed - cause this can only happen if something happens between the File.exists() call and the actual access - wich is often such a tiny time frame window it's often only abused by crackers to power glitch the clock to bypass security - wich shouldn't affect java anyway. But I guess that goes to far off top as the topic itself was answered by one of the most typical reasons: "missing permissions". In that case false make sense as true is only returned if and only if the file could had been created successfully. And to create a file on most modern systems you need write access to the folder you want to create a file in. So, when a createFile returns false the two logical options: does it already exists from an earlier run or does the process have rights to create one - and if you go really low-level that's actually how the "error" is caused in the first place: before the OS tries to create the file it checks if the current user has write permissions on the directory. So why not do the same: check write permission before try to write (create the file)?
4 years ago
in fact when you fill the buffer the next read would contain the rest - so the observation 1 "when entered 10 charachters it prints 10 - correct" is not valid as it only shows what was copied into the buffer instead of what's really in the internal stream buffer
4 years ago
just get rid of that module crap and use java as it was before project jigsaw
4 years ago

Rob Spoor wrote:

Johnny Joseph wrote:Why can't java provide another API which throws exception instead of returning false


There is. java.io.File is quite old, and parts of its API are terrible. Methods returning false without any more information, list methods returning null instead of throwing exceptions, etc. Fortunately, in Java 7 Path was introduced. Besides making it possible to provide multiple file system implementations (including non-local file systems), a lot of the methods throw proper exceptions instead. There is one caveat however - you often shouldn't look what methods Path itself has, but instead resort to utility class Files. For instance: Files.createFile will create the file, throwing a FileAlreadyExistsException if the file already exists.


That's bad design as it uses Exceptions for control flow - wich shouldn't be used in that way.

Johnny Joseph wrote:The problem occured due to permissions..However not shown any error and returned just false......That's the problem..Is there a way to identify the permission before hand i.e before using createNewFile()...Is there is any Java API to check for permissions and display the required permission with name doesn't exist.


Yes, there are - several in fact.
Have a look: https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/io/File.html
canRead()
canWrite()
canExecute()
exists()
isDirectory()
isFile()
isHidden()
Basically any method that returns a boolean can be used to correctly check upfront if what you want to create already exist or if you even have rights to do what you want to do. As said in my first reply: It's up to you as the dev correctly use those provided methods to check upfront instead of rely on useful returns or mis-used exceptions.
4 years ago
Because using Exceptions as controll flow isn't how they should be used. If you get a false from createNewFile() whatever it was you wanted can't be created. This can have three reasons:
1) illegal path
2) target already exists
3) no permissions
For 2 and 3 there're several other methods you can use to check before calling createNewFile() and it's your response as the dev to correctly use them - not of the API to throw an Exception to hint you made a mistake. About 1: always use "/" instead of "\\" as Java does the translation for you - stick to ASCII (more specific: a-zA-Z0-9) and don't use spaces - should solve "illegal" paths
4 years ago
Sure, it should work fine.
Be aware: Having multiple JAVA_HOME in PATH only the first match will be executed - hence it would be recommended to only use JAVA_HOMEx for all the different versions, set JAVA_HOME to one of them, and then only add JAVA_HOME to PATH.
4 years ago
EDT = Event Dispatch Thread
Not just a Java term but basically how any modern graphical environment works: Any time you as a human interact with any input device of system (even when touching the touchscreen of your smartphone) you generate what's called an (input)
event. It is most important above any else when you're dealing with GUIs you fully understand the concept of input events and a dispatch thread.
It comes down to this: You have your Java code running and then you have the GUI. Both are handled in their own threads - or simple: They run (correctly: they're executed) in parallel on the same time - but don't really interact with eac
h other. So whenever you either want to process an event or want to update the GUI you have it to de-couple it.
What means de-coupling in terms of GUIs: I bet you encountered a "frozen" application not responding to the mouse or any key presses. This is caused by someone not fully understood and hence not correctly used de-coupling.
When the OS sends your GUI an input event it's the EDT to take care of it and delegate it to the registered listeners. But, it's also responsible for drawing the GUI.
When you stick to Java and this forum you'll see there're often beginners come up with questions like these: "I want to have a timer. And I have a button. But when I click it nothing happens for 10 seconds and then it only shows 10 instead of counting.". The issue: They locking up the EDT so it can't draw anymore.
Same goes for your loading of your data. Although it may be fast, and maybe even fast enough to accept the short "freeze", it's not how you should do it. In fact, the correct way is to take the event, start a new thread to de-couple it from the EDT (so it can do its things) and when you ready and all is done and you have the data ready to update the GUI you have to correctly re-sync it back into the EDT. That's basically what you're doing in your main(): You let the EDT do all the GUI stuff.
From just looking over your code you're doing it wrong currently. You have the actionPerformed() - this is called from within the EDT - and call showTableData() inside it - so you do what you should avoid at all cost: Doing non-GUI related stuff inside the EDT.
To do it correctly: Start a new thread, let all happen inside it, and at the end just update the GUI with another call to invokeLater() so it gets re-synced back into the EDT.

Side-note: Your SQL stuff also has some flaws:
1) Don't use Class.forName() - that's obsolete (don't know why even still recent tutorials and books still use it - JDBC4 made it obsolet - and pretty much any driver today is a type 4 one).
2) You're using your prepareStatement wrong - you prepare a statement to not build a SQL string yourself.
3) Move the TableDataModel stuff from above the SQL stuff to below it.
4 years ago
Well - although already mentioned - I like the way Javas exception handling is designed. One just have to get used to it to utilize it.

In Java there're two major types of "issues": Errors and Exceptions, where Exceptions can be further devided into checked ones and unchecked ones (all that inhire from RuntimeException).
The doc already explains these three types like this:

Error: abnormal condition within the JVM itself that should lead to termination - and hence should never be caught / handled
checked Exception: anything that goes wrong outside of the JVM and can not be checked upfront
unchecked RuntimeException: logical codeflow issues that can and should be checked and handled before they thrown

Interestingly by its own explanation the SE API is full of misuses: FileNotFoundException (extends IOException) just as one example - it's easy to avoid by checking if something exists and the current user has access rights - the only way it does make sense to me is that someone may have thought about what happens between the File.exists() call and when the file is accessed - but such construct should only happen to those using a scope to power glitch a clock to crack security.
4 years ago
I counted at least 3 different JFrame references - that doesn't look right.
Also: Not really a neginner question - would had fit better in the gui forum (Why is it that anyone always post in Beginner?).
In fact: It's quite easy: Just add the JTable where you needed it, load the data a-sync not in EDT and then just set the model within the EDT.
4 years ago

Monica Shiralkar wrote:Java has concept of checked and unchecked exceptions. Why not keep everything. Why not keep everything as checked exceptions instead of having both checked and unchecked ? thanks


What about Errors?

Simple:

Errors: Abnormal state of JVM itself - shouldn't be handled at all
unchecked Exceptions: dev was too stupid to correctly check upfront - if an unchecked Exception is thrown it's an issue of the code and should be reworked
checked Exceptions: anything that can fail outside the JVM but can't be checked upfront
4 years ago
CMS is defined by the linked RFC - if you want to know how it works and what may cause the issue you have to dive into the protocol spec - if you don't want to bother with the protocol then I doubt you're able to fix the issue yourself
about the other question: have a look at BouncyCastle - java itself can't handle those kind of files itself pretty well
4 years ago
check the document root of apache - default is /srv/www/htdocs
4 years ago
PHP
Well, it would be helpful if all those trolling around "Are you mean the String object or the reference?" would just stop that crap - that isn't helpful at all in any way - and already caused more confusion to OP ...

Back to topic:

@Krish Krishnan
To explain what happens here I have you have to understand how methods (oh, yea, side-note: to all called it "variable" - it's called reference - end of story - same like it's called method instead of function - jeez o.0) without side-effects work.
On the 2nd line you have "a" - wich points to the String "abc" - and call the method "toUppercase()" on it. This method, instead of modifying the String a references (as they're immutable), it returns a new String with the new modified content. To even have any effect you have to store this new String anywhere. If line 2 would only look like a.toUppercase() actually nothin really would happen as the new String is just thrown away (so it's likely to get optimized out).
Back to the basics: To even call a method you either need a class (when it's a static method) or an object (when it's an instances method). So, why does method chaining work? By the previous method returning some object the next method can be called on. So, let's unroll the chain:

So, I guess you understand what happens here: You first have the original b, reference to "ABC", then you first call the first replce on it wich returns a new String now contain "A2C" - wich you store back into b so you override it. Next, you take that new overridden String "A2C" and call the second replace on it resulting finally in "A23" wich then gets stored back in b overriding the intermediate "A2C" with the final "A23".
What makes method chaining different? Nothin at all! It exactly the same - just in a compressed way. Instead of storing each intermediate step seperately you "chain them together" - hence its name "method chaining".

Another example:
"C".concat("o").concat("d").concat("e").concat("r").concat("a").concat("n").concat("c").concat("h") is the very same as "C"+"o"+"d"+"e"+"r"+"a"+"n"+"c"+"h" - it's a chained concatenation of String to form the final result "Coderanch" - but instead of rely upon the special meaning of the "+" operator the concatenate Strings you use the concat() method. The above example could also be written as:

Or like this:

If you may familiar with the term "loop unrolling" - it's kinda like it's opposite: You shrink down multiple lines of code into one.
4 years ago