Time |
S |
Nick |
Message |
00:28 |
|
|
manulite joined ##javaee |
03:42 |
|
|
manulite joined ##javaee |
03:56 |
|
|
kobain_ joined ##javaee |
03:56 |
|
|
kobain_ joined ##javaee |
03:57 |
|
|
kobain_ joined ##javaee |
03:57 |
|
|
kobain joined ##javaee |
04:21 |
|
|
topriddy joined ##javaee |
04:37 |
|
|
neuro_sys joined ##javaee |
04:45 |
|
|
neuro_sys joined ##javaee |
04:58 |
|
|
dross joined ##javaee |
04:58 |
|
|
dross left ##javaee |
05:58 |
|
|
manulite joined ##javaee |
07:01 |
|
|
dosimeta joined ##javaee |
07:46 |
|
|
topriddy joined ##javaee |
07:53 |
|
|
topriddy1 joined ##javaee |
08:39 |
|
|
topriddy joined ##javaee |
08:39 |
|
|
topriddy left ##javaee |
12:29 |
|
|
balazare joined ##javaee |
12:34 |
|
balazare |
What is a good resource that explains how to manage/deploy/distribute a large project (several war, ejb/ejb-client etc) |
12:49 |
|
|
Guest75352 joined ##javaee |
13:24 |
|
acuzio |
balazare: what sort of project is this and how large ? |
13:29 |
|
balazare |
acuzio: it is a new operations/BI project. Inventory data, calibration data, product installation data, remote device management, some ties to control cloud software (mix of REST+IIOP). |
13:29 |
|
acuzio |
IIOP ? |
13:29 |
|
acuzio |
whats that |
13:30 |
|
balazare |
acuzio: initially not that large, but it needs to able to grow |
13:30 |
|
acuzio |
when you say large do you mean large number of lines of code or large deployables or large number of users or high traffic |
13:32 |
|
|
dreamreal joined ##javaee |
13:33 |
|
acuzio |
or large wars, jars, bars, |
13:39 |
|
|
Naros joined ##javaee |
13:44 |
|
acuzio |
BTW - has anyone here used REST based servers ? |
13:45 |
|
tjsnell |
I'm in REST hell today |
13:46 |
|
tjsnell |
well Tibco hell actually |
13:46 |
|
acuzio |
TIBRv ? |
13:48 |
|
acuzio |
did you take your shower then ? |
13:49 |
|
tjsnell |
Tibbw |
13:49 |
|
tjsnell |
got one of their top professional services guys on the phone for 2 hours and we can't get a REST interface running still |
13:49 |
|
tjsnell |
in camel it's a couple lines of code |
13:49 |
|
tjsnell |
but no pretty gui |
13:50 |
|
acuzio |
Camel - |
13:50 |
|
acuzio |
jeez is that thing still alive |
13:54 |
|
tjsnell |
thriving :) |
13:55 |
|
acuzio |
i dont believe you - i am gonna go and check |
13:55 |
|
acuzio |
Has anyone here used REST with JSP please ? |
13:58 |
|
|
wlfshmn left ##javaee |
14:01 |
|
tjsnell |
it's because of the quality of the committers |
14:20 |
|
balazare |
acuzio: I have some RMI and CORBA stuff, it based on the IIOP protocol |
14:22 |
|
balazare |
acuzio: large in code but more importantly many interconnected deployables. |
14:26 |
|
balazare |
acuzio: I have an app that uses REST with JSP (+jquery and bootstrap). The JSP portion is not heavy though |
14:40 |
|
|
kobain joined ##javaee |
14:47 |
|
sfisque |
i had an epiphany (whartung) why CDI cannot be supported in @Asynch methods. what happens if an object is session or conversation scoped, and the servlet session that is holding that context goes out of scope (session times out, get garbage collected, etc.) before the @Asynch method completes. |
14:52 |
|
|
Determined_P joined ##javaee |
14:57 |
|
|
Determined_P left ##javaee |
15:51 |
|
acuzio |
tjsnell: quality of committers is very good - except for one i am told - they keep him on because of his age i am told |
15:51 |
|
acuzio |
why should sessions be managed from the Server ? |
15:52 |
|
acuzio |
balazare: so how is it REST if it is done via JSP |
15:59 |
|
whartung |
acuzio: JSP is not germane to the discussion. You can do REST with anything on the backed: JSP, Shell script CGI, COBOL on a mainframe... |
16:01 |
|
acuzio |
You can do REST with JSP ? |
16:01 |
|
acuzio |
really - how |
16:01 |
|
acuzio |
what happens to session management ? |
16:01 |
|
whartung |
what makes you think you can't? |
16:01 |
|
whartung |
what's session management have to do with anything? |
16:04 |
|
acuzio |
Isn't JSP based on the idea that Sessions have to be managed from the Server |
16:05 |
|
whartung |
Sessions are a service of the server, JSPs can use sessions, but that's an application choice, you don't have to. |
16:05 |
|
acuzio |
i see |
16:06 |
|
|
soulslayer joined ##javaee |
16:06 |
|
soulslayer |
Hi there guys i have a strange problem i override the addInterceptors method of the WebMvcConfigurerAdapter to put my LocaleChangeInterceptor in the registry but unfortunately the overriden method is never called can some of you guys give me hand in debuging that issue ? |
16:07 |
|
whartung |
sounds like a spring thing |
16:07 |
|
soulslayer |
and it ocures ONLY on one machine |
16:07 |
|
soulslayer |
i think is more like a .. server issue or something |
16:07 |
|
soulslayer |
i copy paste the tomcat on my local machine run it at it works |
16:07 |
|
whartung |
I can't say for sure, but all of those interceptors and adapters look like Spring to me. |
16:08 |
|
soulslayer |
yes yes it's spring |
16:08 |
|
whartung |
well, I certainly can't help you. I don't know anything about spring. |
16:09 |
|
soulslayer |
yep i see |
16:09 |
|
soulslayer |
this chan was a blind shot :) |
16:11 |
|
whartung |
yea, hang out, someone may know later, but Spring != JEE, so... |
16:12 |
|
soulslayer |
yes yes i know |
16:12 |
|
soulslayer |
sorry |
16:12 |
|
soulslayer |
;) |
16:13 |
|
whartung |
no, don't be sorry. no worries. |
16:14 |
|
acuzio |
Spring is not JEE - really / |
16:14 |
|
whartung |
really |
16:16 |
|
acuzio |
wow |
16:17 |
|
acuzio |
doesnt Spring have support for JSP's |
16:17 |
|
whartung |
Spring relies on a servlet container which has support for JSPs |
16:17 |
|
acuzio |
What about EJB |
16:17 |
|
whartung |
they don't use EJB |
16:18 |
|
acuzio |
they dont - what about EJB3 ? |
16:18 |
|
whartung |
nope, they don't use that either |
16:18 |
|
acuzio |
What about JPA ? |
16:18 |
|
whartung |
they use jpa |
16:18 |
|
whartung |
so do generic Java apps |
16:20 |
|
acuzio |
isnt that JEE ? |
16:21 |
|
whartung |
it's a part of it, but alone, no. |
16:21 |
|
acuzio |
Ok |
16:21 |
|
acuzio |
whartung++ |
16:22 |
|
whartung |
Tomcat is not a JEE container, it's a servlet contianer. Servlets are part of JEE, but like JPA, they're just a component. |
16:22 |
|
acuzio |
whartung: You are a good guy - thanks |
16:22 |
|
whartung |
yw |
16:24 |
|
acuzio |
I am missing Quest, Sircle and there was another guy here |
16:26 |
|
tjsnell |
me |
16:33 |
|
balazare |
acuzio: In my case REST call are as ajax calls (through jquery), the session management is done through the HttpServletRequest.login on the REST service |
16:35 |
|
balazare |
acuzio: I need JSP mainly for some environment things and a few special formatting items |
16:50 |
|
|
sfisque joined ##javaee |
16:51 |
|
whartung |
hey sfisque -- yea, the lifecycle issues just confirm the session issues with CDI in Async, my only point being that there are other CDI use cases that don't involve the session etc. that Should Work(™) with Async |
16:52 |
|
sfisque |
aye, i havent tested applicationScoped or RequestScoped. those, supposedly should be fine in an Asynch method |
16:52 |
|
sfisque |
since they are either "completely dynamic" or "singleton static" by definition |
16:53 |
|
whartung |
right |
16:53 |
|
whartung |
I mean, basicaly, the session scoped CDi "is" working -- but since there's no session, you get null. |
16:53 |
|
sfisque |
right |
16:53 |
|
sfisque |
the exception you see is (paraphrased) "There's no context for the CDI bean xxx" |
16:54 |
|
sfisque |
i had (have) assumed upto the point of my epiphany that it was globally true. now that i've given it thought and you've chimed in, it's probably saying, "there's no session context, so sorry bud!" |
16:55 |
|
whartung |
yea, that makes sesne |
16:55 |
|
whartung |
so it was actually failing with an exception rather than silently returning null? |
16:55 |
|
whartung |
that's arguably the "right thing". |
16:56 |
|
whartung |
but this whole discussion |
16:56 |
|
whartung |
really makes me think |
16:56 |
|
whartung |
about the use cases such as yours, which I think are arguably, execptional rather than routine |
16:56 |
|
whartung |
to where you would be better off putting the CDI stuff in to wrappers that call "normal beans" underneath taht are "CDI" free to promote reuse |
16:57 |
|
whartung |
and I would just refactor those out on a case by case basis rather than as a fundamental driver of design. |
17:01 |
|
sfisque |
well, it begs the question. why should someone be injecting a CDI bean that contains state into an SLSB. that's a code smell if ever there was one |
17:02 |
|
sfisque |
state info should be passed in on the call stack to the method |
17:02 |
|
sfisque |
if the bean is truly stateless |
17:02 |
|
whartung |
yea that would "never" happen -- it's a STATELESS SB... |
17:02 |
|
whartung |
and SLSBs know "nothing" about HTTP requests |
17:02 |
|
sfisque |
right |
17:03 |
|
sfisque |
so i'm going to have to do a "parallel" refactor so that i do not perturb the existing workflow. eventually we can refactor the existing workflow (that the web ui uses) to use the newer "stateless" calls that i will be creating |
17:04 |
|
whartung |
"parallel" refactor? Is that what they call "Cut and Paste" today? :) |
17:27 |
|
sfisque |
sort of. copy/paste, mark existing @Deprecated, enter a jira ticket to refactor, blah blah blah |
17:27 |
|
whartung |
:) |
17:27 |
|
sfisque |
:-D |
17:38 |
|
Sircle |
acuzio: hm.. missing me? we didnt even had a single chat before. |
17:41 |
|
whartung |
makes it even more profound, eh Sircle ? |
17:41 |
|
whartung |
who knew. |
17:41 |
|
Sircle |
:) |
17:44 |
|
sfisque |
maybe referencing a previous life? did you two maybe converse on the ramparts of the bastille during the french revolution? |
17:44 |
|
whartung |
or perhaps you were a pet goat. |
17:45 |
|
sfisque |
you may ask yourself…. well… how did i get here...... |
17:45 |
|
* sfisque |
starts flipping and floating through a video montage |
17:48 |
|
|
jaya_ joined ##javaee |
18:05 |
|
|
Quest joined ##javaee |
19:48 |
|
Quest |
Naros, you there? |
19:48 |
|
Naros |
no? <grin> |
19:48 |
|
Quest |
:) |
19:48 |
|
Quest |
http://pastebin.com/vfqQ0niF why line 2 checks id for == 0 |
19:50 |
|
Naros |
That probably should be a null check in all honesty. |
19:50 |
|
Naros |
non-persisted (new records) have no ids assigned to them (unless its a composite key the app is responsible for creating) and thus is typically null for persist and contains a non-null value for merge (updates). |
19:51 |
|
Naros |
internally, hibernate session's saveOrUpdate() has an equivalent check on the entity's ID |
19:51 |
|
Naros |
if it's null, it inserts; otherwise updates. |
19:51 |
|
Quest |
hm |
19:52 |
|
Quest |
so i dont need an if / else statement? |
19:53 |
|
Quest |
2. i would use == null check rather == 0 . ok? |
19:54 |
|
Quest |
Naros, oh no. the getid() is a long. so == null cant be applied. |
19:54 |
|
Naros |
Change it to a Long :P |
19:54 |
|
Naros |
generally, I'd argue that entity properties should not be primitives |
19:56 |
|
Naros |
As for if/else with the use of merge versus persist |
19:57 |
|
Naros |
just understand that persist inserts/updates the record and keeps the object's state in-place, meaning that the instance of your entity (if it were not managed before you passed it to the EM becomes managed). |
19:57 |
|
Naros |
merge creates a copy of the entity instance, returning you the new entity that is managed. |
20:01 |
|
|
Quest joined ##javaee |
20:03 |
|
Naros |
Check this out Quest: http://stackoverflow.com/a/1070629 |
20:03 |
|
Naros |
it's a pretty clear differentiation between persist vs merge |
20:04 |
|
Quest |
disconnected(). Naros i think wrappers like Long or Integer should not be used unless needed. (book, effective java by josh) 2. this does not happens with "persist" ? (i.e the new entity is not returned.) "merge creates a copy of the entity instance, returning you the new entity that is managed.") |
20:05 |
|
Quest |
Naros, ok. i will do some readings |
20:06 |
|
Naros |
Quest: the problem with that philosophy is that database fields can be null. |
20:06 |
|
Quest |
Naros, same question again that confuses me again. if there is some problem in dao. like the user already exists, or some other issue, how to pass that error messege to service , then to controller, then to jsp (by controller model)? |
20:07 |
|
Naros |
and null state is considered valid for new entities who have no record id |
20:07 |
|
Quest |
Naros, so this paste http://pastebin.com/vfqQ0niF is some what ok? |
20:07 |
|
Naros |
not exactly. |
20:07 |
|
Quest |
what should it be? |
20:08 |
|
Naros |
you can do it two ways, depending on how you want your API to behave. |
20:08 |
|
Quest |
hm.. |
20:08 |
|
Quest |
like? |
20:09 |
|
Naros |
http://pastebin.com/bcjrCAnv |
20:09 |
|
Naros |
in the first method, you're returning the same entity instance you passed into the method |
20:09 |
|
Naros |
persist makes the entity managed in-place. |
20:10 |
|
Naros |
in the second method, you're returning a different entity instance than what you passed into the method. |
20:10 |
|
Naros |
if the original entity WAS managed, it is NOT managed after the call and only the returned instance is managed. |
20:11 |
|
Naros |
the difference is in the second one, you must use the returned value if you plan to do further operations on your user. |
20:11 |
|
Naros |
otherwise changes will be lost. |
20:11 |
|
Naros |
in the first example, the input and return user entity instance is one in the same. |
20:11 |
|
Naros |
both will handle insert/update appropriately. |
20:12 |
|
Quest |
got it. in http://pastebin.com/vfqQ0niF line 9 is also returning the managed user or not? |
20:12 |
|
Naros |
e.g. if the id is null, it inserts. if the id is non-null, it updates the record. |
20:12 |
|
Naros |
line 9 in your past is returning the same entity instance you passed in, which in that case is 'not' the managed copy. |
20:12 |
|
Naros |
*paste |
20:13 |
|
Naros |
you are discarding the managed instance on line 9 |
20:13 |
|
Quest |
i see |
20:14 |
|
Quest |
well now i think. both of your paste methods , persist or merge should return the created/updated entity as that entity (if successfullyy created) might be used by the caller of that method later on? |
20:14 |
|
Quest |
what do you think? |
20:15 |
|
Quest |
Naros, like this http://pastebin.com/Zg7bgmQ0 . ? |
20:16 |
|
sfisque |
quest, you generally want to avoid primitives in entity PKs, because you need to differentiate between null (not persisted) and 0 (a valid value) |
20:17 |
|
Quest |
sfisque, yes. thats the only case we need them. |
20:17 |
|
sfisque |
in fields that are not PK/FK, primitives are fine and generally will give you better performance in scale |
20:17 |
|
Quest |
sfisque, is there a work around ? |
20:17 |
|
* Quest |
agrees. |
20:17 |
|
sfisque |
yeah, but then you're using the "magic number" anti-pattern |
20:17 |
|
Quest |
sfisque, i did primitive for performance boost |
20:18 |
|
Quest |
sfisque, hm? |
20:18 |
|
Naros |
magic number anti-pattern, assuming 0 means not-persisted |
20:18 |
|
Quest |
hm. |
20:18 |
|
Naros |
non-0 means persisted objects |
20:18 |
|
Naros |
that's an anti-pattern |
20:18 |
|
Quest |
sfisque, Naros will that be ok (to use ==0) ? |
20:18 |
|
Naros |
if you want to use anti-patterns in your code :P |
20:18 |
|
* sfisque |
nods with naros |
20:19 |
|
Quest |
am. anti-patterns are not injurious i gues? |
20:19 |
|
Naros |
it's equivalent to saying it's bad design :P |
20:19 |
|
Naros |
what do you do tomorrow when 0 becomes a legal value in your domain model? |
20:19 |
|
sfisque |
except that in some cases, they look deceptively like "good design". base bean is one such anti-pattern |
20:19 |
|
Quest |
sfisque, Naros so iam stuck with only one choice ? Long == null check? |
20:20 |
|
sfisque |
yes Q |
20:20 |
|
Naros |
Absolutely, esepcially for PKs |
20:20 |
|
sfisque |
for PK/FKs, recommended. for calculated or informative fields, prims are fine |
20:20 |
|
Quest |
hm. so I should convert all long ids to Longs wrappers. but what about performance and scale problem? |
20:21 |
|
Naros |
I've never seen any performance issues and we do that with several hundred entity types with ease. |
20:21 |
|
sfisque |
your joins should be in the db where they are already primitive, so its' not an issue |
20:21 |
|
Quest |
Naros, and is this fine? like this http://pastebin.com/Zg7bgmQ0 . ? |
20:21 |
|
sfisque |
if you're doing that much calculation on FK/PKs in memory, you're doing something very wrong |
20:21 |
|
Quest |
Naros, performance issues are only seen with huge user base. i actually have a huge userbase. |
20:21 |
|
Quest |
sfisque, ^ |
20:21 |
|
Naros |
exactly, avoid doing memory-based joins and allow that database to do what it was designed to do :P |
20:22 |
|
Quest |
hm |
20:22 |
|
Quest |
got it |
20:22 |
|
Naros |
Quest: What is huge to you? |
20:22 |
|
Naros |
Our transaction master's PK is in fact a combination of 4 Longs and a Date. |
20:22 |
|
Quest |
okie dokie. by the way i really doubt that 0 will be a valid id in my DB in future sfisque Naros |
20:22 |
|
Quest |
Naros, users of that web i mean |
20:23 |
|
Naros |
We operate over 100s of millions of records with ease using Hibernate with that PK setup |
20:23 |
|
Quest |
Naros, oh. then I am worring to much i guess. |
20:23 |
|
whartung |
most likely |
20:23 |
|
Naros |
that happens to young programmers :P |
20:23 |
|
Quest |
Naros, and is this fine? like this http://pastebin.com/Zg7bgmQ0 . ? |
20:23 |
|
whartung |
until it shows up on the profiler, don't worry about it |
20:23 |
|
Naros |
^^^^^^^^^^^ |
20:24 |
|
Naros |
i can't stress whartung's advice enough |
20:24 |
|
Quest |
:) |
20:24 |
|
whartung |
for what it's worth, i don't think we call "persist" at all in our system. |
20:24 |
|
Naros |
you'll spend far mroe time trying to design some elaborate scheme that in the end will be more klunky and slower than just doing it the easy way until profiler says otherwise. |
20:25 |
|
Quest |
whartung, why not call persist? |
20:25 |
|
Naros |
Quest: as I said, using persist vs merge is partially a matter of taste. |
20:25 |
|
Naros |
both do the same, its just how you want to interact with the API |
20:25 |
|
whartung |
because then we don't care the state of the object -- managed or not. exists or not. It's just easier. |
20:25 |
|
Quest |
hm. |
20:26 |
|
Naros |
easy approach is to do what whartung suggests and use merge always. |
20:26 |
|
whartung |
let JPA figure that out -- 99.999% of the time it's not imporatnt |
20:26 |
|
Quest |
either way, the return value should be the new one. not the one that was given in argument. right? |
20:26 |
|
Naros |
yep and when that 0.0001% need crops up, just make an exception. |
20:26 |
|
whartung |
the majority of our methods are named "upsert" for a reason |
20:26 |
|
whartung |
yup |
20:26 |
|
whartung |
yes |
20:26 |
|
whartung |
the new one |
20:26 |
|
Quest |
hm. k |
20:26 |
|
Quest |
like this http://pastebin.com/Zg7bgmQ0 . ? |
20:27 |
|
Naros |
yes, merge takes the argument you pass it, unmanages it if it was managed and returns you a new instance that is considered managed by JPA |
20:27 |
|
whartung |
the second one, ditch the first one |
20:27 |
|
Quest |
k :) |
20:27 |
|
Quest |
the first one is also good to go right |
20:27 |
|
whartung |
no |
20:27 |
|
Quest |
ok. |
20:28 |
|
Naros |
the first one is taht 0.00001% case :P |
20:28 |
|
whartung |
yup |
20:28 |
|
sfisque |
hah upsert |
20:28 |
|
Quest |
ya. that understood already :) |
20:28 |
|
Naros |
but yes, you could use the first one for that corner case |
20:28 |
|
Naros |
but only for that :P |
20:28 |
|
Quest |
but IF persist is used. i would prefer updated return value |
20:28 |
|
Quest |
ok. |
20:28 |
|
Naros |
persist makes the instance you pass it managed |
20:28 |
|
Quest |
lastly. I cant get this out of my head. same question again that confuses me again. if there is some problem in dao. like the user already exists, or some other issue, how to pass that error messege to service , then to controller, then to jsp (by controller model)? |
20:29 |
|
Naros |
if you look at the API, persist doesn't return anything |
20:29 |
|
Naros |
merge does return an object |
20:29 |
|
Quest |
oh |
20:29 |
|
sfisque |
aye. the differ. persist makes the instance managed "in situ". merge gives you back a reference to a new copy that is managed |
20:30 |
|
Naros |
DAO throws an EntityAlreadyExistsException |
20:30 |
|
whartung |
if you care about "the user already exists", them explicitly check for it. |
20:30 |
|
whartung |
by the time the "upsert" happens, it's "too late" |
20:30 |
|
Naros |
Service catches it and returns some value object to the controller with state. |
20:30 |
|
whartung |
careful about grenading your transaction when that happens... |
20:31 |
|
Naros |
or as whartung suggests, check it before calling upsert and return a value object to the controller with state. |
20:31 |
|
whartung |
if the dao fails, it's because the DB got shipped off to Madagascar without telling anyone |
20:31 |
|
Naros |
whartung: yah properly placed try/catch inside the service should prevent that |
20:31 |
|
Naros |
since service should be where transaction boundaries exist imo |
20:31 |
|
whartung |
yup |
20:32 |
|
Quest |
Naros, whartung ya . returning some value object is what i thought (discussion in paste with you guys when it was finalized that controller would be doing most of the logic). so how to set up a value object in DAO, and pass that to Serivce, then to controller? |
20:32 |
|
Quest |
and how controller checks up for each possible problem and puts the error to model |
20:32 |
|
whartung |
one thing you learn, particularly with postgres, is you don't do "checking" in the DB. The DB does enforcement. But the data you send it should be already checked. |
20:32 |
|
Quest |
this is really a nightmare |
20:33 |
|
sfisque |
aye, use the validation frameworks. EJB has one, spring has one, hibernate has one |
20:33 |
|
sfisque |
your bean(s) should be "mostly validated" before persist/merge (barring realtime FK/PK collisions and @Version stale issues) |
20:33 |
|
Quest |
whartung, hm. got it. |
20:34 |
|
whartung |
for our older stuff, the controller does most of the work, and sets errors for the framework (which displays them on the webpage for us). |
20:34 |
|
whartung |
for our newer stuff, everything on the edge returns a Result, which is a multi valued object. |
20:34 |
|
whartung |
so |
20:34 |
|
whartung |
Result r = service.getUser(123); |
20:35 |
|
Naros |
Quest: be careful with value objects here. Generally speaking, the DAO should only care about Entity/Domain objects or primitives/context objects the service passes the DAO to obtain entities. |
20:35 |
|
Quest |
whartung, oh |
20:35 |
|
whartung |
User u = (User)r.getResult(); |
20:36 |
|
sfisque |
so in effect "Result" is an interface or abstract class that the entities extend? |
20:36 |
|
whartung |
no |
20:36 |
|
whartung |
it's a container |
20:36 |
|
Naros |
what the controller and service exchange could be your domain (entity) models or some other value object/context object |
20:36 |
|
Quest |
whartung, i think theres my answer. what exactly will the object (multi value) would consist of? |
20:36 |
|
sfisque |
so then how does the typecasting work |
20:36 |
|
sfisque |
you cant just typecast willynilly |
20:37 |
|
whartung |
it's not enforced at that point. |
20:37 |
|
whartung |
we pass these back in WebServices also, which loses a lot of that anyway |
20:37 |
|
whartung |
it may have been different if we used it solely in java |
20:38 |
|
sfisque |
aye, so what does getResult() return that can be typecast to User? i'm assuming it's either Object() or some iface/abstclass |
20:38 |
|
whartung |
objcet |
20:38 |
|
sfisque |
/shudder |
20:38 |
|
Quest |
whartung, i think theres my answer. what exactly will the object (multi value) would consist of? |
20:38 |
|
* sfisque |
is not a big fan of API's returning Object |
20:38 |
|
Quest |
Naros, ok |
20:39 |
|
Quest |
sfisque, do you suggest the contrary? |
20:39 |
|
whartung |
for us, it consists of a list of Results (objcets to return) and Conditions. |
20:39 |
|
Quest |
whartung, for example? |
20:39 |
|
whartung |
so: Result r = service.upsertUser(myUser); |
20:39 |
|
whartung |
in the result |
20:39 |
|
whartung |
we could get back |
20:40 |
|
sfisque |
i guess i'm curious if Result is a concrete class or an abstract/interface that can be typecast as needed |
20:40 |
|
whartung |
the updated user (if perhaps the upsert changes it, modifies the updatedDate or something) |
20:40 |
|
Naros |
sfisque: Result<T> :P |
20:40 |
|
whartung |
a Succes message telling us that it's "OK" (for simple if (r.succeeded()) ) |
20:40 |
|
whartung |
as well as a WARNING condition |
20:40 |
|
Naros |
public T getResult(); |
20:40 |
|
whartung |
telling us "yea, we upserted the User, but by the way the birthday was NULL, so FYI: |
20:41 |
|
sfisque |
syntactic sugar. so Result is a concrete class that wraps Object |
20:41 |
|
whartung |
you could do that, we don't because of the web services |
20:41 |
|
Quest |
sfisque, that would do also. but the question is. is this strategy ok for passing a return Object with error or success message . all over from DAO to service to controller and then to jsp , ok? |
20:41 |
|
Quest |
Naros, whartung ^ |
20:41 |
|
Naros |
service -> controller, sure |
20:41 |
|
Naros |
not dao -> service -> controller imo |
20:41 |
|
whartung |
daos are primitve |
20:41 |
|
whartung |
they work or the db is borked |
20:42 |
|
whartung |
"don't lie to the DAO" |
20:42 |
|
sfisque |
depends. in a very loosely coupled system, you should be passing messages that can communicate result stae (fail, success, partial outcome, etc.) so things like Result make sense |
20:42 |
|
sfisque |
in a tiered system that has some cohesion, you'd want more direct results (success or Exception) |
20:42 |
|
whartung |
yea |
20:43 |
|
whartung |
you mostly want a tiered system. Loosely coupled systems have their place, but MOST systems are fine being more tightly bound. You can always loosen them up incrementally for integratio later |
20:43 |
|
Quest |
hm. ok . let me conclude it in a short way on a pastebin then |
20:43 |
|
* sfisque |
nods with whartung |
20:44 |
|
Naros |
aye, my preference is definitely the sucess/exception approach |
20:44 |
|
whartung |
yes |
20:44 |
|
Quest |
Naros> not dao -> service -> controller imo what if the DAO has an error that needs to be carried out to jsp? |
20:45 |
|
Naros |
dao exceptions are probably database-specific type exceptions |
20:45 |
|
sfisque |
aye. but if you're doing things like an ESB or a service fabric, messages are going to give you less headache :P |
20:45 |
|
whartung |
it's an exeption the controller eats it and presents it "properly" to the jsp |
20:45 |
|
Naros |
service catches those and turns them into something more meaningful to the UI |
20:45 |
|
Naros |
No UI cares about a QuerySyntaxException :P |
20:46 |
|
sfisque |
consider Controller -> EJB -> JMS -> Queue Pub/Sub -> Corba Endpoint |
20:46 |
|
sfisque |
bubbling an exception through that would be a nghtmare |
20:46 |
|
whartung |
doesn't sound like he's doing that sfisque |
20:46 |
|
whartung |
so no reason to muddy the waters talking about them |
20:46 |
|
sfisque |
i know, i'm just "giving examples" |
20:46 |
|
sfisque |
:-) |
20:47 |
|
Naros |
if you follow whartung's advice earlier and "don't lie to the DAO", the only exceptions it likely would throw are considered hard errors. |
20:47 |
|
whartung |
precisely |
20:48 |
|
Naros |
in most cases, halt the transaction and report some error occur that could not be recovered from. |
20:48 |
|
Naros |
sometimes giving the end user too much information can be bad |
20:49 |
|
whartung |
yea |
20:49 |
|
Naros |
reminds me of the login error "Bad password", "Unknown user name", etc. |
20:49 |
|
whartung |
log the original exception, and tell the user "so sorry, oopsie call help desk" |
20:49 |
|
sfisque |
or the generic "Login Failed, please try again" |
20:50 |
|
Quest |
hm. ok . let me conclude it in a short way on a pastebin then http://pastebin.com/fVKRyRms |
20:50 |
|
sfisque |
or even better… |
20:50 |
|
sfisque |
"you missed your password by 2 characters, please try again" |
20:50 |
|
sfisque |
:P |
20:50 |
|
whartung |
"you;re getting warmer!" |
20:50 |
|
Naros |
exactly |
20:50 |
|
sfisque |
lolz |
20:51 |
|
Naros |
I've seen it in so many authorization code bases it's unreal. |
20:51 |
|
whartung |
it's actually a mastermind game in disguise |
20:51 |
|
sfisque |
ROFL |
20:51 |
|
whartung |
yea, that's a maze of twisty passages |
20:51 |
|
Quest |
so are we good to go? |
20:51 |
|
Naros |
Quest: keep in mind that the status message could be an array of messages depending on your API |
20:52 |
|
sfisque |
where are we going? and are you buying? |
20:52 |
|
Quest |
Naros, ok |
20:52 |
|
Naros |
is beer involved? |
20:52 |
|
whartung |
will I be back by dinner? |
20:52 |
|
Naros |
if so, count me in :P |
20:52 |
|
Quest |
:) |
20:52 |
|
sfisque |
and beach sand. and deck chairs |
20:52 |
|
Quest |
wow. programmers are romantic. i didnt knew |
20:53 |
|
Naros |
programmers can be anything behind a computer :P |
20:53 |
|
Quest |
I am not romantic, I have lost much hair now |
20:53 |
|
whartung |
On the internet, nobody knows I'm a programmer |
20:53 |
|
Quest |
hm, |
20:53 |
|
sfisque |
i'll put it into perspective for you. 2 halloweens ago, i came to work dressed as "the dude". all i needed to do was put a bathrobe over my usual outfit :P |
20:53 |
|
Quest |
hm. so the paste is ok? http://pastebin.com/fVKRyRms |
20:54 |
|
Naros |
sfisque: lol |
20:54 |
|
Naros |
we've been lucky lately to wear jeans almost everyday. dunno what i am gonna do come the 13th when we have to go back to biz casual :E |
20:54 |
|
sfisque |
^.^ |
20:54 |
|
sfisque |
what happens on the 13th? the office turns back into a pumpkin? |
20:55 |
|
Naros |
just the last day of denim :( |
20:55 |
|
Naros |
we haven't had any visitors in the office so we've been able to dress down |
20:55 |
|
sfisque |
seems kind of arbitrary, but fitting since it's a friday the 13th |
20:55 |
|
Naros |
lots of C-levels been on vacation and such |
20:56 |
|
sfisque |
corp memo: clothing is now corporate. and please splash blood away from the cubicles. have a nice day! |
20:56 |
|
Naros |
lol pretty much |
20:56 |
|
sfisque |
and say hello to our new HR manager, jason. he's a hockey fan! |
20:57 |
|
whartung |
heh |
20:57 |
|
sfisque |
he's going to assist us in our downsizing initiative |
20:57 |
|
whartung |
hobbies: camping and chainsaws... |
20:57 |
|
sfisque |
^.^ |
20:57 |
|
sfisque |
>.< |
20:58 |
|
Naros |
in my old office, I let a stuffed bear hang from the ceiling for months in a nuce made from a network cable that my sysadmin left as a gag gift with a message that said "I'm finally free!" |
20:58 |
|
Naros |
right over my cube chair :P |
20:58 |
|
Naros |
no way i could get away with that here |
20:59 |
|
sfisque |
my current "hexicle" is festooned with artwork from my children, and my map of the internet :-D |
20:59 |
|
Naros |
those were the days... 18+ hour days dealing with people from Europe at odd hours of the day :3 |
21:00 |
|
Naros |
map of the internet o.o |
21:00 |
|
Quest |
whartung, Naros sfisque http://pastebin.com/VwhhTXT6 |
21:00 |
|
sfisque |
i worked for a company that mapped the internet every night |
21:00 |
|
sfisque |
about 10 years ago |
21:00 |
|
Quest |
thats the service class method that i changed ^ |
21:00 |
|
Naros |
Quest: why is a get transaction not read only? |
21:01 |
|
* whartung |
remembers when the internet map looked like a <--> b |
21:01 |
|
sfisque |
aye, if you're reading, a xact is overkill |
21:01 |
|
Quest |
Naros, have to work on it though |
21:01 |
|
Naros |
@Transactional(readOnly=false) is only necessary if you're changing stuffs |
21:01 |
|
crimsonfubot` |
Naros: Error: "Transactional(readOnly=false)" is not a valid command. |
21:01 |
|
sfisque |
unless you're trying to avoid a dirty read |
21:02 |
|
Naros |
... @Transactional(readOnly=false) is only necessary if you're changing stuffs |
21:02 |
|
whartung |
don't worry about the transactional thing. |
21:02 |
|
Quest |
so is the paste bin strategy ok (other thatn the @annotation) |
21:02 |
|
sfisque |
you're reading twice, why? |
21:03 |
|
sfisque |
two round trips for the same object |
21:03 |
|
Naros |
I also dont think your user of the if/else clause is right |
21:03 |
|
Naros |
*use |
21:03 |
|
Quest |
sfisque, oh you mean on line 12 and 19? |
21:03 |
|
Naros |
yep |
21:03 |
|
sfisque |
yes |
21:03 |
|
Quest |
ok. i will cover it |
21:03 |
|
sfisque |
laod it once and test the local instance |
21:03 |
|
Quest |
other than that? |
21:04 |
|
sfisque |
and onkly set it on success |
21:04 |
|
Quest |
hm |
21:04 |
|
sfisque |
otherwise you're going to end up with a spurious result |
21:04 |
|
sfisque |
in your paste, you set it regardless of the outcome |
21:04 |
|
Quest |
sfisque, ya. didnt knew how to handly that. as I am in doubt how to handle DAO |
21:04 |
|
sfisque |
and the original outcome has no bearing on the final outcome because you're roundtripping again |
21:05 |
|
sfisque |
User u = userDao.blahblahlbah(); |
21:05 |
|
sfisque |
if( u == null ) { fail stuff } else { success stuff } |
21:07 |
|
Quest |
sfisque, good to go ? http://pastebin.com/iCa1XVzh |
21:07 |
|
Quest |
whartung, Naros we are on the same page? http://pastebin.com/iCa1XVzh |
21:07 |
|
Naros |
personally, I'd only set the reeturn object if success; leave it alone otherwise. |
21:08 |
|
Quest |
oops. its != null on 13 |
21:08 |
|
Quest |
Naros, but by that, the error message wont get carried to the controller :0 |
21:08 |
|
Naros |
no i'm saying only call line 20 on success. |
21:09 |
|
Naros |
no need to set null to null :P |
21:09 |
|
Quest |
ah. wait |
21:09 |
|
Quest |
let me change it |
21:09 |
|
Naros |
I'd also probably not have setters on the Result too |
21:09 |
|
Naros |
pass all three values as constructor args |
21:10 |
|
Naros |
but thats more of a matter of taste. |
21:11 |
|
Quest |
http://pastebin.com/sNw1aZKA |
21:11 |
|
Naros |
yep thats looks better. |
21:11 |
|
Quest |
Naros, ya. constructor args is better |
21:11 |
|
Naros |
*that |
21:12 |
|
Naros |
I prefer the concept of |
21:12 |
|
Quest |
Naros, when problem in DAO occurs. the return object of DAO method is always null? |
21:12 |
|
Naros |
if(user != null) { return new Result(true,"you win",user); } else { return new Result(false",'failed"); } |
21:13 |
|
Naros |
a method doesn't return anything if it throws an exception. |
21:13 |
|
Naros |
unless you wrap that method with some annotation black magic that does stuffs :) |
21:14 |
|
Quest |
:) |
21:14 |
|
Naros |
but we aren't talking about aspect programming here |
21:14 |
|
Quest |
so to my original question. of passing things from dao to jsp.. this strategy is ok? |
21:14 |
|
Naros |
its a good first pass yep |
21:14 |
|
* Quest |
saluts whartung sfisque Naros |
21:15 |
|
sfisque |
you want JSP <-> controller <-> service/dao |
21:15 |
|
* Quest |
about turns. |
21:15 |
|
Quest |
sfisque, ya. kind of |
21:15 |
|
Naros |
hence why i cautioned you about the value object exchange between service<->dao and controller<->service |
21:15 |
|
sfisque |
if you put any <% %> scriptlets in your JSP, it makes the baby java cry and a puppy gets shot in the face CIA style somewhere |
21:16 |
|
Quest |
i avoid scriptlets in jsps as 100% |
21:16 |
|
Quest |
99% |
21:16 |
|
Naros |
just turn scriptlets into taglibs :P |
21:16 |
|
Quest |
1% is for display view as inevitable as its agains MVC pattern |
21:17 |
|
* sfisque |
bonks Naros |
21:17 |
|
Quest |
Naros, ya. |
21:17 |
|
Quest |
i only use logic in jsp for view making purspose only |
21:17 |
|
Quest |
that can be any. taglibs. even scriptlets |
21:17 |
|
Naros |
I could be mistaken, but I'd say sfisque is implying try to have your controller do as much preparation of the data as possible. |
21:18 |
|
Quest |
time to go! office closed. got to give reports to MR. circle |
21:18 |
|
Naros |
ths way all the JSP does is very basic stuffs |
21:18 |
|
sfisque |
be well… /wave |
21:18 |
|
Quest |
:)) thanks guys. |
21:18 |
|
Naros |
laters. |
21:19 |
|
Naros |
so DAO method takes 22 parameters :/ |
21:19 |
|
Naros |
WTH |
21:19 |
|
sfisque |
only 22… wuss |
21:19 |
|
Naros |
I can make it take more :P |
21:20 |
|
Naros |
instead of a few String[] params where the API guarantees 3 values per array lol |
21:20 |
|
sfisque |
even better, change it to Object ... |
21:20 |
|
* Naros |
dislikes search forms |
21:20 |
|
Naros |
search forms break so many things |
21:21 |
|
Naros |
particularly if the form allows the user to create adhoc like queries |
21:21 |
|
* Naros |
sighs at sfisque. |
21:36 |
|
sfisque |
i actually like search forms. it's an easy target for pitching the idea of a DSL :P |
21:36 |
|
* sfisque |
loves building little languages |
21:37 |
|
Naros |
:) |
21:37 |
|
whartung |
yea i like toy languages too |
21:39 |
|
sfisque |
i have a peeve/question to present. lately i've been noticing the use of "DSL" to refer to API's. when did writing a library with some methods become synonymous with building a DSL? |
21:39 |
|
sfisque |
silly kids these days |
21:39 |
|
whartung |
Trix are for kids! |
21:40 |
|
sfisque |
i'd have gotten away with it too, if it werent for those silly kids and that dumb dog |
21:41 |
|
whartung |
Have you written many? |
21:41 |
|
sfisque |
4 commercially, 3 personally |
21:41 |
|
whartung |
cool |
21:41 |
|
whartung |
I've only done 1 |
21:42 |
|
sfisque |
almost all by "hand". though i've just finally learned how to use javacc. man that's POWER. i feel like a dark archon in starcraft |
21:42 |
|
whartung |
Full boat algol-esque language that compiled in to Jva source code |
21:42 |
|
whartung |
heh |
21:42 |
|
whartung |
yea, I used a Compiler Compiler |
21:42 |
|
sfisque |
i tried to learn CUP years ago, but the docs were "useless" |
21:43 |
|
whartung |
ANTLR is the Hot Thing today, at least for Java |
21:43 |
|
sfisque |
javacc was a beyatch too, but i got a good book on it via inter-library loan. |
21:43 |
|
whartung |
I used SableCC |
21:43 |
|
sfisque |
i dislike how antlr forces y ou to include their libs. javacc builds pure java, no lib dependancies |
21:43 |
|
whartung |
ok |
21:43 |
|
whartung |
I've not used it |
21:43 |
|
sfisque |
*** pure .java files |
21:43 |
|
whartung |
when I wrote my assembler, I wrote it all by hand |
21:44 |
|
whartung |
what were your runtimes? how did you do those? |
21:44 |
|
SoniEx2 |
I wanna make a CPU with dynamic instructions |
21:45 |
|
whartung |
uh... |
21:45 |
|
whartung |
what does taht mean? |
21:45 |
|
SoniEx2 |
and full Java bytecode support |
21:47 |
|
SoniEx2 |
well you can call it a FPGA-CPU I guess... |
21:47 |
|
whartung |
people do that all day long |
21:47 |
|
whartung |
lots of CPU cores out there |
21:48 |
|
SoniEx2 |
wait when did intel implement custom user-made instructions into their CPUs? |
21:49 |
|
SoniEx2 |
because I'm not aware of something like that... |
21:49 |
|
whartung |
huh? |
21:53 |
|
SoniEx2 |
http://en.wikipedia.org/wiki/Field-programmable_gate_array |
21:53 |
|
SoniEx2 |
basically I want to put a FPGA inside a CPU |
21:53 |
|
whartung |
why not put the CPU in the FPGA, that's what folks do now. |
21:53 |
|
SoniEx2 |
and let the user/program/OS do stuff |
21:53 |
|
whartung |
you can mount the FPGA as a co-processor |
21:54 |
|
sfisque |
you do that now. it's called a virtual machine |
21:54 |
|
SoniEx2 |
sfisque: that's not what I want |
21:55 |
|
sfisque |
then build it! |
21:56 |
|
SoniEx2 |
I want a... GPRPIS? (General Purpose ReProgrammable Instruction Set) |
21:57 |
|
sfisque |
that would be "build your own virtual machine" |
21:57 |
|
sfisque |
like… say… the JVM? |
21:57 |
|
sfisque |
or the ECMA engine? |
21:57 |
|
whartung |
yea I don't even know what "computer" means anymore |
21:57 |
|
SoniEx2 |
virtual machine is virtual |
21:57 |
|
sfisque |
so? |
21:57 |
|
SoniEx2 |
aka it's translating code into code |
21:58 |
|
sfisque |
so? |
21:58 |
|
whartung |
most CPUs today rely on microcode |
21:58 |
|
sfisque |
you think your precious CPU knows what JSR or LDY is? |
21:58 |
|
sfisque |
the cpu only knows 10101000111110101011010 |
21:58 |
|
sfisque |
there is a translation from a8c704 into 1011101010101011010101011 |
21:59 |
|
sfisque |
and from jsr 12c7 to a8c8d013 |
21:59 |
|
sfisque |
and then to 110110100011010101010 |
21:59 |
|
sfisque |
so there is ALWAYS conversion from code to code |
21:59 |
|
sfisque |
unless you're using punch cards and punching 1's and 0's |
22:00 |
|
sfisque |
or encoding directly to magnetic tape |
22:00 |
|
whartung |
I've entered code using a binary front panel -- not recommended |
22:00 |
|
sfisque |
i bet! |
22:00 |
|
SoniEx2 |
I don't think you get it... |
22:00 |
|
whartung |
no, you need to magnetize the individual cores of the core memory... |
22:00 |
|
sfisque |
i've actually held core memory. that's some pretty chunky stuff |
22:01 |
|
SoniEx2 |
virtual machine = instruction set to instruction set translation |
22:01 |
|
sfisque |
a buddy used to keep a 4kb wafer on his desk |
22:01 |
|
SoniEx2 |
GPRPIS = reprogrammable instruction set |
22:01 |
|
whartung |
Intel CPU -- Instruction to instruction set translation |
22:02 |
|
sfisque |
and then you have MX and other "extensions" to the instruction set |
22:02 |
|
SoniEx2 |
I just want to be able to add raw circuits to my code... |
22:02 |
|
sfisque |
unless you're building actual electrical pulses, there is always translation |
22:03 |
|
sfisque |
build a bio-computer |
22:04 |
|
whartung |
when you start working with emulators, and FPGA cores, and virtual machines and then throw in the internet and connected computing, the whole notion of "computers" really goes out the window. |
22:04 |
|
sfisque |
pretty much. to iterate the "sun mantra" of the 90's… the network is the computer |
22:05 |
|
sfisque |
i kind of miss the java stations. that was a neat little device |
22:05 |
|
whartung |
I mean, it was spooky back in the day when the Game Boy Advanced had both ARM and Z80 CPUs on board |
22:05 |
|
whartung |
I almost bought one of those, just for the color :) |
22:05 |
|
sfisque |
hell, you could plug a trash80 card into a appleII back in the day and run CPM |
22:06 |
|
whartung |
when the designers say "yea, we had some extra silicon so we stuck a Z80 up in the corner" as casually as if they were adding a flip flop, you know you're in trouble. |
22:06 |
|
sfisque |
lol |
22:06 |
|
sfisque |
well, you can fit a 80 inside a finger scab these days |
22:06 |
|
whartung |
it was a Z80 SoftCard :) |
22:07 |
|
whartung |
The C-128 has a Z80 in it |
22:07 |
|
sfisque |
i did not know that. |
22:07 |
|
whartung |
boy, the crap we put up with back then lol |
22:07 |
|
sfisque |
the commie 128 had one, eh |
22:07 |
|
whartung |
yea |
22:07 |
|
whartung |
the Ataris were cool because the graphic chip WAS a CPU in it own right |
22:08 |
|
whartung |
(simple one, but still) |
22:08 |
|
sfisque |
yah, i remember "memory paging" on the early x86. that was ANNOYING |
22:08 |
|
whartung |
yea |
22:08 |
|
sfisque |
had to swap segments from upper memory to use more than 640k or 1mb depending on bios |
22:08 |
|
whartung |
I wrote a map viewer program, showing street maps. |
22:08 |
|
whartung |
I had the map broken up in to 64K chunks |
22:09 |
|
whartung |
yea, virtual memory is a win |
22:09 |
|
whartung |
however... |
22:09 |
|
* whartung |
digs through his anecdote drawer again |
22:09 |
|
whartung |
Back In The Day |
22:09 |
|
whartung |
we had this large data set, it was bunch of rows |
22:09 |
|
whartung |
that were invidual nodes in a tree |
22:10 |
|
whartung |
and we need to basically link them all up in the database (or validate them) |
22:10 |
|
whartung |
Joe Hacker said "Tree! Pascal does trees!" |
22:10 |
|
whartung |
and off he ran to the VT100 and started pounding in VAX Pascal code |
22:11 |
|
whartung |
He fired it up, and it immediately sucked in the entire data set |
22:11 |
|
sfisque |
man i learned pascal back in high school. i LOVED pascal |
22:11 |
|
whartung |
then he started linking it all together |
22:11 |
|
whartung |
the detail |
22:11 |
|
whartung |
was we had NOWHERE near enough RAM for this |
22:11 |
|
sfisque |
i bet |
22:11 |
|
whartung |
so, it just thrashed and thrashed |
22:11 |
|
whartung |
I went to my boss |
22:12 |
|
whartung |
"Don, this is goibg to take 23 days" |
22:12 |
|
sfisque |
ouch |
22:13 |
|
sfisque |
yeah i wrote a few programs "back i the day" when i first learned C and C++. it was REALLY EASY to run out of memory, especially if you were doing EGA/VGA graphics |
22:14 |
|
sfisque |
and then the advent of vid cards with dedicated swaths of memory. oh boyz! |
22:15 |
|
sfisque |
bit-blitting == ugh |
22:30 |
|
whartung |
I rewrote that guys program using ISAM, and it took 23 hours |
22:30 |
|
whartung |
mind, I didn't know anything about ISAM at the time |
22:30 |
|
whartung |
but it caught my eye and "hey!…" |
22:30 |
|
whartung |
worked like a charm |
22:30 |
|
whartung |
…rwerote it in VAX BASIC-PLUS |
22:30 |
|
sfisque |
i've seem that "name" around, but you are the first person i know to actuall use it |
22:31 |
|
sfisque |
isam, that is |
22:35 |
|
sfisque |
i just thought of a KILLER feature for java 9 |
22:36 |
|
whartung |
ISAM is rock and roll man |
22:36 |
|
sfisque |
fold the "observable" object into java.lang.Object. it's such a bitch to have to build a proxy/delegate model around the Observable object because java does not have multiple inheritence. why not just put it into the Object, that way it's omni-present when you need it |
22:37 |
|
whartung |
…like in Smalltalk... |
22:37 |
|
whartung |
likely just to keep the weight of the object down. |
22:37 |
|
sfisque |
Observer is an interface so it's totally convenient. observable is annoying because you have to build a mixin or proxy/delegate it |
22:37 |
|
whartung |
I'm not familiar with the distinction |
22:38 |
|
sfisque |
it's not that heavy |
22:38 |
|
whartung |
an object pointer is heavy :) |
22:38 |
|
whartung |
adding another 4 byte to EVERY object -- is heavy |
22:38 |
|
sfisque |
omg, yeah, mr. 1993 |
22:38 |
|
whartung |
8 bytes on a 64b jvm (though I think they actually use les, not sure what trickery they use) |
22:39 |
|
whartung |
oh, it matters! |
22:39 |
|
whartung |
I have run in to stuff where the extra bytes matter |
22:39 |
|
whartung |
when caching 30M items, this stuff adds up |
22:40 |
|
sfisque |
then they need to give us a better mech for "notification" because we don't have multiple inheritence |
22:40 |
|
whartung |
we have PropertyChangeListerns :) |
22:41 |
|
sfisque |
aye but O/O are more generic than that |
22:41 |
|
whartung |
Is Obserevable new for 7? |
22:41 |
|
sfisque |
Obs/Obs |
22:41 |
|
whartung |
hmm..noipe lol |
22:41 |
|
sfisque |
no, it's been i the JDK since 1.0 |
22:41 |
|
whartung |
I've never used/seen it used |
22:41 |
|
sfisque |
it's one of the thigns they did right in 1.0 except for making it a bitch to use in an existing inheritence chain |
22:41 |
|
whartung |
is it not inherited? |
22:42 |
|
sfisque |
Observer = interface (no problem), Observable == concrete class (annoying to fold into an existing inheritence chain) |
22:42 |
|
whartung |
oh I thught it was an interface |
22:42 |
|
sfisque |
hence my desire to see Object fold in the features of Observable |
22:42 |
|
sfisque |
so any object is Observable |
22:43 |
|
whartung |
this is why I've never seen it used |
22:43 |
|
sfisque |
which makes sense in a world where more and more products need to pass messages |
22:43 |
|
whartung |
it's all PCLs now |
22:43 |
|
sfisque |
aye |
22:44 |
|
whartung |
well like I said, it'll add an object pointer to every object, and, yes, Mr 2013, it' STILL expensive :) |
22:44 |
|
whartung |
They lifted that straight out of ST |
22:44 |
|
whartung |
...badly |
22:44 |
|
sfisque |
generally you have to so something like :: class A { Observable o; public addObserver( obs ){ o.addObserver( obs ); } } // hence proxy the Observable and store it internally as an attribute (blech) |
22:45 |
|
whartung |
or you implement PCL |
22:45 |
|
sfisque |
right but then you have to write all the code that is given to you for free in Observable |
22:45 |
|
whartung |
Oh noes Mr. 2013…my IDE does that for me :D |
22:46 |
|
whartung |
or you can put it in your own base class |
22:46 |
|
sfisque |
no, it just stubs it out. Observable does some stuff and it does it well |
22:46 |
|
sfisque |
right but if you're extending someone elses object (say, androids Activity class) you don't get that option |
22:46 |
|
whartung |
with PCL you do :) |
22:47 |
|
sfisque |
yeah yeah yeah |
22:47 |
|
whartung |
your right, no MI -- we'z stuck with interfaces |
22:47 |
|
sfisque |
i prefer to not rewrite code that sun provided and did well |
22:47 |
|
whartung |
apparently they didn't :) |
22:47 |
|
sfisque |
well the did. remember, in the 1.0 world there werent any libs to use. java was "brand new" |
22:48 |
|
sfisque |
we had to roll our own |
22:48 |
|
whartung |
but it didn't stick |
22:48 |
|
whartung |
I don't think it was tossed out for being "too good" |
22:48 |
|
sfisque |
but in a 1.7+ world with a bajillion libs to download, it's inconvenient |
22:49 |
|
sfisque |
and i'm guessing it's probably leveraged quite a bit in sun/oracle's code |
22:49 |
|
whartung |
Observable? |
22:49 |
|
sfisque |
both |
22:49 |
|
sfisque |
Observer/Observable |
22:49 |
|
sfisque |
it's been around since 1.0 |
22:49 |
|
sfisque |
just like Hashtable and Vector are still leveraged in many places |
22:51 |
|
whartung |
Observer -- 57 classes in JDK 6 |
22:51 |
|
whartung |
Observable -- 6 classes |
22:52 |
|
sfisque |
i bet those 57 classes are pretty core |
22:52 |
|
sfisque |
what 6 extend Observable? awt, i'm betting |
22:53 |
|
whartung |
my mistake |
22:54 |
|
whartung |
they're not used at all lol |
22:54 |
|
whartung |
nobody extends Observable |
22:54 |
|
whartung |
nobody implement Observer |
22:54 |
|
sfisque |
wow. that's surprising |
22:54 |
|
whartung |
not really -- they're awful -- for all the reasons we know they're awful. |
22:55 |
|
sfisque |
they're not awful. they work. thery're just "inconvenient" |
22:55 |
|
sfisque |
in fact i'm using them in my android app. i just have to proxy Observable |
22:55 |
|
sfisque |
which i wish i didnt have to, but oh well |
22:56 |
|
whartung |
pretty sure pcl trumped them all -- and they wrote that code once in JComponent |
22:57 |
|
sfisque |
and then the square wheel was reinvented a bajillion times throughout the world |
22:57 |
|
sfisque |
:P |
22:59 |
|
whartung |
no, lost of the compoment implement it themselves |
23:03 |
|
whartung |
heh |
23:03 |
|
whartung |
http://d.pr/i/u1BR |
23:03 |
|
whartung |
zoiks and away! |
23:03 |
|
sfisque |
all awt/swing objects. so useless outside of a desktop app |
23:04 |
|
sfisque |
:-/ |
23:04 |
|
whartung |
this is effectively what you are doing |
23:04 |
|
whartung |
http://docs.oracle.com/javase/7/docs/api/java/beans/PropertyChangeSupport.html |
23:04 |
|
whartung |
well, Obserable is useless as well -- nothing implents that either |
23:06 |
|
tjsnell |
Awt/swing us useless in desktop apps too |
23:06 |
|
sfisque |
well they go together. you wouldnt see one used without the other (obs/obs) |
23:07 |
|
sfisque |
lol tjsnell! |
23:07 |
|
whartung |
just saying, that PCL and Obs are similar, it's a matter of taste as to which you implement. |
23:08 |
|
sfisque |
the difference is one is an interface so it integrates easier. the other is fully implemented class that requires early intergration or a mixin/proxy workaround |
23:08 |
|
whartung |
PCS is that |
23:08 |
|
whartung |
PCL is the interface, PCS is the class |
23:09 |
|
sfisque |
you realize PCS has the same problem as Obs/Obs, right? |
23:09 |
|
sfisque |
you have to proxy it |
23:09 |
|
whartung |
yes |
23:09 |
|
whartung |
never suggested different |
23:09 |
|
sfisque |
ok |
23:09 |
|
whartung |
my point being |
23:09 |
|
whartung |
that apparently the Sun Guys found Obserable lacking, and it seems to have been replaced by PCL/S |
23:10 |
|
whartung |
(Observable uses a Vector -- FYI, if you care…) |
23:10 |
|
sfisque |
or too generic. PCS/PCL is specific to value modification.. Obs/Obs is general purpose |
23:10 |
|
whartung |
eh, PCS is as generic as you want it to be |
23:11 |
|
whartung |
send a "OBSERVE" message with a null argument if you like |
23:11 |
|
sfisque |
right but then you're polluting the API (i can throw NPE for any excpetion if i like, but why would i?) |
23:11 |
|
whartung |
ST used the changed methed |
23:12 |
|
whartung |
you can also send a "FieldValueChangeNotifier" instance to Observable…6 to 1, half-dozne to the other. |
23:12 |
|
sfisque |
ST? |
23:12 |
|
whartung |
smalltalk |
23:12 |
|
sfisque |
oh, gotcha |
23:14 |
|
sfisque |
or how about this. wire in an anotation into the JVM so that you can tag an object as observable and in the annotation, you list observer types |
23:15 |
|
sfisque |
make it a meta feature so that it removes the inconvenience of inheritence |
23:15 |
|
whartung |
you can do that with an AP |
23:15 |
|
sfisque |
AP? |
23:15 |
|
whartung |
annotation processor at compile time |
23:16 |
|
sfisque |
right. but that's annoying. i was thinking like the jvm could handle it natively |
23:16 |
|
whartung |
you could put @Obserable at the class level, and get it "for free" |
23:16 |
|
whartung |
it's not that annoying |
23:16 |
|
sfisque |
another thing i'd like to see, a way to attach an interceptor on constructors |
23:17 |
|
sfisque |
native in the JVM |
23:18 |
|
sfisque |
then you could do things like constructor injection outside of a "container" (basically the JVM becomes a micro-container) |
23:19 |
|
sfisque |
that would be neat. have the JVM have a command switch that turns on a native micro-container so we can do things like AOP and CDI without a EJB container |
23:20 |
|
sfisque |
get nice features like @AroundInvoke, or @Produces |
23:22 |
|
whartung |
yea |