Java questions which don't deserve their own thread, yet.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.

«‹›303 »

PierreTheMime: Dec 9, 2004; Hero of hormagaunts everywhere!; Buglord

Zaphod42 posted:

Writing them separately is pretty much fine and you shouldn't try to overthink it.

That said, logical short-circuiting works pretty drat well here.
code:
If(obj != null && ! obj.getReadOnlyMode()){

//do stuff

}
else{
//handle null/read-only state
}
This works because in an if() clause, if you require logical AND the computer knows that as soon as it sees a 'false' the overall result will be False. False AND X where X is anything returns False. So the Java engine doesn't even bother calculating the rest of the clause, so it never calls obj.getReadOnlyMode();

The same thing works on OR, but in reverse. With OR as soon as it sees a true value it short-circuits since TRUE OR X always yields True.

But that's just fancy syntactic sugar really to make the code simple, you don't need it. There is *nothing* wrong with this:
code:
if(obj != null){
  if(obj.getReadOnlyMode()){
//handle read only
}
else{
//handle object
}
}
else{
// handle null
}
You just don't want the two of them on the same level. If you do if(obj != null) and if(obj.getReadOnlyMode()) then the second will NPE on the null condition. You either need to nest the second check inside the check for null, or you need to inline them as part of the same clause.

Thanks, I really appreciate the input. I'll rewrite it to be more sensible. As a fun quick-fix while I was waited I just coded a single condition and a try/catch for the NPE which also processes the "success" condition but I appreciate knowing the "logical short circuit" option.

# ? Dec 6, 2016 01:59

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 15:05

Paul MaudDib: May 3, 2006; TEAM NVIDIA:
FORUM POLICE

Zaphod42 posted:

I find doing that is a huge pain in the butt compared to just dropping libs in a "libs" dir though.

What I'd really prefer to Maven would be a system where you have a libs dir and then Maven just automatically downloads and places libs into the libs dir based on dependencies. Any files that were not part of the Maven POM file would be ignored in the libs dir, so you could have your own libraries that Maven doesn't know about, but Maven would also pull things for you automatically and replace the old versions, more like a package manager. Then you'd have a totally portable folder that can compile without Maven. Make it more of a setup tool. My problem is that Maven itself ends up becoming a dependency that anybody who wants to deal with your project has to deal with. I really love being able to just rip a lib from an FTP site and compile right away without having to edit POM files.

From Maven's perspective, the problem is that it doesn't go around including a bunch of JARs "just because". If that repository was, say, Maven-Central, then including everything could be tens of thousands of JARs, probably a whole bunch of which are incompatible. From Maven's perspective, a local repository is simply one that it happens to access over file:// instead of http://. There is no other difference. Note that that this is different from your Maven cache, which is usually in the C:\Users\{username}\.m2 directory and is not shared between people..

Even if you just had a limited dir that you wanted it to include - it has no idea what is actually in that directory and what scope they should be included in (build, test, provided, etc). The point of running "mvn install:install-file" is that you give it the metadata of "what this JAR is" so it can write it into the repository directory you give, so that when it goes to grab dependencies it knows that this one is what it should include for "ojdbc-12.0.2.15". It would be super great if this were standardized but Java is the Land Of 1000 standards and walking thousands of jars would not be efficient anyway.

Other than that, "be a package manager" is exactly what Maven does. The point is that you can clone a Git repo, click "build", and it will automagically pull whatever it needs to build and assuming the build worked for the other guy then everything should succeed. You can put a local repository inside the repository for anything that cannot be pulled via Maven-Central, and then address it like - "${project.basedir}/../lib/". Then once again we're back to "git clone and build". Or if you have sub-projects you can set up a multimodule project, although in my opinion this isn't handled the most gracefully.

Gradle does that too of course, but it's imperative rather than declarative. And imperative is harder for other programs to handle, so most IDEs won't pick it up automatically. It's the equivalent of a makefile, it's its own little programming language, whereas Maven is literally "here is the things you should include to build this project" which also happens to be what the IDE needs to include.

quote:

That's great for the big heavyweight stuff with lots of dependencies and versions, but for some small lightweight libs its super overkill and takes too long to get going.

The problem in Java is traditionally that even simple projects swell to encompass a whole bunch of stuff via transitive dependencies. You may only use one lib, but if it starts including a bunch of other stuff then that has to be on the classpath too.

Logging frameworks are sort of a great example of this. Pretty much any project that relies on external libraries for anything will eventually swell to encompass Java.Util.Logging, Jakarta Commons Logging, Log4J, SLF4J, etc. Then at the final application, you use a "bridge" which routes all the different logging APIs to a single logging implementation.

It's really best to just stick to Apache-Commons libraries to try and minimize the amount of dependency bloat. They have pretty much anything you will ever need. SLF4J is pretty much the One Logging Framework To Rule Them All, too.

quote:

I don't know why they don't just build that as a feature into Maven, even. "Maven copy dependencies" would build a libs dir or something to that effect. But I guess its kinda anathema to Maven's mentality, so it'd have to be some other software to offer that kinda approach.

That option actually exists - you can have Maven build a "fat JAR" with dependencies right into it using maven-assembly-plugin. Or you should be able to just build a libs dir too somehow - I don't know how off the top of my head, but I 100% guarantee someone has done that.

edit: here you go

Paul MaudDib fucked around with this message at 02:51 on Dec 6, 2016

# ? Dec 6, 2016 02:32

geeves: Sep 16, 2004

Paul MaudDib posted:

It's really best to just stick to Apache-Commons libraries to try and minimize the amount of dependency bloat. They have pretty much anything you will ever need. SLF4J is pretty much the One Logging Framework To Rule Them All, too.

I've never really sought a reason to go beyond Log4J - I used SLF4J in a handful of projects because they were already there, but never really noticed any different at all between the two. Granted it was all basic logging. But Nobody has ever said, you're missing out because SLF4J does THIS!

# ? Dec 6, 2016 04:59

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Zaphod42 posted:

I find doing that is a huge pain in the butt compared to just dropping libs in a "libs" dir though.

What I'd really prefer to Maven would be a system where you have a libs dir and then Maven just automatically downloads and places libs into the libs dir based on dependencies. Any files that were not part of the Maven POM file would be ignored in the libs dir, so you could have your own libraries that Maven doesn't know about, but Maven would also pull things for you automatically and replace the old versions, more like a package manager. Then you'd have a totally portable folder that can compile without Maven. Make it more of a setup tool. My problem is that Maven itself ends up becoming a dependency that anybody who wants to deal with your project has to deal with. I really love being able to just rip a lib from an FTP site and compile right away without having to edit POM files. That's great for the big heavyweight stuff with lots of dependencies and versions, but for some small lightweight libs its super overkill and takes too long to get going.

I don't know why they don't just build that as a feature into Maven, even. "Maven copy dependencies" would build a libs dir or something to that effect. But I guess its kinda anathema to Maven's mentality, so it'd have to be some other software to offer that kinda approach.

Sounds like you want Gradle. You keep your non standard libraries local as needed. If you work anywhere where you're maintaining multiple projects with different requirements, you're gonna want something like Maven or Gradle. You can't assume anyone coming in is going to have the same libraries in a folder as you. That runs dangerously close to the "works on my machine" issues.

# ? Dec 6, 2016 06:12

BabyFur Denny: Mar 18, 2003

Don't be that guy that needs you to jump through 50 hoops to get his stuff built.
If your stuff doesn't build with a simple gradle build or mvn install then it's not ready for production. And no, those extra libs don't belong in your source code repository. Also lol @ just grabbing a lib from some FTP sites. Best way to get your system compromised.
If it's not part of maven central or your internal artifactory, it's not a library worth being used.

# ? Dec 6, 2016 09:35

Boz0r: Sep 7, 2006; The Rocketship in action.

Jabor posted:

It sounds like if you distribute the work appropriately (so that two threads aren't going to process the same data), then everything just works?

This is true, but I can't guarantee that. I didn't write the processing part, I'm just trying to fix the non-functioning concurrency stuff.

Volguus posted:

From your example everything looks to be more complicated than it needs to be. If you would have ConcurrentHashMap<Integer, AtomicInteger> you can get rid off synchronized, Sempahore and ... pretty much everything else. Can simply put into the map and increment the key when needed without worries.
But, the first question is : do you have to mutate the same object from multiple threads? Can you do without?

The Integer in my map just represents the real data objects in my test system, so I can't use AtomicInteger. Again, I can't guarantee that multiple threads need to mutate the same data.

I realize that this is terrible design, but it's out of my hands.

# ? Dec 6, 2016 09:52

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Paul MaudDib posted:

Also, as much as Maven has its bugs, at least it's not so slow that it needs to live as a resident daemon

Yeah, I checked out a Minecraft mod and it used Gradle. Fine, whatever, just enable Gradle support in Idea. Import gradle project and... it takes 2 hours to resolve the dependencies. :wtc:

# ? Dec 6, 2016 10:26

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Zaphod42 posted:

What I'd really prefer to Maven would be a system where you have a libs dir and then Maven just automatically downloads and places libs into the libs dir based on dependencies.

That's what the .m2 directory under your home directory is.

# ? Dec 6, 2016 10:33

pigdog: Apr 23, 2004; by Smythe

geeves posted:

I've never really sought a reason to go beyond Log4J - I used SLF4J in a handful of projects because they were already there, but never really noticed any different at all between the two. Granted it was all basic logging. But Nobody has ever said, you're missing out because SLF4J does THIS!

SLF4J is the best option because it allows you to change the logging framework at deployment time. Say your company puts together a fancy log storage and analysis stack that unfortunately only works with Logback, or log4j. By targeting slf4j you can choose and switch logging framework at deployment, so you don't need to change the app itself to suit the ecosystem.

# ? Dec 6, 2016 11:14

Volguus: Mar 3, 2009

Boz0r posted:

This is true, but I can't guarantee that. I didn't write the processing part, I'm just trying to fix the non-functioning concurrency stuff.

The Integer in my map just represents the real data objects in my test system, so I can't use AtomicInteger. Again, I can't guarantee that multiple threads need to mutate the same data.

I realize that this is terrible design, but it's out of my hands.

OK, fine, but anyway you look at it the code is simply ... not ok. You have too many "synchronized" keywords in there. What for? Use one, to synchronize the actual object mutation (which you want to prevent from being mutated by multiple threads at the same time). There's no need for Locker, nor Sempahore. And, oh, by the way, the double-checked locking idiom that you have in Locker is wrong.

And you asked earlier about WeakHashMap. Sure you can use it, if you understand what it does and how to use it. From the example code you posted it doesn't look like it will help you at all. If you hope that you will avoid object mutation from multiple threads by using weak-pointers, you would be wrong.
Some pointers:

As a general rule when dealing with multiple threads, try to avoid using mutexes (synchronized). Try not to share objects. If you have to share, try to use atomics (atomic reference for example). Make use of the utilities found in java.util.concurrent
If you have to share objects and cannot use atomics, sure, use mutexes. However, try to limit their use to the point of mutation. If you find yourself peppering your code with synchronized keywords, something is wrong. Fix your code, you shouldnt have to do that
In general, avoid singletons. They are an abused pattern that usually tries to hide their real self: global variables. There are use-cases for singletons, but very few and very far in-between. Usually, you don't need it. If you think you do, convince yourself out of it.
When using utilities from java.util.concurrent read the documentation. Carefully. Then read it again. Very carefully. ConcurrentHashMap does not need synchronization. That's the entire point of it, otherwise you're fine using a normal HashMap.
You seem to try to "test" for race conditions. You can't/don't "test" for race conditions. You prove that theoretically race conditions cannot happen in your algorithm. Sure, have a unit test, but that doesn't do anything except test the result. If theoretically a race condition can happen, it will happen, just not for the first 100 executions of the code.

# ? Dec 6, 2016 14:09

TheresaJayne: Jul 1, 2011

Paul MaudDib posted:

The nice thing about Maven is it is declarative though - which makes it trivial to use as an IDE-agnostic project file. Literally any IDE can look at a POM file and spit out a working project, so you can just go ahead and git-ignore all IDE-specific project files from the repo forever and never worry about project files getting out of date or that one idiot who just can't help but check them in every single time clobbering your project config updates.

If you still want to have your "libs" dir that can build the whole app without any dependency downloads, you can still do that by installing everything into a local repository and naming it in your POM file. Ideally you will give the path relative to ${project.basedir} for portability. You pretty much need to do this for some stuff anyway, like the Oracle OJDBC drivers or some of the Java EE JARs that aren't in Maven-Central due to licensing concerns. This applies to Gradle too of course.

Also, as much as Maven has its bugs, at least it's not so slow that it needs to live as a resident daemon

Sorry, Gradle is better than maven,.

I worked on a project with 350 connected projects.

Maven compile and build always took 90+ minutes

Gradle full build including tests 15 minutes (5 if you had recently built it) - and this is not using the daemon

This was on an airgapped system and we had a copy of the files we needed in a global repo on the network that Both Gradle and Maven used.

TheresaJayne fucked around with this message at 14:18 on Dec 6, 2016

# ? Dec 6, 2016 14:15

CPColin: Sep 9, 2003; Big ol' smile.

Volguus posted:

And, oh, by the way, the double-checked locking idiom that you have in Locker is wrong.

As that article says, only before Java 5 and only if you leave out the volatile keyword.

# ? Dec 6, 2016 16:23

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Wheany posted:

Yeah, I checked out a Minecraft mod and it used Gradle. Fine, whatever, just enable Gradle support in Idea. Import gradle project and... it takes 2 hours to resolve the dependencies.

This is not typical. I'm guessing that mod has repositories pointing all over the internet with slow connection speeds.

# ? Dec 6, 2016 17:22

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Wheany posted:

That's what the .m2 directory under your home directory is.

Or the .gradle directory under your home directory if you're using gradle.

# ? Dec 6, 2016 17:23

Volguus: Mar 3, 2009

CPColin posted:

As that article says, only before Java 5 and only if you leave out the volatile keyword.

That's certainly correct. However, the volatile keyword is quite essential after 1.5.

# ? Dec 6, 2016 17:58

pigdog: Apr 23, 2004; by Smythe

TheresaJayne posted:

Sorry, Gradle is better than maven,.

I worked on a project with 350 connected projects.

Maven compile and build always took 90+ minutes

Gradle full build including tests 15 minutes (5 if you had recently built it) - and this is not using the daemon

This was on an airgapped system and we had a copy of the files we needed in a global repo on the network that Both Gradle and Maven used.

Being smarter about the build process, and being able to more accurately deduce which parts of the project have changed, is definitely an upside of Gradle.

But, man, with 90 minute build times you really should reconsider what you're doing. Break it down to microservices, or just start enforcing modularity (which is like microservices but within a single JVM :eyepop:

# ? Dec 6, 2016 18:03

TheresaJayne: Jul 1, 2011

pigdog posted:

Being smarter about the build process, and being able to more accurately deduce which parts of the project have changed, is definitely an upside of Gradle.

But, man, with 90 minute build times you really should reconsider what you're doing. Break it down to microservices, or just start enforcing modularity (which is like microservices but within a single JVM ).

I am no longer working on that project but it was Control software for satellites

# ? Dec 6, 2016 18:17

HFX: Nov 29, 2004

pigdog posted:

Being smarter about the build process, and being able to more accurately deduce which parts of the project have changed, is definitely an upside of Gradle.

But, man, with 90 minute build times you really should reconsider what you're doing. Break it down to microservices, or just start enforcing modularity (which is like microservices but within a single JVM ).

I have seen 90 minute builds. Usually it involves integration test cases (which people may mistakenly label unit tests). I usually start by splitting them out to a test that only runs once a week.

# ? Dec 6, 2016 20:10

Jo: Jan 24, 2005; Soiled Meat

Would this be the place to talk about Kotlin? I recently stumbled upon the language and have taken a liking to it. Do we have a JVM languages thread?

# ? Dec 6, 2016 21:35

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Jo posted:

Would this be the place to talk about Kotlin? I recently stumbled upon the language and have taken a liking to it. Do we have a JVM languages thread?

I don't know poo poo about Kotlin or Scala besides the fact that they don't do anything that Groovy doesn't already do and the syntax looks like rear end.

# ? Dec 6, 2016 22:01

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

geeves posted:

I've never really sought a reason to go beyond Log4J - I used SLF4J in a handful of projects because they were already there, but never really noticed any different at all between the two. Granted it was all basic logging. But Nobody has ever said, you're missing out because SLF4J does THIS!

I think the biggest feature of SLF4J is the placeholders in the log messages which log4j and java.util.logging lack. Also it really makes it easy to bridge all the other weird poo poo that other dependencies need and force them to your final destination logger of choice.

I have a project that included libs which have hard transitive dependencies on JCL, JBoss Logging, Log4j, Log4j2 and SLF4J, it would be a nightmare to manage if it wasn't for the SLF4J facades. I was able to stub out all that bullshit in my POM, provide the facades to satisfy their runtime requirements and have it all just go to my logback implementation through SLF4J, it owns.

# ? Dec 7, 2016 00:55

Jo: Jan 24, 2005; Soiled Meat

poemdexter posted:

I don't know poo poo about Kotlin or Scala besides the fact that they don't do anything that Groovy doesn't already do and the syntax looks like rear end.

I'm coming up for a breather from Rust and Python, so the syntax is pretty cozy for me. Of the JVM languages I've tried so far (Scala, Clojure, and Groovy), it's my favorite. Clojure is a close second, though, so take that with a grain of salt. :v:

# ? Dec 7, 2016 04:18

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Paul MaudDib posted:

That option actually exists - you can have Maven build a "fat JAR" with dependencies right into it using maven-assembly-plugin. Or you should be able to just build a libs dir too somehow - I don't know how off the top of my head, but I 100% guarantee someone has done that.

edit: here you go

I don't want it in a compiled jar though; I want to just have a folder with the loose libraries for building with without Maven in the future.

But that's pretty close and worst case I could always rip the libs out lol. Cool read, thanks.

I'm aware of the local repo but you have to add things to the local repo first, and then it stores them in its own directory. That's efficient so you don't have tons of copies of the same library all needing to be copied around and updated, but I just would really like to be able to like detach from Maven at will and create a portable source zip. But like I said that's just kinda backwards to the whole mentality of how Maven is designed to be used.

BabyFur Denny posted:

Don't be that guy that needs you to jump through 50 hoops to get his stuff built.
If your stuff doesn't build with a simple gradle build or mvn install then it's not ready for production. And no, those extra libs don't belong in your source code repository. Also lol @ just grabbing a lib from some FTP sites. Best way to get your system compromised.
If it's not part of maven central or your internal artifactory, it's not a library worth being used.

But my point is even having to add things to an internal artifactory is overkill for some applications. If I'm just rolling up a quick dumb application for fun that I'm going to delete tomorrow, or if its some high school student project that's never going to be maintained or updated or something, situations like that it ends up being a hassle. Like you could write a bash script to accomplish some quick task, but what if you just wanna do java real quick?

My entire point is that you shouldn't have to jump through so many hoops to get stuff built! That's exactly what I'm trying to accomplish. For complex business software maven makes it easier to build and deploy, but for really simple one-off projects or student learning projects its a huge initial burden before you can even compile and run a single test.

If you're scared of your system being compromised you can use SSL, checksums, and virus scans.

Wheany posted:

That's what the .m2 directory under your home directory is.

That's for all libraries for the machine, right? I'm saying I want a directory with just a single project's needed dependencies.

Its not a big deal though just a gripe. There's probably tools I should use to make deploying your own libraries into Maven and configuring a POM to use them much more painless.

I'm really just salty because a project I use switched over to gradle after not requiring it for a long time and it was a real pain to reconfigure the project and get everything in the right form that it could build.

Zaphod42 fucked around with this message at 07:13 on Dec 7, 2016

# ? Dec 7, 2016 06:59

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Zaphod42 posted:

I don't want it in a compiled jar though; I want to just have a folder with the loose libraries for building with without Maven in the future.

But that's pretty close and worst case I could always rip the libs out lol. Cool read, thanks.

I'm aware of the local repo but you have to add things to the local repo first, and then it stores them in its own directory. That's efficient so you don't have tons of copies of the same library all needing to be copied around and updated, but I just would really like to be able to like detach from Maven at will and create a portable source zip. But like I said that's just kinda backwards to the whole mentality of how Maven is designed to be used.

But my point is even having to add things to an internal artifactory is overkill for some applications. If I'm just rolling up a quick dumb application for fun that I'm going to delete tomorrow, or if its some high school student project that's never going to be maintained or updated or something, situations like that it ends up being a hassle. Like you could write a bash script to accomplish some quick task, but what if you just wanna do java real quick?

My entire point is that you shouldn't have to jump through so many hoops to get stuff built! That's exactly what I'm trying to accomplish. For complex business software maven makes it easier to build and deploy, but for really simple one-off projects or student learning projects its a huge initial burden before you can even compile and run a single test.

If you're scared of your system being compromised you can use SSL, checksums, and virus scans.

That's for all libraries for the machine, right? I'm saying I want a directory with just a single project's needed dependencies.

Its not a big deal though just a gripe. There's probably tools I should use to make deploying your own libraries into Maven and configuring a POM to use them much more painless.

I'm really just salty because a project I use switched over to gradle after not requiring it for a long time and it was a real pain to reconfigure the project and get everything in the right form that it could build.

I'm not sure what libraries you need to download and put in a folder that aren't already on mavenCentral or jCenter. Imagine for a second that you have one additional file in your project that lists all the things you want. Now imagine there's a single command to download all the things you want and build your jar. Now imagine that someone can clone your git repo or unzip your source (lol) and run that same command and get the exact same outcome as you did on your own machine. That's gradle and/or maven.

If you're just doing Java to dick around and you don't think anyone will ever touch your source code and you don't think you'll write anything worth sharing, then go ahead and download jars manually and add them to your classpath. Even for one off projects and hackathons, I still find gradle is easier than going and downloading libraries and adding them to projects manually. There's a reason why other languages have package managers tied to them.

Seriously, check this: https://gist.github.com/poemdexter/6cb747368e34992ea6e0aeb386981259

code:

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
  compile 'com.google.guava:guava:20.0'
  testCompile 'junit:junit:4.12'
}

Now if you have gradle installed, all you have to do is:

code:

gradle build

and now those libraries are linked to your project and a jar was built. Now I can do fancy guava stuffs and even test my code and I didn't have to go all over the internet hunting for jars!

poemdexter fucked around with this message at 10:16 on Dec 7, 2016

# ? Dec 7, 2016 10:07

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Zaphod42 posted:

That's for all libraries for the machine, right? I'm saying I want a directory with just a single project's needed dependencies.

But why?

# ? Dec 7, 2016 10:53

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

Wheany posted:

But why?

Because he hates having an external dependency on maven :shrug:

# ? Dec 8, 2016 05:47

Volguus: Mar 3, 2009

Janitor Prime posted:

Because he hates having an external dependency on maven

If you have a Makefile you have an external dependency on make.
If you have a build.xml file you have an external dependency on ant.
If you have an IDE project file you have an external dependency on that IDE.

It just never ends and it's a nightmare.

# ? Dec 8, 2016 05:53

TheresaJayne: Jul 1, 2011

Volguus posted:

If you have a Makefile you have an external dependency on make.
If you have a build.xml file you have an external dependency on ant.
If you have an IDE project file you have an external dependency on that IDE.

It just never ends and it's a nightmare.

build.xml is Gradle

ant is buildfile

# ? Dec 8, 2016 08:59

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

TheresaJayne posted:

build.xml is Gradle

ant is buildfile

build.gradle is Gradle.

Volguus posted:

If you have a Makefile you have an external dependency on make.
If you have a build.xml file you have an external dependency on ant.
If you have an IDE project file you have an external dependency on that IDE.

It just never ends and it's a nightmare.

Yes, the solution is never build a project ever.

# ? Dec 8, 2016 11:21

HFX: Nov 29, 2004

Janitor Prime posted:

I think the biggest feature of SLF4J is the placeholders in the log messages which log4j and java.util.logging lack. Also it really makes it easy to bridge all the other weird poo poo that other dependencies need and force them to your final destination logger of choice.

I have a project that included libs which have hard transitive dependencies on JCL, JBoss Logging, Log4j, Log4j2 and SLF4J, it would be a nightmare to manage if it wasn't for the SLF4J facades. I was able to stub out all that bullshit in my POM, provide the facades to satisfy their runtime requirements and have it all just go to my logback implementation through SLF4J, it owns.

While I still typically deal with SLF4J, Log4j2 provides the ability to deal with most other logging frameworks through bridges. It also does a bit better at not generating garbage for messages which are not going to print. It also has a bit better performance than Logback while having several configuration features that I can't find in Logback. I also don't have to deal with the random installation where Logback doesn't roll the files properly. Finally, I don't have to put a special entry in a weblogic.xml file to make sure that the correct SLF4J entry is used.

# ? Dec 8, 2016 18:37

Volguus: Mar 3, 2009

HFX posted:

While I still typically deal with SLF4J, Log4j2 provides the ability to deal with most other logging frameworks through bridges. It also does a bit better at not generating garbage for messages which are not going to print. It also has a bit better performance than Logback while having several configuration features that I can't find in Logback. I also don't have to deal with the random installation where Logback doesn't roll the files properly. Finally, I don't have to put a special entry in a weblogic.xml file to make sure that the correct SLF4J entry is used.

Oh hey, Log4j is back from the dead, had no idea. I've long abandoned the dead log4j project in favor of logback, but if it's alive and kicking again I'll certainly consider it. Using SLF4J certainly makes the switch painless.

# ? Dec 8, 2016 19:45

Janitor Prime: Jan 22, 2004; PC LOAD LETTER

What da fuck does that mean; Fun Shoe

Yeah log4j2 is the new hotness and it's quite nice. I just have the infrastructure tied around logback and I need a new project to migrate to log4j2 since it is actually better like HFX mentioned and it's license is more flexible in management's point of view (LGPL vs Apache).

# ? Dec 8, 2016 20:10

HFX: Nov 29, 2004

Janitor Prime posted:

Yeah log4j2 is the new hotness and it's quite nice. I just have the infrastructure tied around logback and I need a new project to migrate to log4j2 since it is actually better like HFX mentioned and it's license is more flexible in management's point of view (LGPL vs Apache).

The license issue is what initially made me have to look into the change. Companies are terrified of anything GPL including the LGPL. How we manage to run on Linux with that terror I have no idea.

Edit due to question coming up:

In an application we use JPA and an eclipse-link provider. We have a persistence.xml file which contains a password to a test environment since we have a number of junit tests which are integration tests. This file is never deployed to any environment and is strictly used during a promotion build process to ensure we didn't break anything dealing with the database. Unfortunately, the security scans are flagging on the word password. Thus, I'm being told I need to find a way to obscure the password. Does anyone know how to obscure the password when using a persistence.xml file to allow unit testing?

HFX fucked around with this message at 22:44 on Dec 8, 2016

# ? Dec 8, 2016 22:17

Volguus: Mar 3, 2009

HFX posted:

The license issue is what initially made me have to look into the change. Companies are terrified of anything GPL including the LGPL. How we manage to run on Linux with that terror I have no idea.

Edit due to question coming up:

In an application we use JPA and an eclipse-link provider. We have a persistence.xml file which contains a password to a test environment since we have a number of junit tests which are integration tests. This file is never deployed to any environment and is strictly used during a promotion build process to ensure we didn't break anything dealing with the database. Unfortunately, the security scans are flagging on the word password. Thus, I'm being told I need to find a way to obscure the password. Does anyone know how to obscure the password when using a persistence.xml file to allow unit testing?

Why do you have passwords in persistence.xml? Why don't you point to an jndi resource, which can and should be provided by the application server? JNDI resources can also be created for test environments, integration tests and other things.

# ? Dec 8, 2016 22:58

HFX: Nov 29, 2004

Volguus posted:

Why do you have passwords in persistence.xml? Why don't you point to an jndi resource, which can and should be provided by the application server? JNDI resources can also be created for test environments, integration tests and other things.

I do that in any actual web container environments (dev, qa, uat, etc). However, this file is used when doing unit tests through a Jenkins build job.

# ? Dec 8, 2016 23:11

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

A lot of configs use the word "password" for fields. I think you might need to lower your security settings on that one because it's not like you can go and change the external libraries to start using a different word.

# ? Dec 8, 2016 23:29

Paul MaudDib: May 3, 2006; TEAM NVIDIA:
FORUM POLICE

poemdexter posted:

A lot of configs use the word "password" for fields. I think you might need to lower your security settings on that one because it's not like you can go and change the external libraries to start using a different word.

I guess you could walk the fields of the properties object and build another properties object using the rot13 values of the field names, then feed that to the factory or whatever builds the connection pool.

# ? Dec 9, 2016 01:58

Volguus: Mar 3, 2009

HFX posted:

I do that in any actual web container environments (dev, qa, uat, etc). However, this file is used when doing unit tests through a Jenkins build job.

Sure, and in unit tests you can provide a dummy jndi resource and the persistence.xml doesn't even need to be changed (or different) from qa or production ones.

# ? Dec 9, 2016 03:15

AbrahamLincolnLog: Oct 1, 2014; Note to self: This one's the shitty one

So, I'm going to preface this with the point that this is potentially a very dumb question, but I have to be honest and say that I'm just totally stumped.

Yesterday I logged into my COP 2805 online class to see my final assignment. The instructions are as follows:

quote:

Use the ComplexClass class attached to develop the ComplexMatrix class for performing matrix operations involving complex numbers. The ComplexMatrix class should extend the GenericMatrix class and implement the add, multiple, and zero methods. You need to modify GenericMatrix and replace every occurrence of Number by object, because ComplexClass is not a subtype of Number. Write a test program that creates the following tow matrices and displays the result of additions and multiplication of the matrices by invoking the printResult method.

The assignment comes with a ComplexClass.java which is all fine and dandy. But where the gently caress do I get GenericMatrix from? There's no GenericMatrix class in the given files; attempting to just extend it gives me a "class not found error" (obviously). With some extensive googling, all I've found is people who have had the exact same assignment, with one catch: they're all using a different textbook, which included code for a GenericMatrix class. My textbook is an e-book and I've searched it for "GenericMatrix" and there's no results. As far as I can tell, my professor has ripped this assignment out of another text book that we aren't using and only included part of the code.

Am I missing something? Is there a GenericMatrix in Java somewhere, and I'm just missing it (or are too dumb to know how to import it)? The rest I can kind of figure out, but I have no idea where I'm supposed to be getting this GenericMatrix stuff from, and I wanted to double check to see if I was just loving up, or if I'm right and I'm missing part of the assignment.

Big thanks in advance for any help. My grade is high enough that I should still get a B if I "fail" the final, but I'd rather keep the A.

AbrahamLincolnLog fucked around with this message at 08:26 on Dec 14, 2016

# ? Dec 14, 2016 08:23

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 15:05

Jo: Jan 24, 2005; Soiled Meat

AbrahamLincolnLog posted:

... As far as I can tell, my professor has ripped this assignment... The rest I can kind of figure out, but I have no idea where I'm supposed to be getting this GenericMatrix stuff from, and I wanted to double check to see if I was just loving up, or if I'm right and I'm missing part of the assignment.

I can see this happening and advise strongly in asking your professor if he's hosting the missing file somewhere. Email him NOW and CC a TA.

# ? Dec 14, 2016 08:28

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.

«‹›303 »