Page 17 of 22 FirstFirst ... 7131415161718192021 ... LastLast
Results 161 to 170 of 211

  Click here to go to the first Developer post in this thread.  

Thread: Take On Java

  1. #161

  2. #162
    Quote Originally Posted by Slapstick View Post
    I am not familiar with JRuby, do you need to instantiate a ScriptEngineManager to run Ruby scripts? Can't you compile the Ruby scripts into .class files? Using SQF to load a Java class that instantiates a scripting engine to run a Ruby script does seem a bit excessive. You need something that can compile directly into real JVM .class files... I'm not sure JRuby is it...
    It depends on the goal, yes. My idea was, for rapid prototyping, having the bare .rb scripts being directly executed seemed like the "fasted way" (but as we gave an overfew of the call chain, probably not something you would want to do in "production" ;-) ). JRuby can compile to pure .class files fine, I just haven't explored this yet.
    System: CPU: i7-980X, RAM: 12GB Kingston HyperX, GFX: XFX Radeon HD 5970 Black Edition, MOBO: GA-X58A-UD7 X58, POWER: be quiet P8 1200W ATX 2.3, HDD: 2x Intel X25-M G2 160GB, 2.5", OS: W7Pro 64bit, Drivers: Catalyst: 13.12, 2D: 8.01.01.1360, D3D: 9.14.10.01001, OGL: 6.14.10.12618, CCC: 2013.1206.1603.28764

  3. #163
    Hi guys. For those in the middle of learning: Treat anybody who's recommending Maven to you as your enemy. Seriously get away from this piece of crap as far as you can. I know what I'm talking about. It's just another big hype in Java world, something like XML, ... or Java. But this one is worst. If you really need to manage dependencies (you don't) look at Gradle. Ant will do fine (though it's crap too). I'm outta here.

  4. #164
    Master Sergeant Serclaes's Avatar
    Join Date
    Nov 27 2005
    Location
    this town right here
    Posts
    775
    Right. He's not the messiah, I'm the messiah?

    Would you care to elaborate why exactly Gradle is so much better than Maven? Since you obviously have vast experience with both...

  5. #165
    Hello. This would result in flame war and it doesn't fit here. So look at comments here please http://tapestryjava.blogspot.com/200...led-again.html (I actually got to this page after googling "mave piece of shit", I do it quite frequently). I laugh at all of you maven-piece-of-crap lovers. I love the motto of your ultimate-xml-driven-tool: "convention over configuration" ... which is totally wrong because there is no option for configuration. I love when asking on forum/ml about how to do something that would be easily done with 1 line in some script and they reply you-re-doing-it-wrong-way-do-it-maven-way(r). Unfortunately I had to use it at my job. No security (man in the middle on LAN is very easy), no parallel executions, full of bugs, XML programming, ... I'm outta here (now for real!).

  6. #166
    Quote Originally Posted by Slapstick View Post
    This is NOT the best/proper way to set up a Java project. The example on the wiki simply shows how to get Eclipse, Java and TOH working together. Mashing code, class files, Eclipse project files and the TOH mission files all into the same directory is likely a Bad Idea. It will likely take a while for some "Best Practices" to emerge, but keeping the sources separate from the binaries is always a Good Idea, simply so people can choose to take one or the other and are not forced to take both.
    All the files mentioned in the mission directory is how the result looks. The class files and toh mission file(s) have to go together, since it will only read them from that directory*; when you pbo it all up, it'll have to be part of the mission.

    * It may be that jload will accept paths, so you could have a separate classes subdir in the mission dir. I haven't tested this possibility.

    "keeping the sources separate from the binaries is always a Good Idea, simply so people can choose to take one or the other"
    Sort by file type, select the approximate half that is .class or .java depending on what you want, press delete. Though I acknowledge that is 1 to 2 clicks more than if they're in a separate directory. It's even simpler from a command line.

    And while Open Source is nice, if someone just wants to distribute the binary (.class/.jar) files without the source does it really matter? Do you read the Eclipse source code when using Eclipse?. Of course, the binary still needs to be distributed under a "free to use" license, but I would rather have a free to use closed source binary than open source code with a GPL license. In fact, I would prefer to have a well documented Jar file in a Maven repository than either of the above.
    1) Pre-built binaries are fine - as long as they're suitable for whatever ones needs are. But every so often you just need a slight change for it to be good for your uses. If you don't have the sources, you have to discard it completely; it may as well be useless junk.
    In SQF, there's practically no scripts that don't need modification to work outside of the narrow use case the writer had for it. If your use case is a good enough match, good for you. If not, sqf allows you to modify it.
    Another effect we have from sqf being source-only is that people can look at your code, and tell you exactly what line needs to be changed to fix a bug.


    2) Learners - those learning java, or just how to use RVE from java, will be looking at code. Especially if they want a similar effect, but still different.
    If you have hidden that code, you won't be getting what missions and mods they would have produced.
    If, back during cold war crisis, sqs had been a pre-compiled language without sources provided, arma1 probably wouldn't have happened.

    FWIW, there are arma2 missions under GPL. Like the one most played, ever. Especially if you include its arma1 versions. A lot of mission makers started their "careers" by modifying domination.

    So yes, it matters a lot. As long as you're in it for the long term.

    My threads can... although my testing with threads has simply been to start one thread that calls RVEngine.hint every second, and another thread that kills the first thread after a few minutes. It is not exactly a stress test, but I haven't run into any problems starting threads or having them interact with RVEngine.
    My threads have all crashed after anywhere from 1 to 450000 RVEngine calls. This is a race condition problem, which means it will fail sooner or later, even if it's always worked for you while you were testing it. You're free to call RVEngine functions when the game is stopped for a jcall - at least as long as no other thread is calling one of them. Outside of that window, we basically have no guarantees, and we're observing crashes. If all a thread does is call hint once and then exit, then that too seems to fall into "incorrect" behavior that may cause a crash; It may not start running until the jcalled function returns, and at that point the game engine can be all over the relevant stuff. Some functions will be lower risk then others by nature of what they do, but all must be considered risky at this time.

    The RVEngine functions seem to "yield" just fine, just don't do anything that blocks.
    By yield, I mean pausing the calling java code to do other stuff like sqf code; such that when a function returns, the game state can be radically different from before it was called. That's definitely an issue with sqf today, the question was if java was immune to it. If it's not, you need to make sure all jcall-able functions are reentrant too. I can tell you that RVEngine.Sleep() is effectively a no-op, and yielding is its purpose in life, so I think the "does not yield" assumption is safe for the time being. Not that I'd rely too much on it even so.
    Last edited by MaHuJa; Feb 28 2012 at 20:12. Reason: Spelling error bothered me

  7. #167
    Master Sergeant Serclaes's Avatar
    Join Date
    Nov 27 2005
    Location
    this town right here
    Posts
    775
    O.k. I see where he is getting at. To give some perspective on what he's saying: you can't expect a hammer to work well for screws. Every ill used tool will fuck you up.

  8. #168
    Quote Originally Posted by Serclaes View Post
    you can't expect a hammer to work well for screws
    in case of maven: "you can't expect dildo to work well for screws", for anything other than compiling java source files and packaging them into jar it's worst possible tool ever, yet somehow people like themselves into pain, just look how easy it is to do something like file rename:

    <plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.7</version>
    <executions>
    <execution>
    <phase>generate-resources</phase>
    <goals>
    <goal>run</goal>
    </goals>
    <configuration>
    <tasks>
    <copy file="something" tofile="other"/>
    </tasks>
    </configuration>
    </execution>
    </executions>
    </plugin>


    in gradle you can actually write your build AS A PROGRAM (if you like), i don't need some unknown loosers (maven developers) to dictate me how should i build my code and wait 5 years to fix a bug with one line patch, maven is a bad joke, period

  9. #169
    Quote Originally Posted by one_man_clan View Post
    I love the motto of your ultimate-xml-driven-tool: "convention over configuration" ... which is totally wrong because there is no option for configuration.
    Are you using the same Maven I am? Maven is totally configurable, it is just that you do not need to do any configuration if you follow the conventions.

    If you find yourself jumping through hoops to do something the "Maven Way" when it could be done in a one line script then do it in a one line script. Maven is for dependency management, if Maven doesn't do what you want to do then don't use Maven to do it. At work I still use bash scripts and makefiles to coordinate my Maven builds.

    Of course, my preference is Gradle; the power of Ant, the dependency management of Maven all in a nice concise Groovy syntax.

    Quote Originally Posted by MaHuJa View Post
    All the files mentioned in the mission directory is how the result looks. The class files and toh mission file(s) have to go together, since it will only read them from that directory*; when you pbo it all up, it'll have to be part of the mission.
    The .class files and .sqm file have to be in the mission directory, but the Java source code files and Eclipse project files do not. The Eclipse project files include machine specific settings that can actually make it more difficult for others to use, and are worthless if the person is using a different IDE. Eclipse will create these files when you create/import a project so there is no need to include them with the mission. The source code should be kept separate simply so people are free to chose to take the bits they are interested in and don't get bloat they don't want.

    I can confirm this works because I am currently using Maven to build my Java/Groovy code in a separate directory and only copying the generated .class files to the TOH mission directory.

    But every so often you just need a slight change for it to be good for your uses. If you don't have the sources, you have to discard it completely; it may as well be useless junk.
    Ah, but that is SQF-think. In Java it is possible to modify the behaviour of other classes (within limits) without having the source code. Well, you don't actually modify the class you create a new class that "extends" the class you want to modify. For example, suppose someone released a must have package, but it was closed source and their Vehicle.getVelocity() method contained a bug that caused it to be off by one all the time. I could do something like:
    Code:
    public class MyVehicle extends Vehicle {
    	...
    	public int getVelocity() {
    		return super.getVelocity() + 1;
    	}
    }
    Now I can use instances of the MyVehicle class anywhere a Vehicle is expected and the "off by one" bug has been fixed.

    2) Learners - those learning java, or just how to use RVE from java, will be looking at code.
    Don't get me wrong, I am just playing Devil's Advocate. I suspect the Donators will outnumber the Code hoarders by a large margin. I am just saying closed source is not as "evil" in Java as it is in SQF. A well designed Java API will have abstract classes that can be extended or interfaces that can be implemented to allow others to change the behaviour of the classes with out modifying the source.

    My threads have all crashed after anywhere from 1 to 450000 RVEngine calls. This is a race condition problem, which means it will fail sooner or later, even if it's always worked for you while you were testing it.
    Agreed, RVEngine et al needs to be thread safe or we are doomed. Ok, maybe not doomed, but it will certainly be alot more work to write thread safe wrappers around them if they are not.

    It may not start running until the jcalled function returns,
    But that is the nature of concurrent programming. In fact I would think this to be the expected behaviour. Once a thread is started we have absolutely no control over the order the threads will be executed, or that the thread will even be started before the jCalled function returns. The more cores a CPU has, and therefore the more threads it can run, the more random this will seem.

    ---------- Post added at 07:09 PM ---------- Previous post was at 06:54 PM ----------

    Quote Originally Posted by one_man_clan View Post
    in gradle you can actually write your build AS A PROGRAM (if you like), i don't need some unknown loosers (maven developers) to dictate me how should i build my code and wait 5 years to fix a bug with one line patch, maven is a bad joke, period
    You do realize that Gradle is just a Groovy wrapper around Maven right... If you are using Gradle then you are using Maven, albeit without all the XML. I agree that XML tends to get used where it shouldn't be (don't even get me started on Ant), but don't confuse XML with Maven.

    Having said that, I thought I would be the only Gradle advocate here! Now I just need more recruits for the Groovy bandwagon
    Last edited by Slapstick; Feb 28 2012 at 23:34. Reason: Fixed spelling.

  10. #170
    Quote Originally Posted by Slapstick View Post
    Maven is totally configurable, it is just that you do not need to do any configuration if you follow the conventions.
    Ye, Maven is totally configurable, that's true. It takes 10 XML lines to change Java source level. Also conventional != required. Maven requires you do it Maven way like Maven devs knew every possible problem on the world.

    Maven is for dependency management, if Maven doesn't do what you want to do then don't use Maven to do it.
    Wrong, that's just the part of it. Are you sure you use Maven?!

    At work I still use bash scripts and makefiles to coordinate my Maven builds.
    Oh my...

    You do realize that Gradle is just a Groovy wrapper around Maven right... If you are using Gradle then you are using Maven, albeit without all the XML.
    Totally wrong. Gradle has nothing to do with Maven. It uses Ivy to fetch deps. Groovy wrapper around Maven would be exactly same piece of crap with slightly less verbose syntax.

    I agree that XML tends to get used where it shouldn't be (don't even get me started on Ant), but don't confuse XML with Maven.
    No confusion here. You program your build in shitty XML.
    Last edited by batto; Feb 29 2012 at 00:55.

Page 17 of 22 FirstFirst ... 7131415161718192021 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •