| |
| |
| |
|
Page: 1 2
Comments:
<0> hola
<1> away
<2> away
<3> MartyCruz: how's Java?
<4> @find java
<5> Hello everyone. I have a question: is the ***ert keyword supported in Java? Several pages I've been looking at suggest that it is, but my compiler refuses to recognize it.
<6> It is supported
<6> http://java.sun.com/j2se/1.4.2/docs/guide/lang/***ert.html
<6> You have to p*** an argument to the compiler when using them.
<7> Yes, as of 1.4.
<5> Thanks. That was actually one of the pages I'd been looking at. So does the compiler switch cause the code to compile with ***ertions, or does it state whether or not the code should in fact "***ert" run-time? Because in my case it's a compilation issue.
<8> hey Resonator
<8> what's the compilation issue?
<5> "Cannot resolve symbol ***ert"http://java.sun.com/j2se/1.4.2/docs/guide/lang/***ert.html
<5> Oops, sorry about the bad paste
<5> Anyway -- that's the error I get.
<5> With 1.4.
<8> are you using it properly? :)
<7> From Sun?
<5> ***ert (1 == 0);
<5> It's the compiler which is part of IntelliJ. I ***ume it uses the one from Sun's SDK.
<5> I've only used it about a week so far so haven't fully come to terms with it.
<7> You may have to tell it what Java version you are targeting.
<6> Hey jottinger!
<5> Yeah, I believe I've done so as well. So you're saying the code snippet above should definitely work with 1.4?
<6> RobertB: only if you tell the compiler that you want to enable ***ertions.
<8> it should compile fine, though
<6> If the IntelliJ compiler is 1.4.x, there should be some way to turn on ***ertions.
<6> I know in Eclipse you have to explicitly enable them in the compiler preferences before they'll work.
<6> *shrug*
<5> I will look into the compiler flag. At least I know where to start lookin (for a while I thought I had gone crazy or something as I kept seeing references to the ***ert keyword on the web)g. Thanks.
<7> ***erts are not a syntax error without that setting, using javac. On version 1.5 at least.
<5> All right, it looks like it was in fact not targeting 1.4. I added "-source 1.4" as an option and that did the trick. The IDE still displays it as an error (by flagging it in red) but at least it compiles.
<6> Cool.
<9> RobertB: IntelliJ doesn't red-falg it if you select a 1.4 JDK and check the ***ert syntax checkbox in your project settings (also check on module level)
<9> RobertB: Exactly how you define JDKs and ***ert syntax changes between version though, it seems
<7> I'd expect it to provide a quick fix to enable ***ertions if youj click on the error or something. Not that I use IDEA.
<9> Unless ofcourse you are using 3.5 or older I suppose, then it might not be aware of the 1.4 specifics
<5> There didn't seem to be an easy fix but there may be a way if I go through all of the settings. But I'll refrain from now as I'm not sure whether the owner of this project wants ***ertions enabled anyway.
<5> from = for
<5> Last week was the first time that I'd used Java for five or six years (normally I use C, C++ or C#). Feels good to be back. I have to admit I miss some things though, like indexed collections, auto boxing, and enums. I've heard some of those features made it to 1.5 though (which unfortunately I cannot use for this particular project.
<5> My main annoyance thus far however, is actually the convention to lower-case the initial letter of method names. :)
<9> RobertB: Index collections exist since forever, and autoboxing and enums are in 1.5
<9> for enums, there is always the static enumerator pattern to fit most uses
<5> Really? I tried indexing into a LinkedList but it would only support the get() method it seemed.
<7> That *is* indexing into it.
<6> I love generics in 1.5.. and the new iterator syntax. Good stuff.
<5> crookery: Ok. My mistake, I could have been more clear.
<5> I was referring to the use of the [] operator.
<7> You miss operator overloading. ;)
<5> When I first jumped into C# I thought that it seemed like a mistake to introduce C/C++ messyness but I had grown to like that feature. No biggie though, I'll survive. :)
<5> wlfshmn: With the static enumerator pattern, are you referring to the use a cl*** with instances of itself contained inside representing different values, and then manually adding support for comparing those values?
<9> Yes.
<5> That is so much work though, and so much code for every little enum.
<9> RobertB: It's trivial code that most of us implement by template from our spec and rarely, if ever, touch again
<9> RobertB: But yes, it is more code than it has to be
<5> Do you typically give the enumeration cl*** its own file or put it inside a cl*** that uses it?
<9> Depends on it's visibility, but most frequently it's it's own file.
<5> Ok.
<7> There is no reason not to use 1.5 anyway.
<5> I would if I had a choice, but this project targets a device which only supports 1.4 at this time.
<7> What is it?
<7> ..the device
<5> An airport terminal which accepts tickets, cards and performs other various duties.
<7> Who made its VM?
<5> I would ***ume they use the one provided by Sun.
<9> crookery: Well, I don't use 1.5 in all my projects, because we need to run on 1.4 in order to work with certain vrsions of app servers that our customers have
<7> RobertB: For what platform?
<9> crookery: we get new technical targets every release cycle, which is rouglhy every 18 months, and the last one was 1.4, the next one I might get to use 1.5
<5> Windows.
<7> RobertB: There is a 1.5 JVM for Windows.
<5> I know... but the devices will remain with 1.4.
<5> At least some of them.
<9> crookery: Asking the customer to upgrade is not always feasible. Especially not in between core releases
<7> It might be more feasible if you automate the upgrade, or allow the old version to sit beside it.
<9> crookery: IIRC, one of the major reasons we didn't migrate to 1.5 last cycle was that at the time, websphere didn't support it
<7> Websphere provides its own modified JRE iirc.
<9> My next project will certainly leave 1.4 behind atleast, since it isn't due for public release until in about three years
<7> My boss has already asked me whether I'll be looking to move to 1.6.
<7> Or 6, or whatever they'll call it.
<9> crookery: That may be. But then the one it provided probably did not yet run 1.5 code. I don't write app-server code myself, but I'm bound by the same technical platform as everyone else nonetheless
<5> I wonder why IntelliJ suggests to me to split the declaration and initialization of variables inside my cl***. Is there any compelling reason to do this that I'm missing?
<7> Not imo.
<10> it's just giving you options
<11> is it possible to do something like: clazz instanceof Cl***<? extends MyType>
<12> ?
<11> i want to check if clazz is a Cl*** for a type that extends or implements MyType
<6> Um. korbin, I don't think that's going to work.
<6> Cl*** is a final cl***, it can't be extended.
<11> i think cl*** does support generics though
<11> but yes i dont think what i wrote will work
<11> MyType something = new MyType();
<11> Cl***<? extends MyType> clazz = something.getCl***();
<11> Cl***<? extends MyType> superCl*** = clazz.getSuperCl***(); <-- this won't work because it returns Cl***<?>
<7> Obviously the supercl*** doesn't extend MyType..
<11> oh right
<11> i was thinking since clazz belongs to something ... but compiler doesn't go that far
<7> I'm mildly surprised it doesn't return Cl***? super MyType>.
<7> Cl***<? super MyType> even.
<7> Heh, and it does.
<7> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Cl***.html#getSupercl***()
<11> right .. i just can't cast it to Cl***<? extends Loggable>
<11> it returns Cl***<? super ? extends Loggable> .. not sure what that means
<7> A Cl*** that represents a supertype of something that extends Loggable.
<11> that makes sense but i can't do: Cl***<? super ? extends Loggable> superCl*** = clazz.getSupercl***()
<11> it complains about the super keyword
<7> What are you trying to achieve?
<11> basically i want to go up the super cl*** chain until i find a particular one
<11> the variable im using to iterate is Cl***<? extends MyType> clazz;
<11> but it can't be ***igned clazz.getSupercl***()
<11> so i have to use Cl***<?> clazz instead which is less type-safe
<11> actually i dont care and can see where it cant be incorrect since the object im getting the cl*** from has to implement MyType
<11> since i declare it as MyType
<11> i was hoping that when i get the super cl*** it would acknowledge that this is a super cl*** of something that is dervied from MyType is all
<7> Why do you want to go up the supercl*** chain?
<11> in our code, we ***ign logging parameters to each cl*** .. derived cl***es inherit any logging attributes
<11> so i want to check super cl***es for any logging atttributes
<7> Sounds daft to me, but ok.
<7> Just use Cl***<?> and get on with it.
<13> I fail to see the point if all derived cl***es inherit these attributes wouldn't it be easier to check on them?
<13> ofcourse while reading back I fail to see the point to any of this but thats just me ;)
<14> hello
<14> is there a good way to merge arrays?
<13> Lorraine: shouldn't be too hard to write a method for it, depending on how you want to merge 'm.
<14> I tried this "convert the arrays to ArrayLists, create a new ArrayList, then use ArrayList.addAll(Collection c) for each array to merge."
<7> Lorraine: What is merging in this context?
<15> Lorraine: see arrays trail in tutorial
<15> hi
<7> Lorraine: Ok, and?
<13> Ey there Clackwell
<14> crook: it throws an exception. I think it's because the destination array is empty
<14> Can I use addAll on an empty array?
<15> Lorraine: see arrays trail in tutorial?
<13> Lorraine: thats likely to get a NullPointerException.
<14> Clack: what tutorial?
<7> Arrays don't have addAll, so no.
<15> TUTINDEX Quickly locate information about your topic of interest in the *big* tutorial index: http://java.sun.com/docs/books/tutorial/reallybigindex.html
<14> ok I'll look into that tutorial
<14> crook: you say arrays don't have addAll, but I converted them into ArrayList with "Arrays.asList()"
<14> The problem is, I don't know what size the final array is gonna have, and I'm looking for a clean way to append to it
<14> Like in c++, myvector.push_back(mystuff);
<15> Lorraine: see arrays trail in tutorial?
<7> No, make a list containing everything you want, then convert that into an array.
<7> Of course, in Java most arrays are broken anyway, so you may as well use lists all the time.
<14> crook: I have a function that returns an array ; I call it X times, and I want to concatenate the return value to the final big array at each call
<14> like : Object[] partialResult = myfunc();
<14> finalArray.add(partialResult);
<14> return finalArray;
<7> Just Use Lists(tm).
Return to
#java
or
Go to some related
logs:
#linuxhelp
bubblesort assembler
#linux
#AllNiteCafe
#MissKitten
marcialfa
#AllNiteCafe
#linux
#java
backticks in vixie crontab
|
|